Mapping Tool for Networks Using OSPF and LLTD Protocols

Transcription

1 Mapping Tool for Networks Using OSPF and LLTD Protocols PAVEL KRIZ, FILIP MALY Department of Informatics and Quantitative Methods University of Hradec Kralove Rokitanskeho 62, Hradec Kralove CZECH REPUBLIC Abstract: This article deals with enhancing of an existing functionality of OSPF network topology discovery tool. Enhancements are necessary to facilitate the use of the original tool in any network that uses OSPF routing protocol and routing software Zebra/Quagga. Enhancements consist primarily in an easier way of obtaining topological data. Furthermore the concept of future functionality is discussed. It consists of two main features: topological data export to other analytical tools and the use of LLTD protocol for local L2 topology discovery. Key-Words: OSPF, topology discovery, wireless community networks, LLTD, Dijkstra, Quagga, GraphViz. 1 Introduction During the development of community networks the need to obtain a clear and reliable picture of the entire network topology appeared. With this information it is possible to further develop the network efficiently, solve problems in network, or clarify dependencies between individual nodes according to the real topology. By analyzing the dependencies we can properly inform users about planned network outages, since it is known on which nodes and connections is the end node (user) functionally dependent. In addition the knowledge of the topology may be used for supporting the analysis of unplanned outages by network users, as outlined below. 2 The main goals and current status A tool for analyzing and planning the OSPFbased network topology was designed and developed based on needs HKFree community network. OSPF dynamic routing protocol is popular among the other networks and the resulting application is useful outside the community wireless networks area as well. The primary goals of this application are discovery and analysis of an unknown OSPF topology and assisting the network administrators (users) in planning the topology changes and solving potential problems with the OSPF configuration [1]. The application enables analysis of very large networks as it's able to visualize only the selected part of the network. The part was originally defined as a part of the sub-graph G' G determined by the initial node and the depth to which the original graph G is traversed. This solution was insufficient, since the existence of nodes with many neighbors (core backbone elements) caused the visualization of large amount of (irrelevant) nodes. As a result it was difficult to overview such a graph. Therefore, interactive mode has been added to support the incremental revealing of neighboring nodes. Using this approach we achieved functionality the user can see just a part of the network that he or she needs. Of course it is possible to hide the nodes back again. The application also has a network history analysis mode that among other things is suitable to detect hot spots where are frequent (unwanted) topological changes. This analysis also allows analyzing the historical states of the network, so expost we are able to identify the possible causes of failure such as temporary malfunction or misconfiguration of a router. Some known anomalies, like asymmetric OSPF costs in two directions of the same link, may occur in the network configuration. It may be the intention of administrator as well as a misconfiguration. Application is able to warn the users about these anomalies and visually highlight them in the resulting graph. Application currently provides basic statistical analysis of the network graph. This allows us to identify critical points in network, i.e. nodes or edges, whose failure leads to dividing the graph (i.e. the real network) into two or more components. The more components occur, the more critical given node or link is. In future versions we plan to visually highlight these critical areas. ISBN:

2 The structure of a wide network of routers can be hardly overviewed by a user. It is however expected that the user knows the approximate geographic location of the router(s). That is why we developed the feature to layout the graph according to the GPS positions, assuming that the positions of some network devices will be available. Network routing is one of the most important issues that administrators deal with. Proper OSPF cost assigning to the links is the only way to influence the way the data are physically routed. Assigning these costs is often very sensitive issue. At the moment when the administrator sets the router in the way he or she wants, it is appropriate to test the running configuration using ping and/or traceroute tools. Using our tool, administrator will not have to configure and test the real device or whole network as the tool is able to simulate his or her changes showing the shortest paths in the network. There is an option to display the tree of shortest paths from a selected router to all other available network routers. To calculate the shortest paths tree the Dijkstra's algorithm is used in the same way as in an OSPF implementation. The visualized map also properly handles and simulates any interactive changes in costs of links, switching routers and links on or off and inserting new routers or links to the model. In this case the shortest paths are immediately recalculated. The user is able to simulate various situations that may actually occur. The tool is able to properly work with links connecting more than two routers. Such a link may in fact be made of more point-to-point links, but these are inter-connected at the Layer-2 (L2) and such links are not captured in OSPF in detail. Therefore the actual physical topology is not known in this regard. Such a multi-link behaves to OSPF like a full-mesh inter-connection between all participating routers. However, displaying full-mesh is not very appropriate since it will strongly increase the number of displayed links and visual appearance has no benefit for users. So we implemented the transformation procedure, that transforms a multilink to a special node type (which doesn't correspond to the router) and this node is adjacent using edges to all the nodes representing routers participating in the original multi-link. This is a reasonable compromise to emphasize information about the likely complicated L2 topology (although without the knowledge of its details) and also to simplify visualization [2]. Figure 1 shows an example output map of the part of network that was incrementally visualized using the interactive mode. Fig. 1. Example output map of the part of a real network 3 Making the tool more general One of the current goals is to reach a wider group of users. This was problematic as the application was designed for the specific needs of HKFree community network. First of all, we are working on the localization. According to the original target group of users, the application was available only in Czech language. We will translate it into English. 3.1 Changes in deployment architecture The dependency on the central server (OSPF snapshot archive server), which provided regular saving of OSPF database to text files, becomes a specific limitation for news users. The archives of these files were created on the server and were then on-demand downloaded by the application. The original architecture is shown in Figure 2. This solution is robust enough for long-term deployment, especially if we want to analyze historical changes of the network. (Java) HTTP request to archive Response with OSPF snapshot archive OSPF snapshot archive server (shell+perl) Reverse DNS requests Responses Scheduled requests to Quagga console (port 2604) Textual responses (OSPF database) Fig. 2. Original architecture running Quagga ISBN:

