Procedia Information Technology & Computer Science
00 (2013) 000-‐000
2 World Conference on Innovation and Computer Sciences 2012 rd
Network Discovery Tool for IPv4 and IPv6
a
a
b
Tomáš Sochor *, Jan Sochor Department of Informatics and Computers, University of Ostrava, 30. dubna 22, 701 03 Ostrava, Czech Republic b Faculty of Informatics, Masaryk University, Botanická 68a, 602 00 Brno, Czech Republic
Abstract
Present network discovery tools are focused on the prevailing Internet Protocol version 4 while tools discovering IPv6 network are missing. Our aim was to study approaches to the IPv6 discovery and to implement the new tool. SNMP was used as the primary protocol for network data gathering. Detailed analysis of specific MIB records was also done to ensure full data gathering and its correct interpretation. The new tool was implemented in C# and third-‐party libraries #SNMP and Graph# were used. The final product was tested in several small to medium scale networks. In case of IPv4 networks it produced results comparable to other tools. In case of IPv6 networks, the comparison was limited due to lack of well documented IPv6 networks. The outputs precision level was higher than expected. The new tool proved to be efficient and precise in discovering the unknown topology. Further testing in IPv6 networks is necessary.
Keywords: C#, Ipv4, Ipv6, Network discovery, SNMP; Selection and/or peer review under responsibility of Prof. Dr. Dogan Ibrahim. ©2013 Academic World Education & Research Center. All rights reserved.
1. Introduction Network discovery in the sense of the procedure of finding as many as possible devices in the network (with obvious preference given to active devices like routers and switches) from a single device in the network is a crucial operation for administration of any larger network. There are various tools discovering devices in networks using the common IP protocol of the present legacy version 4.
* ADDRESS FOR CORRESPONDENCE: Tomáš Sochor, University of Ostrava, Dept. of Computer Science, 30. dubna 22, Ostrava,
CY701 03, Czech Republic E-‐mail address:
[email protected] / Tel.: +420-‐59-‐709-‐2129
Firs Author name et all. / Procedia Information Technology & Computer Science (2013) 000-‐000
The emergence and rapidly spreading use of the new generation IP version 6 (hereinafter IPv6) poses a challenge how to perform a similar operation with the new protocol. There have been some attempts to build network discovery tools for the emerging IPv6 protocol (a recent one see in Guanlan, Qin, Yan & Hongli (2010)) but most of the so far proposed solutions have been characterised by just limited usability. Because of the lack of versatile tools able to perform the network discovery, the project of implementation of a new network discovery tool was performed and the results are presented in this article. 2. Network Discovery Methods Not many works focusing on the network discovery in IPv6 networks have been published so far, but most of them agreed on the conclusion that approaches useful in IPv4 cannot be used unmodified in IPv6 networks (see Hsieh & Kao (2006), Luo, Fan &Ye (2007), and Waddington, Chang, Viswamathan & Yao (2003)). A brief overview of possible approaches follows with an emphasis on usability of the specific approach in networks where IPv6 operates. 2.1. Tracing towards all nodes The ICMP protocol, which is widely used in IPv4 networks, is potentially applicable for IPv6 too (in the ICMPv6 version). Its drawback is known – slow discovery in larger networks due to the necessity to send a lot of IP packets to every possible network address and waiting for replies for a relatively long time. This aspect became muc h worse in IPv6-‐based networks because every node in IPv6 network can have more active and used addresses. This fact also makes the compilation of the topology a much more complex task. This is the main reason why this approach was not considered applicable in IPv6. 2.2. Management protocols application Network management protocols (especially SNMP) can be used for the network discovery too. In IPv4 networks, it is often combined with broadcasting packets to all possible addresses. This method is relatively fast but limited to the fact that numerous operating systems may not respond to broadcast packets under some circumstances. The fact of discarding broadcasts on most routers also limits the use of broadcasts to smaller networks. However, a modification of this approach using unicast packets (and thus avoiding both drawbacks mentioned above) is widely used in IPv4. The application of SNMP seems viable in IPv6 due to replacement of broadcasts by multicasts. 2.3. Link-‐state routing protocol approach Link-‐state routing algorithms (e.g. OSPF) operate based on their own formed network map including lines interconnecting single nodes. A similar approach can be used both in IPv4 and IPv6 networks discovery subject to support the selected routing protocol on all network nodes. The main problem of this approach consists in elimination of all other layers, except for the network one. However, only routers and other routing devices (like L3 switches) can be discovered, and therefore present in the resulting network map thus ignoring classical L2 switches and many other network devices. 2.4. Gradual enquiring via management protocol with a-‐priori knowledge of a node This method makes use of a management protocol but it is based on gradual sending a management enquiry to all potential nodes from the node of origin that is known a priori. The discovering node establishes an SNMP connection to the node of origin and it can discover all SNMP-‐ capable subset of the network from SNMP responses. This approach is fast and provides good results 2
Firs Author name et all. / Procedia Information Technology & Computer Science (2013) 000-‐000
in certain types of networks. However certain layout of the network nodes not supporting SNMP can completely distort the resulting network diagram. A-‐priori information about one SNMP-‐capable node required for the process to start could also be critical under some circumstances, but does not pose a significant problem in most cases. Thanks to the fact that SNMP like application layer protocol does not differ much under IPv4 and IPv6 protocols, this approach could be used for both types of networks. 3. IPv6-‐specific Discovery Approach The difference in the scope of available addresses in an individual network between IPv4 and IPv6 networks, as mentioned above, is the most significant obstacle making the traditional network discovery based on IP addresses almost unusable. The comparison of the IP protocol in versions 4 and 6 from the point of view of the number of addresses used in network discovery is summarized in the Tab. 1 below. Table 1. IPv4 and IPv6 Address Range and Number Comparison Protocol IP version 4 IP version 6
No. of addresses in LAN 254 -‐ 65,534 19 1.84 x 10
No. of addresses per node 1 – 2 2 – 10 or more
Anycast addresses in IPv6 (formally non-‐distinguishable from unicast addresses, unlike multicasts) pose another obstacle against the IPv6 address based network discovery, thus making this approach almost unfeasible. Despite some drawbacks the latter method using SNMP was determined as the only feasible approach in IPv6 networks because it is the only one not relying solely on IP addresses. The advantage of this approach is the fact that it is also usable in IPv4 networks without limitation. 4. Results 4.1. Network Discovery Design Having the decision to develop own solution for network discovery, the best development practices were applied in the form of agile methodology recommendations as summarized by the article Procházka (2010). The C# programming language was chosen for implementation of the tool and the name MyNetDiscoverer was given to the new program being developed. After a deep analysis of the above-‐mentioned approaches, the method based on SNMP queries as described in the chapter Methods section 2.4 was chosen as the basis for MyNetDiscoverer. Because of the fact that SNMP operates on the application layer, the unresolved issue how the network boundary should be determined emerged. There are 2 approaches to consider: • Setting the network boundary using an IP address and mask, • Setting the network boundary using an SNMP community string. The first approach is not very useful especially in IPv4 networks where subnetting is frequent because every subnet would be considered as an individual network. Therefore the set of all nodes with the same SNPM community string is considered to form a single network. 4.2. Additional information from the network The analysis showed that information from SNMP could be insufficient especially in the case of infrequent or even no traffic in the network. Therefore additional information from other protocols is used too (when available). Such protocols include CDP (Cisco proprietary but information-‐rich) and LLDP (less information but widely supported by network device producers). 3
Firs Author name et all. / Procedia Information Technology & Computer Science (2013) 000-‐000
4.3. MIB records processing The result of an SNMP query is in the form of a value of MIB having its own unique OID identifier. In the case of tables or other multidimensional data stored in a single MIB record (originally intended to store only a single scalar value), so-‐called indexes are used extending the OID by the index value containing the information about the position in the table. To obtain values from these indexed MIB tables, a special method was implemented. There are several MIBs designed for various purposes. Several of them were selected to integrate their data in the network discovery process, namely SNMPv2-‐MIB, IF-‐MIB, IP-‐MIB, IPV6-‐MIB, RFC1213-‐ MIB, CISCO-‐IETF-‐IP-‐MIB, CISCO-‐CDP-‐MIB, LLDP-‐MIB, BRIDGE-‐MIB and Q-‐BRIDGE. Relatively large amount of MIBs used was due to various levels of implementation of the used supporting protocols (e.g. LLDP) in devices by various manufacturers. 4.4. Network Discovery Implementation The implementation was made using C# and .NET (versions 3.5 or higher required). Two third-‐party libraries were used, namely #SNMP (see C# in references for details) for SNMP requests sending and receiving, and Graph# (see Graph# in references for details) for displaying the resulting network diagram. The algorithm used for network discovery is described in the following list. Assumptions made: q is the empty queue, s the address of the initial node. 1. q.enqueue(s) 2. loop 3. lock q 4. if q is empty then 5. release q; return; end if 6. p → q.dequeue() 7. release q 8. p.processing() 9. lock q 10. for all n in list of neighbours of p node do 11. if the node n was not processed before then 12. q.enqueue(n); end if; end for 13. release q; 14. end loop
The procedure described above is based on the method described in the chapter Methods section D and it is used for gradual discovering the network and subsequent forming of the topology. Most of the time is spent by the processing() method in line 8. The time consumption is mainly due to the required communication over the network. Due to the fact that processing of a single node is independent of the processing of other nodes. Therefore running this method in parallel threads is possible. The queue with nodes to be processed serves as a synchronization mechanism. However, an adequate adjusting of the maximum number of concurrent connections is necessary to avoid network congestion due to the traffic generated by the network discovery tool. As one can see, the procedure above contains two pairs of lock and release primitives denoting the beginning and the end of critical sections respectively. 5. Discussion 5.1. MyNetDiscoverer Verification The MyNetDiscoverer program was tested in both IPv4 and IPv6 networks to verify that the produced results reflect the real network topology. Testing in IPv4 networks was performed by running the program in two networks (a small one, modelling a small home office network, and a 4
Firs Author name et all. / Procedia Information Technology & Computer Science (2013) 000-‐000
larger one, modelling a network of a medium enterprise) with known topologies. The results were compared both to the real topology and to the output of the well-‐known commercial network discovery tool SolarWinds LANSurveyor. The resulting topology of the small network in MyNetDiscoverer was almost identical to the one of LANSurveyor output of the same network. The differences lie only in negligible details. Having compared both outputs, it was easily concluded that the topology produced by our tool is comparable to the commercial tool. In the case of the larger IPv4 network the comparison resulted in a comparable result (between 50% and 60% of all nodes were discovered by both MyNetDiscoverer and LANSurveyor). The illustration of this test is shown in Fig. 1.
5
Firs Author name et all. / Procedia Information Technology & Computer Science (2013) 000-‐000
Fig. 1.Part of larger IPv4 network topology made by MyNetDiscoverer
Another important factor in testing the MyNetDiscoverer program was the network discovery speed. The times required for producing the network topology are summarized in the Tab. 2. Table 2. Time of IPv4 network topology creation Program LANSurveyor MyNetDiscoverer
Small LAN (~10 nodes ) 21 s 7 s
Medium LAN (~700 nodes) >1 hour 14 min.
Figure 2. Part of IPv6 network topology made by MyNetDiscoverer
The most important part of verification of the MyNetDiscoverer program should have been done in IPv6 networks because the main purpose of the MyNetDiscoverer program was to allow the network 6
Firs Author name et all. / Procedia Information Technology & Computer Science (2013) 000-‐000
discovery in IPv6. Despite the lack of IPv6 based networks where testing could be done making a significant obstacle in performing thorough testing of the MyNetDiscoverer program the only test was done in a single network. A part of the resulting topology is shown in the Fig. 2. The diagram in the figure serves rather as an illustration because of the size of the network. The real results will be presented in details at the conference. The lack of available tools for network discovery in IPv6 networks posed another problem in verification of the MyNetDiscoverer program because there was no network topology diagram which the result of the program could be compared to. Therefore the only comparison made was with a hand-‐made network diagram prepared by the administrator of the network used for testing. The result of this manual comparison was positive (i.e. the network topology produced by the MyNetDiscoverer program corresponded to the real networks as shown in the documentation). Still more detailed and exact verification of the program in more IPv6 networks is necessary. 6. Conclusion As demonstrated above, a new network discovery tool called MyNetDiscoverer has been developed, intended primarily for IPv6 networks. During the MyNetDiscoverer program verification the following conclusions were made: •
The MyNetDiscoverer program performs well both in IPv4 and IPv6 networks but a more detailed verification especially in IPv6 networks is necessary.
•
The performance of the MyNetDiscoverer program in IPv4 was confirmed as comparable to commercial tools.
Acknowledgements Authors acknowledge the willingness of SolarWinds Company in Brno to have the testing network available and necessary software tools for testing and experiments. References Guanlan C., Qin Z., Yan M. and Hongli K. (2010), “A new topology discovery solution for IPv4 & IPv6 coexisting networks,” in: International Conference on Advanced Intelligence and Awareness Internet (AIAI 2010). Beijing, 2010, pp. 208–212. Hsieh I., Kao S. (2006) “Topology Discovery for Coexisting IPv6 and IPv4 Networks,” in: ICIS-‐COMSAR Proceedings of the 5th IEEE/ACIS international Conference on Computer and information Science & 1st IEEE/ACIS international Workshop on Component-‐Based Software Engineering, Software Architecture and Reuse. Washington: IEEE Comp. Soc., 2006, pp. 89–95. Luo J., Fan M., Ye D. (2007) “Research on Topology Discovery for IPv6 Networks” in: Software Engineering, Artificial Intelligence, Networking, and Parallel/Distributed Computing. Eighth ACIS International Conference on. Qingdao: SNPD, p. 804–809. Waddington D. G., Chang F., Viswamathan R., Yao B. (2003), “Topology discovery for public IPv6 networks,” in: SIGCOMM Computer Communication Review, vol. 33, no. 3, p. 59–68. Procházka J. (2010), “Agile Support and Maintenance of IT Services” in: Business Systems and Services: Modeling and Development. Springer. C# Based Open Source SNMP for .NET and Mono. Online. Available at www: [http://sharpsnmplib.codeplex.com/] Graph# webpage. Online. Available at www: [http://graphsharp.codeplex.com/]
7
