Relational Network Manager for IP Networks

Transcription

1 Relational Network Manager for IP Networks Yuri Breitbart, Deepakraj Shanthilal Department of Computer Science Kent State University Kent, OH Abstract This paper deals with an issue of effective network management for an enterprise IP network. It focuses on SNMP based protocols that are widely used in current network management. The major problem with the SNMP based network management is that it does not provide network managers with a unified picture of the network when the network manager may query the network from several SNMP tables with a single request. Furthermore, SNMP does not provide network manager with historical network information. In this paper we propose a new network management tool that is also based on SNMP but uses a relational database approach to the storing and accessing the SNMP data. Our tool uses SQL query language to access network information and allows network manager to keep network historical information. The major advantage of our tool is in guaranteeing scalability and network data management data consistency. Key Words: Network Management, SNMP, MIB, Relational Database, IP Network I. INTRODUCTION In this paper we deal with an important issue of effective network management for an enterprise IP network. The effectiveness of network management critically depends upon the availability of network information collected from different network nodes. A timely collection of such information is a difficult and important task. Most current network management systems use a Simple Network Management Protocol (SNMP) [7], [5] designed in the late 80 s. The SNMP based network management architecture shown in Figure 1 includes entities of two types: SN M P M anager and SNMP Agent. An SNMP manager is normally located at a single network node - network management site (NMS) - and collects information from SNMP agents located at network nodes. In addition, an SNMP agent may send notifications about the node status to the SNMP manager independently of the SNMP manager s requests. An SNMP agent extracts the network management information from Management Information Base [8] (MIB) variables that are stored at the node where the agent is located. An MIB has a hierarchical structure in which each MIB table is placed at the MIB leaf node. An SNMP based network management has a number of important advantages. Among them are: 1. SNMP is a standard protocol and, consequently, it is easier to ensure the interoperability of network element management systems each of which manages a separate network node. 2. The SNMP protocol allows the settings of traps in network nodes to notify an SNMP manager about events of interest to the manager. 3. Applications that use the SNMP protocol do not require making any changes in the network element management software. There are, however, several problems with SNMP based network management. 1. Due to the hierarchical structure of an MIB, the SNMP protocol does not provide any tools to query several MIB tables with a single command or, alternatively, to select only specific columns from a given MIB table. Consider, for example, requesting information on a system name of all next hop routers for a given IP address. This requires

2 Fig. 1. Conceptual View of the SNMP Based Network Management submitting an snmpwalk command to select all next hop IP addresses, and then for every next hop IP address another snmpwalk command must be submitted to extract the next hop system name. Similarly, requesting MAC addreses of each router port along with a port description currently results in the selection of a complete ift able after which a selection predicate is applied to the retrieved result in order to obtain the requested information. This process is cumbersome, time consuming, inefficient, and generates a significant load at the network elements that execute SNMP commands. 2. There are no tools to preserve consistency of retrieved MIB information. The difficulty is that querying MIB tables with different SNMP commands cannot assure the synchronization of information from these tables. Consider, for example querying ipnettomedia and iproutingtable tables by submitting two snmpwalk commands: one for querying an ipnettomedia table and another for querying iproutingtable table. Since both tables are located in the network node memory (as shown in Figure 1), some information from an ipnetto- Media table could have been cached out at the time when application queries the iproutingtable table. 3. The SNMP protocol cannot access any historical information about the network. This is due to the fact that MIB is located in the memory and the MIB information that is cached out of MIB is no longer accessible. 4. The SNMP protocol was mainly designed for managing the network at the network element layer as opposed to the network layer. Consequently, managing the network at the network layer using the SNMP protocol presents a difficult challenge. 5. Finally, scalability (or a lack thereof) is a well known problem of the SNMP protocol. While the overhead that SNMP imposes on network traffic is minimal, the time the network element spends on servicing SNMP commands is unacceptable high and, as a result, many network managers restrict SNMP access to their nodes. This situation clearly mandates the development of an effective, general-purpose network management tool that guarantees the synchronous access to MIB information in the network. This tool should be based on the industry standard SNMP protocol but should address the drawbacks described above. In this paper we describe one such tool. Our tool uses a fully functional SQL language to access network management information either at the network node or at the backend relational database that contains the most recent MIB information as well as historical MIB information. Figure 2 depicts the conceptual architecture of network management based on our approch. The database is located at the network management site. The MIB hierarchical structure is converted into a relational database structure. Network Monitor periodically updates the database by monitoring network elements in the background, MIB changes since the last update. Alternatively, using SNMP traps, a network node sends updated information to the monitor which, in turn, updates the backend database. Consequently, the issue of scalability