3 However, the requirement for the server part is restrictive for users who want to try the tool or use it only occasionally. Therefore we are developing a solution that allows direct connection of the tool into the (running Zebra/Quagga router implementation). After this improvement the user will be able to use the tool without being forced to install the server part. He or she will only enter the address of the router, the port on which the Quagga's telnet-console listens and password to access the console. When analyzing this solution the problem with the translation of RouterID to the router name appeared. RouterID, a unique router identifier, is an assigned four-byte value often corresponding to the main IP address of the router. To assign appropriate human-friendly names the standard solution based on a DNS server is used. The DNS server is able to do a reverse lookup of particular IP address and translate it to the router's domain name. RouterIDs are often picked out of the private address space [3], especially today, when the public IPv4 addresses are exhausted. Unfortunately these private addresses cannot be translated by publicly available DNS servers on the Internet. We must translate the RouterID to the name of the router using the right private DNS server that is not part of the public DNS hierarchy. As we don't want the user to be forced to change his or her default system DNS server the application will allow entering the address of the (private) DNS server to be used for translation RouterID to the name of the router. This problem was not discovered during the testing of the original architecture because the server part was deployed inside the private network and the server was configured to use the private DNS server as its default system DNS server. A new alternative architecture is shown in Figure 3. Of course, it is still possible to use the original solution employing the server part. (Java) Reverse DNS requests Responses On demand requests to Quagga console (port 2604) Textual responses (OSPF database) Fig. 3. New alternative architecture running Quagga name (e.g..hkfree.org ). This suffix was the same for all routers in a network. As a result, the names displayed in the map are considerably shorter and thus the map is clearer. The same suffix had no added value so we lost no information. As we want to simplify the application by eliminating the server part the name trimming functionality must be added to the tool. So we will develop the automatic major suffix detection. It will analyze all the names and identify the major suffix that will be trimmed off. User will not have to predefine this suffix. The application will have a general-purpose while maintaining comfort by reducing the displayed names' length. Threshold frequency for determining the major suffix will be empirically selected. Nodes with the major suffix trimmed off as well as nodes with full names (not using major suffix) may appear in the resulting network map. The dot symbol will be added at the end of non-trimmed (i.e. full) names to avoid ambiguity of the actual domain name. So it will be clear which names are full domain names and which are using the major suffix that was trimmed off. It may also happen that the IP address of the node cannot be looked up using the DNS server. This can occur when the given node is not inserted into the DNS server or when the DNS server is completely unavailable or does not exist. In this situation, the map will display only the IP address. An example of all possible options is shown in Table 1 (note the dot after the com domain). We assume that the algorithm identified.hkfree.org as the major domain suffix. Node Name Display Name gw.transit.example.com gw.transit.example.com. r1.backbone1.hkfree.org r1.backbone Table 1. Node name display options In case that no major suffix is identified, no trimming is performed and so all names will be displayed in full. From these steps, we expect to extend the user base and to get a feedback from users in the form of bug reports or suggestions for improvements. We would like to address other developers who would actively participate in this project and contribute to it as well. 3.2 Automatic suffix detection Originally the server part trimmed off the predefined domain name suffix from the router's ISBN:

