24.4.1999
Jani Mäkelä
Computer Engineering Department
Helsinki University of technology
Jani.Makela@hut.fi
In the world of exponentially growing public IP networks both the commercial and public organizations are faced with the challenge of managing the heavy investments to network infrastructure. Nowadays, network management is a central issue in building every professional network solution. Cost reduction, multi-vendor interoperability and the ability to tailor the network to meet the needs of the organization are business goals that drive the development of management technology and standards.
Currently the internet management model based on Simple Network Management Protocol (SNMP) is the dominant management technology for public IP networks. The philosophy of minimum requirements for introduction of network management functionality to network elements has made the SNMP based technology the de-facto standard for public internets.
This paper contains the core information about management of public IP networks. The information is presented from different points of view ranging from business goals to higher level technical considerations. A special attention is given to the SNMP based management model with an analysis of its virtues and vices.
2 Objectives for management of public IP networks
3 The Internet management model
4 Simple Network Management Protocol (SNMP)
5.1 Structure and identification of management information (SMI)
6 Inside SNMP managed network element
Network management is a central issue in building every professional network solution. In the past the monitoring, control and configuration of network infrastructure was accomplished with independent and often vendor specific tools. The exponential growth of public IP networks and increased complexity of network technology made that approach to network management unfeasible. Two major management technologies for internetworks emerged practically simultaneously. Originally the technologies were developed to address two separate domains of network management. A technology based on CMIP protocol was developed for system level solutions and another - simpler - technology based on SNMP protocol for box-type solutions. Today, the SNMP based technology is the only one that remains, except for the absolutely largest system solutions.
The discussion about management of public IP networks begins with setting objectives for the management solutions from both the business and functional points of view. The most fundamental aspects of public IP networks are also covered. The following discussion introduces and analyses the internet management model and related aspects. The architectural framework, management protocol and management information are presented in their respective chapters. The considerations that arise when building a SNMP managed network element are presented as a practical example.
Networks and distributed systems have become vital resources both in the business world and lately also for the public communities. To fully exploit the expensive network investments organizations must be able to manage them. We begin the discussion about network management by presenting the four most fundamental business objectives for network management. [4]
All network elements have a primary functionality that they are responsible for in the network. Regardless of the management functionality the elements must be able to provide that primary service (e.g. routing of IP packets). However, the service must be somehow initialized, configured, monitored and controlled - this is the domain for network management. The objective for network management has been coined into a requirement to provide more effective, user-friendlier, standardized and flexible way to implement the management functionality.
Designing networks is difficult and anticipating future requirements is even more difficult, if not totally impossible. Therefore it is important to design the networks so that they allow flexible changes and modifications in order to meet the requirements emerging after the network deployment. Network management offers a possibility to have an increased control over the network elements so that the requirements can be met with changes in the network configuration and structure.
Users are naturally interested in best possible network service at the lowest possible price. One of the means to reduce the price of network solutions is to divide the development costs between as many users as possible, which implies more general purpose design solutions targeted to larger audiences. The problem with general-purpose solutions is that they cannot provide the best possible service for all users without some kind of adaptation. Network management offers a cost-effective way to customize the network after installation to provide the required level of service.
All software and hardware components are potentially faulty and their failures cause network downtime and reduction in network availability and efficiency. Such faults cause often large unanticipated costs that users want to minimize. Network management provides a way to anticipate and react to faults with error correlation, isolation and elimination so that the impacts of the failures are minimized.
In the past the monitoring and controlling interfaces were implemented per-vendor basis, which resulted in numerous incompatible forms of implementing the management functionality and a strong dependence to specific vendor. Users do not want to tied to single vendor solutions and therefore require open interfaces that allow interoperability between network elements of different vendors.
As network software and hardware manufacturers want to keep their own enhanced interfaces proprietary, the way to provide the required interoperability is through network management. Network management allows flexible interoperation of products from various vendors through standard interfaces.
Organizations build networks with ever growing size and complexity. Management of these resources becomes gradually more complex and sets new requirements for network management solutions. A large network cannot be implemented and managed only with human resources, because the complexity and distributed nature of the networks. Network management offers standardized tools to monitor, control and configure the networks even remotely and automatically - thus reducing the complexity.
There are many approaches to categorize the functional objectives of network management. One of the most well known and accepted is the ISO "FCAPS" model of functional areas of management. FCAPS is an acronym of Fault, Configuration, Accounting, Performance and Security Management. [9]
Fault Management. The goal of fault management is to detect, isolate and correct network problems so that the network keeps running effectively. In addition, fault management is responsible of notifying network operators about faults and recovery actions taken. Because faults cause downtime, network efficiency degradation and reduced availability the fault management is one of the most important and implemented functional areas of FCAPS.
Configuration Management. Configuration management is perhaps the most important area of network management because the management of the network configuration is a basis for other management operations. The objective of configuration management is to monitor and control network configuration so that coordinated control over software and hardware additions, deletions and modifications can be achieved.
Accounting Management. The objective of accounting management is regulate user or group based network utilization parameters. The purpose behind the main objective is to minimize the overall network utilization problems and provide fair share of network resources to users.
Performance Management. The objective of performance management is to measure and provide access to network performance information so that network performance can be kept in acceptable level. Based on the gathered performance information operators can find bottlenecks in the network, anticipate potential faults and decide on the improvements needed.
Security Management. Security management is used to control the security functionality that protects the network against sabotage and unauthorized access to restricted information in the network.
Public internetworks are growing rapidly. The amount of hosts attached to internets is considerable and will experience even more intense growth in the near future. This implies that the management system must take into account that the environment is much more complex than the system alone. The rapid growth has also lead to a lack of common policies and the basic protocols acting as the only common denominator. The following sections present some of the main aspects of internetworks that have implications also for the management solutions.
Internets are by definition networks of multiple heterogeneous hosts and routers with common communication protocols. In addition, the internets of internets (especially the Internet) consist of multiple autonomous and separately owned and administered domains.
The dominant network protocol in public IP networks is Internet Protocol (IP). IP is connectionless, best effort service that offers very good efficiency for message transportation. It is unreliable and must therefore be complemented with a retransmission policy if reliable operation is required. From the network management point of view the best-effort IP complemented with User Datagram Protocol (UDP) is appropriate, because the network management solutions are often distributed geographically and must communicate over potentially expensive WAN connections. Therefore the connection between the management entities can not be continuos and connectionless protocol is well suited for these purposes.
Internets are insecure. When multiple hosts and routers have access to a common internet they are all potential security threats. The basic Internet protocols like IP, UDP, TCP do not contain security features. Therefore the network management protocols must implement or be complemented with security functionality such as authentication, access control and encryption. Older network management solutions have implemented security solutions in a simple way with light security. This has lead to a fact that most network management solutions offer extensive monitoring capability for the network elements, but potentially risky control operations are limited to other more secure protocols.
The IP protocols are standards for all network elements in the internet. Everything else is left to be decided by the users. Therefore internets often do not have a unified architecture. This implies the fact that network management must be able to cope with this lack of common architecture and offer flexible compromised framework for all feasible architectures.
The internet management model, also known as SNMP management model, is currently the dominant technology in IP networks. This chapter provides a technical overview to the model describing the architecture, management information and protocol in their respective sections.
The fundamental philosophy behind the internet management model is to create a management framework with minimum requirements so that management can be introduced to the simplest of devices and therefore to allow a uniform and universal management solution. This philosophy is both the cornerstone of the success of the internet management model and greatest source of problems. This paradox is discussed in the following chapters. A set of technical objectives for the model has been derived from the business goals and functional objectives coined in the earlier chapters. [5]
The internet management model is defined in a collection of standard IETF administered RFC documents. The documents define a management framework that consists of four major components.
The documents currently contain extensive management information descriptions, but the definition of the overall architecture is incomplete and ambiguous. Recently a lot of work to define the architectural approach and framework has been done and the latest versions of the standard documents contain much more precise and complete definitions in this area. [3]
The internet management architecture consists of management entities with defined responsibilities. The standards define the high-level aspects of the entities and leave the implementation dependent details to the implementers. The following figure represents a conceptual summary of the internet management architecture.
Figure 1. The internet management model architecture. [10]
The Manager is responsible of providing network wide access to the management information in the managed entities deployed in the network. It can offer a user interface and some automatic operations through which the network operators can monitor, access and modify the management information in the network. It can also offer standard interfaces for network management platforms that provide autonomous or added-value network management functions.
The Agent is responsible of providing access to the management information (MIB) of the network element that the agent is responsible for. It provides a standard management protocol interface (SNMP) for operations initiated from the manager and the unsolicited event messages (SNMP traps) from the network element itself. It can also provide access and security functionality to protect the management information from unauthorized access and use.
The Management Protocol is responsible of the transfer of management information between the managers and the agents. A strict and simple protocol standard allows full interoperability between management entities from different vendors and management domains.
The Management Information Base is a conceptual distributed database in each network element. It contains all the management information related to the network element. The central resource from management point of view.
The Management Instrumentation is responsible of encapsulating the actual form of the management information within the network element and providing the access to the actual variables, services and operations that constitute the management information. The management instrumentation interfaces are not defined in the internet management model, but are left to be decided by the implementers.
Simple Network Management Protocol is the language spoken between the network elements and managers located in manager. It is a simple request-response -type protocol where the agent in the managed network element acts as a server and the manager as a client. There are two major versions of SNMP protocol (SNMPv1 and SNMPv2) and a third version is under development. The first version of the protocol has the largest installation base even though the second version has been available for quite some time. The reasons for this situation are explained in the following sections.
The most characteristic feature of SNMP protocol is the explicit simplicity with strictly limited number of operations and transport mapping. This simplicity allows straightforward and lightweight implementation of the protocol, but is also a major obstacle when complex systems are modeled. Modeling complex systems is quite difficult, because for example object oriented modeling concepts such as inheritance, encapsulation and containment are difficult to implement to be operated with the simple operations. On the other hand, simple model enables construction of harmonious, widely accepted information models that are easy to implement.
SNMP has basically only three different types of operations that can be used to handle scalar objects that constitute the management information. The operations are used to retrieve and modify the values of the management information and to report events. There are no action-type operations defined in SNMP. The actions must be encoded as trigger functions related to the modification of the values of certain pieces of management information. There are not create or delete -type operations either. The management information structure is rather static and the manager cannot create or remove object instances. The existence of objects must be encoded as state information that specifies whether the object exists or not. [5]
Get-operation. The manager can ask the current value of a uniquely identified piece of management information. The operation is initiated by the manager and results in a response message containing the corresponding value from the agent. The get -operation is mainly used for monitoring purposes (e.g. the operator can query information about the network element and make decisions based on that information).
There are three distinct types of get -operations. Plain get-operation queries strictly specified piece of management information. Get-next-operation can be used to traverse the whole management information tree without knowledge about the structure (the operation returns the corresponding values that lexicographically follow the specified pieces if management information). Get-bulk -operation (introduced by SNMP v2) is like plain get-operation, but allows a large amount of information to be transferred in single message. This was found very useful, because the manager often queries whole sets of information which would otherwise result is multiple small messages and result in consumption of network bandwidth.
Set-operation. The manager can set the value of a piece of management information. This operation is also initiated by the manager and results in a response message indicating the success of setting the values. The set-operation is mainly used to control and configure the network element by setting the operational parameters and initiating trigger functions in the network elements (e.g. the operator can order the network element to restart so that normal operation is reached after a failure).
Trap-message. The agent in the network element can use a trap message to inform the manager about a significant or exceptional situation. The trap sending operation is initiated by the agent and can result in event logging or warning in the manager (the resulting actions are not specified by SNMP standard). SNMP v2 defines also an inform message that is used for communication between managers.
The restrictions described above make SNMP very simple and easy to implement for devices with limited resources. On the other hand, the simplicity makes the design of management information and operations difficult, because object-oriented operations offered by other management models must be encoded with the simple mechanisms available. Practically this simplicity has resulted in considerable simplicity of the MIBs as well - complex operations are not implemented and the network management interfaces are kept simple and restricted.
The manager and the agent communicate with SNMP messages that are interpreted as one of the operations described earlier. The messages are encoded as standard SNMP PDUs that are wrapped in UDP (or other transportation protocol) messages. The header of the message specifies the protocol version and the type of the operation according to which the agent can commence the correct action. In SNMP every operation operates on one object instance only. However, the SNMP message can contain multiple operations for distinct objects. It is recommended to collect operations on objects that are strongly related to each others to a single SNMP message so that atomicity of the larger operation is guaranteed.
Figure 2. The SNMP protocol stack.
The following list describes the basic handling of SNMP messages
In the manager:
In the agent:
Trap messages are mapped in a different way to transportation protocol messages. The most important information in a trap message is the identity of the trap and the related information. The agent maps the trap message to UDP PDU and sends it to the manager.
The security aspects of protocols have become increasingly important in modern internetworks. This section introduces shortly the security of SNMP protocol.
Version 1 of SNMP is not secure. It has a so-called security mechanism that is based on community strings that are sent in clear-text in the network. The community strings restrict the access to operations (read/write/read-write) and visibility of the management information for each community respectively. The fundamental insecurity of this authentication mechanism is one the most profound problem with SNMPv1. This has resulted in restricted design of available management information that contain only safe readable objects and practically no writable objects.
The second version of SNMP includes two types of security models which are not discussed here, because that version of the protocol has not gained a lot of appreciation, because it is different from the first version, but does not offer enough new features to justify implementation. The security model is based on Digest Authentication Protocol and Symmetric Privacy Protocol (and the information is encrypted with DES).
The third version of SNMP protocol is under development. It shall contain advanced security features mainly based on the ones specified in the second version of the standard.
The internet management model offer both a simple implementation of management functionality, but also a possibility to extend the simple framework with new services and information definitions. The purpose of SMI standard is to define the overall structure for management information hierarchies and representation of the information in an extensible format. The standard defines a concept of a virtual information store called Management Information Base (MIB). The MIB contains a set of uniquely defined managed object types that are set available through the MIB implementations in network elements. The managed objects are defined using a restricted set of ASN.1 descriptions.
Every object is defined to have a name, syntax and encoding. Names are used to identify objects. The name defined by SMI is called Object Identifier (OID). OID is a sequence of integers which traverses a global name tree [Figure 3]. The names are hierarchical by definition and practically unlimited amount of possible names is available. The syntax defines the abstract ASN.1 data structure for that object type. An object can be a simple integer value or a sequence of octets, for example. The encoding specifies how instances of that object type should be represented when mapped to transportation layer messages. For this purpose basic encoding rules for ASN.1 are used. [6]
The word MIB is used ambiguously to mean the collection of all management information in the global MIB tree, single MIB document or part of such document. In this text the MIB is a textual definition file that defines certain groups of managed objects. The MIB is a rather static definition (or class definition) that is interpreted in manager only once and therefore defines also the end user view to the management information. It can be seen as a class description that is instantiated to network elements that share similar characteristics.
Figure 3. Part of the object identifier namespace used to name MIB variables.
There are tens of standard MIBs available with thousands of managed objects. In addition, different network element vendors have their own proprietary MIBs. The problem with the SNMP MIBs is that there is no kind of classification available. The MIBs are independent collections of related managed objects and the sheer amount of them is becoming an obstacle for handling the information. The good side in this independence is that the network element developers can select just the group of MIBs needed for the element to be properly managed. The problem with many other management models is that they require implementation of large object structures even thought they are not used at all, which results in agent sizes that are ten times bigger than an average SNMP agent.
The MIBs are the most valuable resources in the SNMP management framework. They contain the essential management information about network elements gathered during the years of design and field test experience.
MIB-II is the second version of the core configuration and fault management information for hosts and routers. It contains the objects needed for the management of the fundamental internet protocols and most common aspects of network elements and therefore has become one of the most commonly implemented standard MIBs. The designers of MIB-II had a set of criteria according to which the objects were selected to MIB-II. The criteria are presented here to provide an example of requirements for MIBs.
MIB-II consists of eleven groups (of which nine are in active use). The following list [Table 1] gives an overview of the content of the most important groups in this MIB. [7, Figure 3]
Table 1. MIB-II groups|
System group |
System group provides common information about the system - features that are existent in all network elements (e.g. sysLocation object describes the physical location of the device). |
|
Interfaces group |
Interfaces group provides information about the various interfaces on the device (e.g. ifNumber describes the number of the interfaces). |
|
IP group |
Contains IP protocol related information (e.g. ipForwarding describes whether the device acts as a router or not). |
|
ICMP group |
This group provides information about the ICMP protocol (e.g. the counters of various ICMP messages). |
|
TCP group |
This group provides information about the TCP protocol (e.g. tcpConnTable contains the information about the current TCP connections). |
|
UDP group |
Information related to UDP protocol (e.g. UDP ports that allow connections). |
|
EGP group |
Contains EGP protocol information. |
|
SNMP group |
This group provides information about the SNMP protocol itself (e.g. snmpInPkts describes the SNMP packets received by the device). |
Remote monitoring is a relatively new addition to the series of standardized MIBs for network management. Devices called monitors and probes are instruments that exist in the network only for monitoring and controlling purposes.
Figure 4. The remote monitoring architecture.
Remote monitoring MIB defines objects that constitute the interface between a RMON agent (probe) and a RMON manager [Figure 4]. The objects are designed to be handled internally by the management application and are not suitable for direct manipulation by human users. RMON MIB contains many objects that are well suited for managing all types of networks, but it also dedicates a set of object for Ethernet networks. [8]
The RMON standard document lists the following goals for remote network management. The set of goals addresses the problems of managing very large distributed networks remotely.
Offline operation. In a large, geographically distributed network the manager cannot be continuously in contact with the remote monitoring devices. Attempts to minimize communication costs and use of overall network bandwidth over a WAN require offline operation. The remote monitoring probe can be configured to collect statistics and perform diagnostics continuously, even when the communication to manager is not possible or efficient. The probe works autonomously until an error condition is detected which will result in notification of the managers.
Proactive monitoring. As the probe is often dedicated for the management purposes it can run diagnostics and log network performance continuously and store the information in the limits of the resources available. In case of failure in the network the information can be uploaded and played back to find out the original cause for the failure. The probe can be configured to notify the manager when a failure has occurred and the human operator can then use the historical information to find out the cause for the malfunction.
Problem detection and reporting. The monitor can be configured to recognize different types of conditions and to notify the manager about them. Especially important category of conditions is erroneous situations and conditions that potentially cause a failure later.
Value added data. Because the remote monitoring device often dedicates all it's resources for network management functions only, it can use the available resources to give added value for the information collected from the network. It can combine, highlight, transform and compress the information in a more useful form.
The MIB contains a set of objects and traps that provide the service specified above. The objects are arranged into ten groups [Table 2] some of which are general purpose and some are Ethernet specific. The groups are all marked optional so that a remote monitoring device can implement any combination of the groups.
Table 2. Remote Monitoring MIB groups|
Ethernet statistics group |
Statistics measured by the probe for each monitored Ethernet interface on this device. |
|
History control group |
Controls the periodical sampling of statistical data from various types of networks. |
|
Ethernet history group |
Periodical samples from the Ethernet network operations. |
|
Alarm group |
Takes periodical samples from the variables in the probe and compares them to defined threshold levels. An event is generated if the variable crosses a threshold. |
|
Host group |
Statistics associated to with each host discovered on the network. |
|
HostTopN group |
Information about hosts ordered by one of their statistics. |
|
Matrix group |
Information about the communication between two addresses. |
|
Filter group |
Allows packets to be matched to filter equations. |
|
Packet capture group |
Allows packets to be captured when flowing through a specific channel. |
|
Event group |
Controls the generation of events from this device. |
As a practical example this chapter introduces the considerations related to implementing a SNMP managed network element. The basic philosophy of simple agents in SNMP model makes the implementation rather straightforward, but definitely not trivial. The following list of activities describes the process. [2]
Public IP networks experience currently their most intense period of growth and development ever. Organizations employ network management to their networks in order to exploit the heavy investments to the network infrastructure.
In the world of public IP networks a single management model is the de-facto standard of today. The SNMP model is currently by far the most common management technology in the public internets. Like many other Internet standards it has gained the dominant position through fast standardization, simple implementation and broad support from the Internet community. The fundamental philosophy of explicit simplicity is both its greatest virtue and vice. Simple implementation invites many developers to offer the standard interface, but makes the definition of the new network solutions requiring more complex information models unfeasible. Corba and HTTP based management architectures are gaining a lot of popularity in system level solutions.
In the perspective of three to five years no other management model poses a realistic threat to SNMP as the dominant management technology in public IP networks. The current installation base of SNMP is huge and the fundamental standards are widely accepted in the internet community. However, SNMP has to evolve to meet the needs of the new kind of network services or other models will take its place. Manufacturers of system level solutions are already looking for more capable management technologies. Another trend is towards distributed management solutions providing some degree of management automation with intelligent agents. The RMON standard is just the first step towards this direction.
|
[1] |
Active IETF Working Groups, 5.2.1999 [referred 24.4.1999] |
|
[2] |
comp.protocols.snmp SNMP FAQ Part 1 & Part 2, 17.1.1999 [referred 24.4.1999] |
|
[3] |
Perkins, D & McGinnis, E, Understanding SNMP MIBs [referred 24.4.1999] |
|
[4] |
Pras, A., Network Management Architectures, 2.1995 [referred 24.4.1999] |
|
[5] |
RFC 1157 - A Simple Network Management Protocol [referred 24.4.1999] |
|
[6] |
RFC 1155 - Structure and Identification of Management Information for TCP/IP based internets [referred 24.4.1999] |
|
[7] |
RFC 1213 - Management Information Base for Network Management of TCP/IP based internets: MIB-II [referred 24.4.1999] |
|
[8] |
RFC 1757 Remote Network Monitoring MIB [referred 24.4.1999] < http://wwwsnmp.cs.utwente.nl/ietf/rfc/rfcbytopic.html> |
|
[9] |
Stevenson, D., Network Management What it is and what it isn't, 4.1995 [referred 24.4.1999] |
|
[10] |
Simple Network Management Model, 1989 [referred 24.4.1999] |