3 on a backend machine only. In a rare case, when the latest MIB information has not yet been propagated to the database, the database loader module extracts the latest data from the MIB and these data are propagated to the database. The issue of network management at the network layer becomes much easier to resolve since the network manager can access several network nodes and display their status with a single query or a query script. Fig. 2. Conceptual View of the SNMP Based Relational Network Manager does not arise since most of the managers queries can be answered using the database information without going to the MIBs. This relieves a network node from processing network management requests and further reduces the network management traffic. Network manager requests are formulated in the SQL language and as such the queries may include many join operations as well as aggregate functions. Thus, the issue of selective access to the MIB information is resolved. Using a full fledged database management system resolves the issue of data consistency for data retrieved by the network manager. The issue of synchronous database access is resolved by accessing the database directly The idea of converting the hierarchical structure of MIB into a relational database has been discussed in several papers [1], [3], [4]. In [1] the authors discuss a conversion of MIB into a SQL database where each MIB table is converted into a relational table. However, the issue of how to relate tables from different MIBs is not addressed there, since their language does not admit several MIBs into one relational database, which is the approach we take in this paper. In [3] the authors mainly discuss the MIB software and do not directly address the issue of conversion of MIBs into a relational database. They review several software tools that are based on the SNMP protocol and discuss their advantages and disadvantages. In [4] the authors discuss an application of XML to describe MIBs. They argue that XML documents can serve as an excellent tool for exchanging data between different network nodes. However, the issue of integrating data from MIBs of different nodes is not addressed there. Recently, ORACLE released their network manager application [6] which is collecting data from different MIBs into a single relational database. However, their tool does not address scalability issues. That is, the main goal of their application is to keep historical data in the database. The issue of automatic data refresh is not addressed there. The remainder of this paper is organized as follows. Section II reviews necessary background information and presents the conceptual architecture of our system. Section III discusses implementation issues and the current state of the system. Finally, section IV, discusses remaining challenges and concludes the paper.

4 Fig. 3. Examples of Database Table generated from MIBs II. MODEL AND ARCHITECTURE Our model includes two major components: backend relational database and data collection/data refreshment architectures. We describe these components below. A. Database A backend database is a relational database consistng of several relations. The database includes a special inventory table that contains IP addresses of all network nodes along with their interconnections. To collect such information each node entering the network broadcasts its IP address to all other nodes including the NMS site. The Network Monitor, upon receiving a new IP address begins to monitor a newly integrated node. In addition, the system periodically runs a network discovery program that probes every possible IP number allocated to the network manager. In [2] we discuss in detail how to create and maintain the inventory table. The other relations in the database describe various MIB-2 tables (such as system, interfaces, ip, ipaddr, iproute, ipnettomedia, icmp, tcp tcpconn tables, and many others). For example, the ipaddrtable contains the following attributes: IPaddress, ipadentaddr, ipadentifindex, ipadent- NetMask, ipadentbcasraddr, and ipadentreasm- MaxSize. Some of other tables are illustrated in Figure 3. Fig. 4. Conceptual Architecture of Relational Network Manager A primary key of the inventory table is an IP address. The primary key of each MIB relation is the primary key of the MIB table concatenated with the IP address of the MIB. For example, the primary key of the ipaddrt able table of node a is an IP address of a and ipadentaddr of the specific interface of a. Each tuple in each relation includes a timestamp that indicates the time that the record was downloaded from the network MIBs. Each time that the Network Monitor sends the new data to the Database Loader, the Database Loader updates the timestamp of the records that have changed. B. Relational Network Manager Architecture The relational network manager architecture is depicted in Figure 4. The User Interface accepts user requests submitted either in the form of a SQL query or a query script. All query scripts are stored in the script library. Each script describes a specific function of a network manager. For example, there is a script that allows displaying a network status of a specific subnetwork, its utilization, and its fault rate. The User Interface forwards the user request to the Scheduler. The Scheduler role is to decide whether the request can be satisfied with the information from the database, or the database needs