4 4 Export to other analytical tools During our research of analysis of the network graph, we have found the CytoScape tool [4]. It was originally intended for the area of bioinformatics, specifically the analysis of interacting molecule networks. Using plugins CytoScape was successfully adapted for use in other fields such as social networks or semantic web. So we plan to evaluate this tool in the context of computer network topology visualization and analysis. The easiest first step is to export our topology to a format suitable for import into CytoScape. E.g. Graph Modeling Language (GML), which is also supported by other popular tools for working with graphs such as yed Graph Editor. In case that the use of CytoScape for network topology will be successful, we will consider a possible future integration of both tools, whether such as developing a plug-in for CytoScape or integrating parts of CytoScape into our tool (this is possible thanks to the open-source license). 5 L2 topology mapping extension Another extension is designed to support the mapping of the local topology at the Layer-2 (L2) and Layer-3 (L3) without the use of OSPF. This will enable to analyze the topology of L2 within the user's home network and to analyze statically routed network edges. This extension will require a software component deployed to the user's PC. This component is temporarily called the topology. Its mission is to perform a local topology discovery, in cooperation with other s, and send the topology to the topology server that will combine these local topologies the global one. Existing available methods, such as Link Layer Topology Discovery (LLTD) protocol by Microsoft, which is implemented in Windows Vista and later operating systems, will be used for local mapping [5]. We can use well-known traceroute-based methods for L3 topology discovery [6]. Conceptual architecture of the new solution is shown in Figure 4. The communication layer, providing interconnection among topology s and other components, may be implemented using our Mobile-Oriented Scalable Cooperative Architecture[7]. Global topology Cooperative P2P DNS (router/node names) Topology server Local L2 topology gathering OSPF database (L3 topology) Fig. 4. Conceptual architecture supporting L2 topology discovery 5.1 Testing LLTD As the LLTD in MS Windows is quite promising for our tool, we have done a basic testing and analysis of this protocol and implementation. The protocol uses two main roles for devices: Mapper and Responder. Mapper is a device that initiated the process of mapping local topology and at the end of the process gets the final map. Responder is simpler and serves to provide Mapper information about its existence and other details (how the device is connected to the network, etc.). Responder can be installed install into Windows XP. Mapping can be performed only if the PC is configured to be connected into a private network. Using the System Policies the functionality of the Responder may be enabled even for public or domain network type. Responder can be deployed into other devices than just PCs. E.g. it can be installed into gaming consoles, wireless access points and other equipment for the consumer market. LLTD is well adapted for mapping local networks using wireless technology based on IEEE LLTD works strictly on the second layer (L2), so it does not map the topology beyond the first router. Therefore a new component called topology deployed into the PC in every L2 network segment is necessary to perform local topology discovery and to pass the topology to the server. For testing we used several PCs with Windows XP, Vista and Seven and two Wi-Fi routers that were able to work as a simple wireless access points (AP). We proposed and built 10 different testing topologies. For each topology the discovery process was done several times using the built-in Network Map tool in Windows. We also developed a simple tool designed to perform its own topology discovery (using LLTD) that is independent of the Microsoft's ISBN:

5 implementation of the Mapper. The output of this tool is a text file describing the graph topology in the format specific for the GraphViz visualization tool that can finally render the resulting map picture. Results of testing showed that both the original Microsoft's Network Map and our prototype implementation of the Mapper provide good results. Discovered topology roughly corresponds to the real topology and contains additional information such as wireless network names (ESSIDs). However both solutions cannot provide completely reliable results and in some cases, the resulting topology slightly differed when we ran the discovery process several times. LLTD results should be therefore considered approximate. It turned out that some results were adversely affected by the suspending and reawakening of equipment (e.g. laptop). 6 Conclusion The described tool is very well proven by HKFree community wireless network administrators and is actively used by them. Several obstacles complicating the general use of the tool will be removed through enhancements as described here. The main enhancements are: - the possibility of direct connection to the based on Zebra/Quagga software without installing the server part, - automatic detection of the DNS suffix used within the network. We believe that these enhancements will bring wider adoption of the tool by other network administrators and will address developers to participate in the development of this project. Further, the function for export the topology to other analytical tools is proposed. We also outlined the concept of an extension for local L2 topology discovery based on LLTD protocol that was briefly tested. The tool was developed during our research of community wireless networks and is available at References: [1] Kriz, P. Maly, F. Topology Discovery in Wireless Community Network. In Proceedings of the 2nd European Conference of Computer Science (ECCS '11), pp , Puerto De La Cruz, Tenerife, Spain, World Scientic and Engineering Academy and Society (WSEAS). ISBN [2] Menzel, J. Administration, design and visualization of net of routers using OSPF protocol, Czech Republic, Diploma thesis. University of Hradec Kralove. [3] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. J. & Lear, E. Address Allocation for Private Internets, Internet Engineering Task Force (IETF), 1996, RFC [4] Smoot, M.E., Ono, K., Ruscheinski, J., Wang, P.L., Ideker, T. Cytoscape 2.8: new features for data integration and network visualization. Bioinformatics Feb 1;27(3): Epub 2010 Dec 12. PubMed PMID: ; PubMed Central PMCID: PMC [5] Microsoft Research. A Windows Rally Specification LLTD: Link Layer Topology Discovery Protocol. [Online] URL: aspx?id=72439 [6] Donnet, B., Friedman, T. Internet topology discovery: A survey. IEEE Communications Surveys and Tutorials. 2007, 9, 4, pp ISSN X. [7] Maly, F. Kriz, P. Mobile-oriented Scalable Cooperative Architecture. In Proceedings of the 15th WSEAS international conference on Computers, pp , Greece, World Scientific and Engineering Academy and Society (WSEAS). ISBN ISBN: