Web-based Automatic Network Discovery/Map Systems

Transcription

1 20 International Conference on Computer Applications and Industrial Electronics (ICCAIE 20) Web-based Automatic Network Discovery/Map Systems Chakchai So-In, Chinnakorn Netphakdee, Kasidit Wijitsopon, Chavalit Panichayanubal and Pusadee Seresangtakul Department of Computer Science, Faculty of Science, Khon Kaen University Maung, Khon Kaen, Thailand, Abstract This paper introduces a new automatic network discovery/map system via Web architecture, the so-called Web-based Automatic Network discovery/map Systems (). The system functions as a plug-in for a wellknown network management system, Cacti. Enriched features, especially the automatic networking discovery and map module, have been added in order to enhance the efficiency of Cacti embedded with a weather map plug-in. With user defined-pattern functions, the discovery process recognizes a proper type of networking devices. The discovery process generates XML-based information so that a graph visualization using jquery via HTML5 can generate a simplified network map using a force-directed layout technique. is easy-to-use and less complicated, and so lessening the discovery time. In particular, for performance comparison with OpenMMS and DNMA, outperforms others in several perspectives, i.e., faster convergence, better coverage, and more details of types of networking devices. The system is presently used at the department of Information Technology, Provincial Police Region 4, Thailand. Keywords Network Management System; NMS; ; Web-based Automatic Network discovery/map Systems; Network Discovery; Network Map; SNMP; MIB; FCAPS I. INTRODUCTION wadays, almost all organizations (either academic or industry) are not only linked within their own departments but also joined into a bigger network, and resulting into the Internet. A huge number of networking devices, e.g., personal computer, laptop, mobile phone, sensor, server, switch, router, are included in this complex network. Several issues concerning heterogeneous networks and devices in term of networking control and management have been brought up such as Fault, Configuration, Accounting, Performance, and Security (FCAPS) in order to aid the network operating properly in an efficient way. FCAPS is the standard defined by ISO [] so that any Network Management Systems (NMS) can follow the requirements, e.g., to record statistical information for future network prediction, to specify multi-privileges for different users, to display a networking map of mixed devices for monitoring purposes, and to embed security protection systems against intruders. This work was supported in part by the grant (CSKKU2/2554#8) from the Department of Computer Science, Khon Kaen University. NMS is a combination system of hardware and software functioning as monitoring and administering tools for heterogeneous networks. Simple Network Management Protocol (SNMP) [2] is commonly used within NMS in that Management Information Base (MIB) [3] is acquired for each individual networking device as statistical information, e.g., packet sentreceived and networking interface descriptions. Also, the protocol allows administrators to configure some features (read/write modes) in each particular networking device. There have been several NMSs in both commercial (HP Openview, CiscoWork, Tivoli Netview, Solarwinds, etc.) and non-profitable or open-source (Nagios, Zenoss, OpenNMS, Cacti, etc.) [4-5]; each of which NNS provides different features, functions, and supports. Cacti Traffic Grapher (Cacti) [6] is one of the opensource web-based network management systems providing enriched features such as embedded graph templates, easy-to-install and easy-to-use menus, and only required basic software components (mysql, php, rrdtool, and optional net-snmp). Additionally, Cacti supports adding-on plug-ins using as a tool to enhance the overall system performance for individual usage as an increase of complexity trade-off (versus OpenNMS, Nagios or Zenoss as examples of more complex NMSs). For example, a weather map plug-in including MRTG [7] allows the administrator to manually draw an individual map providing the network traffic usage. However, Cacti with the weather map plug-in does not allow users and/or administrators to monitor and manage networking devices efficiently, such as port-based monitoring, active link status, link notification (either via or SMS), SNMP read/write-enable configuration, and web-based network configuration. Most importantly, a combination of various plug-ins cannot hold the necessity features of NMS, especially the automatic networking discovery/map. As a result, in this paper, we enhanced Cacti performance by including a weather map plug-in embedded with necessity features as stated above. One of the features is the automatic networking device discovery plug-in in which the discovery information will be drawn as a networking map via XML-based information using an Arbor library, a graph visualization library using web //$ IEEE 480

2 workers and jquery (HTML5) [8], the so-called Webbased Automatic Network discovery/map Systems (). adapts the use of ipaddrtable MIB information [2], and so the discovery time is reduced (versus iproutetable). The system also allows user-defined description patterns in order to identify the type of networking devices. In addition, with the plug-in concept, the operation time is bounded not to compute all unrelated monitoring and management functionalities. This paper is organized as in the followings. In Section II, we briefly surveyed recent research/proposals regarding the techniques for network management systems (NMSs), and discussed about several issues, especially the automatic discovery and map functions. Then, in Section III, an overview of our system,, will be discussed. Section IV provides the detailed description for our automatic network discovery/map systems. After that we discussed the system performance comparatively in Section V. Finally, the conclusions are drawn in Section VI. II. RELATED WORK Due to the advance of networking technology, the communication among networking devices tends to be more complex, and so the networking management system (NMS) becomes necessity for administrators to smooth out the operation and to lead heterogeneous devices to function efficiently. For years, several NMSs have been proposed in both open-source and commercial software/hardware [4-5]. In [9], J. Hughes showed that some of NMSs are more frequent to be downloaded. Nagios [0] is the top-most download; and the latter are MRTG-based tools [], Zenoss [2], OpenMMS [3], and Hyperic [4], respectively. The reasons for users/administrators to adopt these tools include networking coverage accuracy, detailed statistical information, and complexity and easyto-use/install criteria. In [5], the comparative function of Nagios, Zenoss, OpenMMS, and Cacti (using MRTG) [6] was evaluated in terms of monitoring display, device discovery, plug-in usage, and report. Each has pros/cons, and especially for cons, Nagios has no details on display map unlike Cacti, and also has no support on SNMP built-in features for auto-discovery. One of its disadvantages is that it has no support on database such that to query pre-dated statistical information may not be feasible, in which NetHAM [6], the forked Nagios, offered in terms of XML-based file format using AdobeFlex to display. Regarding an auto-map function, OpenMMS outperforms Zenoss in terms of accuracy with the complexity trade-off. Cacti itself does not provide the auto-map function although it provides the simplicity and easy-to-use/install function. tice that a weather map module [7] offers the user-defined manual map built into Cacti; however, it still lacks the auto-map function. Considering research-based network management proposals, W. Singhabut et al. [7] proposed the algorithm, Dynamic Network Map (DNMA), to discover networking devices to avoid the networking loop within the local network. However, there is no support on Web configuration and a lack of database-support as Nagios. W. Kersri [8] proposed the prototype of NMS using SNMP and ping/port checking functions to monitor both managed and unmanaged devices. P. Pitaksateanskul [9] proposed the module to monitor the performance of routers using SNMP resulting in the statistical display via web browser. P. Jirapanichakul and S. Huntakul [20] proposed the prototype for WLAN management via Web service. In addition, C. Maharak [2] applied the webbased network manager to utilize SNMP and ICMP to monitor the network. However, none of these approaches offers the automatic map function resulting in a complete networking map displayed via Web. In addition, they provide no details on an automatic discovery process. Consider NMS requirements. Although X. Wang et al. [22] proposed the NMS framework according to FCAPS, there is no implementation and/or analytical analysis. From various techniques discussed above, notice that there are advantages, but some useful techniques aren t considered probably depending upon the user requirement and technology inadequacy. As a result, we have proposed a new system to collaborate necessity features, especially automatic discovery/map processes, to make a simplified network management system, the so-called. III. SYSTEM ARCHITECTURE Web-based Automatic Network discovery/map Systems () is a plug-in module embedded into Cacti in order to complete necessity functions for Network Management System (NMS) requirements. tice that especially for auto-discovery/map purpose, this sub-module can be run individually excluding Cacti. Fig. shows Cacti architecture including a weathermap plug-in. Cacti consists of three main modules: Data Source, User Management, and Graph and Template. The data sources function as statistic collection. RRDTool is used to generate graphs based on statistical information. The user management is used for administrative purpose. (Fig. 2) enhances the traditional Cacti with a weather-map plug-in with many features as follows: ) Discovery Module: this function primarily performs the networking discovery process using ICMP and SNMP. There are two sub-discovery processes. The first one is for local discovery within the weather-map (in each sub-network); offers the local discovery feature to the networking devices to identify the type of those. Another one is to generate the entire map automatically. For auto-map purpose, the information after the discovery process is based on XML-format. This will be described again in details in Section IV. 2) tification Module: provides the user-defined configuration to send notifications/alerts in case the networking devices do not function properly. There are two alert methods: either by or by SMS services using Google SMS and Google Calendar API. 48