5 to be refreshed with the MIB data from network nodes, or a combination of both. The Scheduler upon receiving the user request, verifies whether the database contains the data timestamped with the timestamp that is sufficiently close to the timestamp of the request. If the request timestamp is smaller than the timestamp of the requested data, the Scheduler verifies whether the requested data was updated after it was loaded to the database. If the data was updated, the Scheduler schedules a request for the updated data to be submitted directly to the network node s MIBs. Otherwise, the request is submitted to the relational database manager (ORACLE 9 ) for processing. The relational manager processes the request and displays the result on the network manager display. As previously stated, in some cases, the user request ask for some data directly from the node s MIB. While the data is periodically updated by the database loader, it may happen that the request occurred just between two periodic updates of the database. If the network manager request requires direct access to several MIB tables, then the request is forwarded to the SNMP Request Generator. The major role of the SNMP Request Generator is to translate the query into a set of SNMP commands, to submit these commands to the node s MIBs, to collect results of these commands, and pass them to the Scheduler. The Scheduler passes them to the Database Loader to insert the new data into the backend database. The SNMP Request Generator generates a set of snmpwalk, snmpget, and snmptable commands, submits them to the respective MIBs and monitors their execution. After receiving responses from the node s MIBs, the SNMP Request Generator sends them to the Scheduler, which, in turn, translates them into a set of update statements and sends them to the Database Loader for execution. At the same time the results of the user request are displayed at the network manager station. To illustrate, let us consider the following example. Suppose that the network manager for a given IP address, IP 1, wants to find a system contact for every node that is the next hop in the routing table of IP 1. Further, suppose that the inventory table contains the following IP addresses: IP 1, IP 2, IP 3 and IP 4. Let system table contain system information for IP 1 and IP 2. Suppose that IP routing table contain IP 2 and IP 3 as next hops for IP 1, and IP 1 and IP 3 as next hops for IP 2. To obtain the information the netwoork manager submits the following query: SELECT IP, syscontact FROM Inventory, System, iproutetable Where Inventory.IP = iproutetable.ip and System.IP = iproutetable.ipn exthop; The Scheduler receives the above query and forwards it to the relational database manager for execution. Prior to that, each of the indicated join operations is replaced with an outer join operation. The result of the query is the following table: IP Contact IP1 Jay IP2 John IP3 - Since the information on system contact for IP 3 is missing, the Scheduler requests that information from the SNMP Request Generator which generates the following SNMP command: SNMP W ALK -c public IP3 system This command is submitted to the node with the IP address equal to IP3. After receiving the information from MIB, the SNMP Request Generator sends the results to the Scheduler which, in turn, generates the following update statement: update system set syscontact = George where IPAddress = IP3; and sends it to the Database Loader which, in turn, executes the command by filling in the system contact for IP 3 in the table above. The Scheduler reviews whether any other information needs to be obtaind from the database and if the request is completed, passes it to the user interface which, in turn, displays the result for the network manager. As we mentioned earlier, the Network Monitor collects the changes in all network MIBs since the last

6 database update and propagates these changes into the database. Clearly, the majority of MIB s variables do not change very often. For example, the sysname attribute is stable for the lifetime of the network node. Consequently, not all MIB variables need to be monitored. We choose to monitor only MIB variables of the type Counter. Other variable types are monitored only if there are changes in the network. For example, suppose some connections in the network have changed. This, in turn, results in changes of variables describing the connection. Since such changes are done by the network manager, the Network Monitor is automatically run after any network manager initiated network change. MIB variables of type counter are monitored by setting SNMP traps. We observe that not all counters can be monitored with the SNMP traps, since otherwise, traps may impose a significant network overhead. Consequently, we require that the Network Monitor periodically updates all counter variables into the database. The periodicity of such updates is selected by the network manager that on the one hand, wants to monitor these variables as closely as possible and on the other hand, does not want to generate a significant network overhead by downloading these variables. III. IMPLEMENTATION We have partially implemented the Relational Network Manager (RNM). In this section we describe the current state of implementation. The system is implemented under the RedHat Linux system using the ORACLE 9 relational database manager. We also used a publicly available SNMP protocol package. The system was tested in our lab that included 3 Cisco 7500 routers, 4 Avaya Cajun switches and numerous workstations and desktops interconnected into an autonomous network with access to the departmental network as well as university networks. The current version of our system does not include the Network Monitor that is is being implemented. We extensively experimented with the system. Clearly,the system even without the Network Monitor sigificantly reduces the network overhead at the network nodes. The main reason is that the majority of the network requests are answered from the database using ORACLE and the ORACLE s query optimization capabilities. The network changes are infrequent, thereby reducing the need for an extensive network monitoring. The situation changes dramatically, if the network goes through network faults that causes rapid changes in the network active paths. In such cases, the queries require the access to MIBs. We observe (using simulation approach) that the frequency of going to the MIBs critically depends on two parameters: frequency of the database updates and the the frequency of network faults. Database updates are caused either by the user after the new information is received from a MIB or by the network monitoring that sends a new update statement to the database. Network faults create much more serious problem. The reason is that a fault of some links can generate a cascading effect on the network, leading to massive changes to network node MIBs and as a consequence, these changes trigger changes to the database. During this process the database may contain inconsistent database. We are developing concurrency control algorithms that exclude user from getting the lates data. The user is informed that the earlier version of the data is available. The user then decides whether to use the earlier data version and possible to see an inconsistent network view, or to cancel the request. The research on these issues still continues. IV. CONCLUSIONS In this paper we describe the network management system which is based on two main ideas: 1. Current and historical MIB data for all network nodes are kept and periodically updated in the backend relational database system. 2. Network manager s requests are primarily handled by relational database manager (ORACLE 9 in our case). Consequently, the network management requests are optimized by query optimizer of ORACLE and directed to the backend database. This allows to

7 eliminate the network node overhead which is currently generated by handling MIB queries. In rare cases, when the request is directed to one or more MIBs, our system optimizes the number of SNMP commands requesting the information. There are still several issues that we continue to work on. Among them are: 1. Frequency of database updates with the fresh MIB data. 2. Semantic merge of MIB information from different network nodes. We have implemented a prototype of the network management system based on these ideas. Extensive experimentation with our prototype confirms clear advantage of our approach over a traditional SNMP based network management system. REFERENCES [1] Wengyik Yeong SNMP Query Language, Technical Report: , Performance Systems International, Inc., 1990 [2] Breitbart, Garofalakis, Rastogi, Seshadri, Silberschatz Topology Discovery in Heterogeneous IP Networks Proceedings of the INFOCOM 2000 Conference, [3] J. Schoenwaelder Evolution of Open Source SNMP Tools Proceedings of SANE 2002 Conference, May, [4] Jeong-Hyuk Yoon, Hong-Taek Ju and James W. Hong Development of SNMP-XML-based integrated network management International Journal of Network Management, 13: , 2003 [5] J. Case, M. Fedor, M. Schoffstall, and J. Davin, A Simple Network Management Protocol (SNMP), Internet RFC-1157 (available from May [6] Oracle SNMP Support, White paper (available from partners /snmp wp.html/. [7] William Stallings, SNMP, SNMPv2, SNMPv3, and RMON 1 and 2, Addison-Wesley Longman, Inc., 1999, (Third Edition). [8] K. McCloghrie and M. Rose, Management Information Base for Network Management of TCP/IP-based internets: MIB-II, Internet RFC-1213 (available from Mar