3 Weather Map Plugin Start Cronjob Data Sources Create an XML tree Script Command Cacti User Management Network Address Scan network address Host Addresses MySQL Database Graph & Templating Has next host address tification Module Service RRD Tool Fig.. Cacti Interaction Component SMS Service Google API GUI Discovery Module Servers Network s WMH Module Unreachable Send ICMP ping Is Alive Alive Add host detail to an XML tree Save an XML tree to a file End End of Scan t Alive admin XML Data File Fig. 2. Architecture Cacti Module Fig. 4. Flowchart: IP Discovery Process tice that PHP scripts are mainly used to control the interaction among modules. In addition, Crontab is optionally enabled to perform regular updates for up-todate networking information. Fig. 3. Port-based Status 3) GUI: this module is used to display all information via Web architecture such as networking device descriptions. This module also includes the display of networking maps using XML-based information. 4) Weather Map Helper (WMH) Module: this module provides accessory features to a weather-map plug-in. - Read/Write Function: instead of read-only for networking device statistics, offers a writeenabled feature to update the allowable information such as networking interface description, message of the day, and device name. - Port-based Display Status Function: users can verify the status of each port for a particular networking device, i.e., router and switch, indicated by different colors green when active and no color when inactive (Fig. 3). - Display Status Function: users can identify the status of networking devices whether they are in stable states or not (PC and Server). 5) Cacti Module: this module performs the interaction functionality with the traditional Cacti including collecting the statistical information into MySQL database. IV. AUTOMATIC DISCOVERY/MAP PROCESS In this section, we focus on the automatic discovery/map process. Fig. 4 shows the flowchart for IP discovery process, especially for local discovery (with a weather-map plugin) in that a whole sub-network will be scanned with ICMP ping features. If the device responds an echo-reply or unreachable message (in case some devices do not allow ping to get through), this IP address will be stored into XML database tree. Once feasible networking devices are available from XML tree information, Fig. 5 shows steps to identify the type of networking devices such as Router, Switch, Access Point, or Server. In this process, SNMP walk [3] is primarily used to acquire all related information. tice that this process is performed in recursive manner, especially for finding out completely connected interfaces to other networks using an ipaddrtable field. In addition, to properly specify the type of networking devices, sysdescr and sysname are used as identifiers in which users can manually pre-define the pattern in the configuration file; for example, if Linux and sysname is Access Point, this device tends to be an access point. 482

4 Start Start An XML file of network scan result Read an XML file Host Addresses Create an XML tree Has next host 2 ifconfig Find Current IP IP Check host type Send an SNMP Walk to host A SNMP Service available Read host information from SNMP sysname, sysdescr IP Send SNM P w alk to retrieve devive type type NMAP Scan for OS type Is WAP Sockopen to SSH, HTTP, RDP ports If any of these ports is open Access Point sysname, sysdescr Access Point Check host type Linux DD-WRT Linux and sysname is Access Point IP IP type name Send SNM P walk to get device name Add inform ation to XML tree Is Server, Switch, Router name PC Server Switch Switch or Cisco IP Extract interfaces data A ll Interfaces IP 2 End Router Router and sysname is Router Fig. 5. Flowchart: Local Discovery Process (with weather map plug-in) Interface IP Has next interface Add interface inform ation to XML tree <?xml version=.0?> XML Declaration <map> Root Element <time> </time> Executed Time <total-devices>4</total-devices> Total Discovered s de IP and Name <device IP= depth= 2 type= Server name= ns.police4.go.th > <interfaces> Interfaces Element <interface IP= /> Network Interface <interface IP= /> <interface IP= /> </interfaces> </device>... Next de </map> Fig. 7. Example: XML-based information for Arbor library For automatic discovery purpose for the entire network, Fig. 6 shows all steps resulting in proper XMLbased format information so that a networking map can be created by a graph visualization library using web workers and jquery (Arbor library). An example of XML-based file format is shown in Fig. 7. From Fig. 6, the automatic discovery process initially starts from IP address of router gateway of the server using ifconfig command. Then, a SNMP walk process is applied to figure out more information about connected networks including active IP addresses. After that similar to Fig. 5, the justification among the types of networking devices is performed. Finally, all these information are stored in XML-based file format so that Arbor library is applied in order to generate the entire networking map. Interface IP IP inform atio n Find connected devices Send SNM P walk to get device inform ation Add device inform ation to XML tree Save XM L tree to a file END Has next device Fig. 6. Flowchart: Automatic Discovery A ll connected devices IP inform atio n Is Server, Switch, Router V. PERFORMANCE EVALUATION In this section, we performed the evaluation process so as to justify our system performance. We only focus on discovery/auto-map processes. An automatic discovery speed, map-drawing display, and discovery coverage are our main metrics for comparison purpose. tice that although there are several proposals regarding to the network management systems (NMSs), some of them have limitations, and so incomparable to. For example, with Nagios [0], there is no built-in feature for an automatic discovery process. 483

5 Fig. 8. : Automatic Map For the forked Nagios, Netham [6], there is no detailed algorithm for the automatic discovery process. The network mapping process for Zenoss is manually performed, and the display map does not entirely represent the actual devices [2]. As a result, OpenMMS [3] and DNMA [7] are chosen as our evaluation candidates. Table I shows a comparative features among those three. For our testbed, the network management server ran over Debian i386 (Linux ): CPU Intel(R) Celeron(R) 2.80 GHz (256 KB Cache), 52 MB DDR-SDAM (400 MHz), Integrated Realtek RTL800C 0/00 BaseTX, and 80 GB Disk-ATA33. For OpenNMS, as a standard configuration, net-snmp, postgresql, java sdk: Tomcat (java servlet engine), rrdtool, and curl are included; and for DNMA, since there are no details of implementation tools, we followed its automatic discovery algorithm, and then applied into our existing configuration. For example, instead of Java, we used PHP and MySQL. tice that DNMA does not support Web-based display and lacking of automatic global map generation features. In addition, all devices for our testbed were used as a close system within the department of Information Technology, Provincial Police Region 4, Thailand. A. Experimental Setup We evaluated three main scenarios to test the system performance, especially the discovery/map process as follows. ) To show the system performance in details of automap processes, OpenNMS was chosen to perform the auto-discovery, and then the auto-map process was run. 2) To show the performance of discovery speed and coverage, we ran our system comparing to OpenNMS and DNMA with default configuration. There are two cases: the first one is limited by 5 second evaluation period so as to figure out the number of discovered networking devices. Second, we set up 20 ( ) and 30 ( ) networking devices scenarios consisting of Router (Firewall+L3 switch), Switch, Server, PC, and Access Point, respectively, and then we captured the completion time for the entire autodiscovery process. 3) To show the optimized results, we tuned up the configuration of OpenNMS such as limiting the number of retries to as well as timeout to 00 ms (these parameters are optimized from over multiple trials) and ignoring the service discovery process. tice that due to the limitation and availability of our testbed within the department, for the second and third scenarios including the number of testing devices, we ran over three experiments; the average (mean) and standard deviation were computed. B. Experimental Results The first scenario shows two maps from (Fig. 8) and OpenMMS (Fig. 9). In these figures, our system can display detailed networking devices, especially including the wireless access point properly (3 devices). The reason is because our auto-discovery process includes the pre-configured pattern to evaluate the specific type of networking devices. The second scenario shows the average and standard deviation of auto-discovery speed (Table II and III). With the time limitation (5 seconds), Table II shows that our system can discover up to 7 devices in average with less than 0. as a standard deviation. OpenNMS cannot find any devices (the first device found is at the 32 nd second). For DNMA, a number of found devices are limited to 4; the DNMA s discovery process cannot get through the firewall (tudtu.aaa.bbb.ccc); the process is terminated at time around 6.65 second. Additionally, Table III shows that in both 20 and 30 devices scenarios, OpenNMS spent discovery time over 3 times as much as that of for the discovery process. In the third scenario, the optimized configuration for OpenNMS, i.e., limiting the number of retries, timeout, and services, the discovery process reduced from 5 to around minutes. The main reason may be because of the complexity of the implementation that offers several unrelated functionalities of OpenNMS. 484

6 Fig. 9. OpenNMS: Automatic Map TABLE I FEATURE COMPARISON:, OPENNMS, AND DNMA Feature OpenNMS DNMA Language PHP Java Java Database MySQL PostgreSQL N/A Web-based N/A Network Map Algorithm Force-direct Layout N/A Discovery Result Format XML XML XML Configuration N/A N/A Alert /SMS N/A N/A Wireless Support (Defined- Pattern) N/A N/A TABLE II NUMBER OF FOUND NETWORKING DEVICES (WITHIN 5 SECONDS) Networking OpenNMS DNMA Router 2 0 Switch Server PC 2 0 Access Point #Total TABLE III DISCOVERY TIME VS. NUMBER OF DEVICES (20 AND 30) #20 OpenNMS #20 #30 OpenNMS #30 Router Switch Server PC Access Point #Total Discovery Time (min.) VI. CONCLUSION AND FUTURE WORK A new automatic network discovery/map system via Web architecture has been proposed in this paper, the socalled Web-based Automatic Network discovery/map Systems (), as an easy-to-use/install plug-in for Cacti, one of the network monitoring open-source software, as well as a weather-map plug-in module. embeds the networking discovery process which includes the user-defined matching rules in order to specify the networking devices properly. In addition, after the discovery process, an XML-based output is to feed into a graph visualization library using web workers and jquery so as to automatically redraw the entire networking map with a force-directed layout algorithm. The comparative results show that the system outperforms other techniques, i.e., OpenNMS and DNMA, in both networking discovery speed and device coverage criteria. tice that in this paper, we experimentally performed the evaluation process over the controlled testbed within the department of Information Technology, Provincial Police Region 4, Thailand, due to the limitation and availability of the authorized administrative domain. However, similarly, other testbeds can be evaluated as well for further study, especially for scalability purpose. Although the system can be easily integrated with Cacti, similarly to a weather-map plug-in, our future work is to embed/integrate this auto-map function into the weather-map plug-in directly so as to provide detailed statistical information. Thus, the administrators can perform similar functions directly into this module rather than using this as the preliminary maps. REFERENCES [] ISO/IEC 0040, Information technology - Open Systems Interconnection - Systems management overview 998. Available at [2] D. Mauro and K. Schmidt, Essential SNMP, O'Reilly Media, 464 pp., [3] S. Southier, Ed., Management Information Base for the Internet Protocol (IP), RFC 4293, [4] P. Moceri, SNMP and Beyond: A Survey of Network Performance Monitoring Tools, Available at net_traffic_monitors2.pdf [5] C. So-In, A Survey of Network Traffic Monitoring and Analysis Tools, Available at net_traffic_monitors3.pdf [6] Cacti. Available at [7] Weather Map plug-in (Cacti). Available at [8] Arbor, A graph visualization library using web workers and jquery. Available at [9] J. Hughes, Open-source network management download comparison, Available at [0] Nagios. Available at [] MRTG. Available at [2] Zenoss. Available at [3] OpenNMS. Available at [4] Hyperic. Available at [5] K. Meesublark, C. Aitsariyapat, and K. Sripanichakulchai, Comparison of Network Management Software (OpenSource), Available at [6] T. Kongpool, C. Aitsariyapat, and K. Meesublark, NetHam (Network Health Analysis & Monitoring, In Proc. of ECTI-Conf. on Application Research and Development, [7] W. Singhabut, C. Tangtongjan, and S. Kumanee, Dynamic Network Map Algorithms, In Proc. of National Conf. on Computer Information Technologies, 200. [8] W. Kerdsri, A Prototype of Completed Network Management System Using SNMP and Ping/Port Checking for Monitoring of Managed and Unmanaged s, In Proc. of Int. Joint Conf. on Computer Science and Software Engineering, [9] P. Pitaksatieankul, Program for Checking Router Performance Under SNMP Environment, Thesis, King Mongkut s University of Technology Thonburi, Available at [20] P. Jiyapanichakul, Prototype Development of Wireless LAN Management System, Dhurakijpundit University, Available at [2] C. Maharak, EMBEDDED WEB-BASED NETWORK MANAGER SYSTEM, Thesis, Chulalongkorn University, Available at [22] X. Wang, L. Wang, B. Yu, and G. Dong, Studies on Network Management System framework of Campus Network, In Proc. of Informatics in Control, Automation and Robotics, pp ,