|
|
Simple Network Management Protocol
Simple Network Management Protocol (SNMP) is an application-layer protocol designed to facilitate the exchange of management information between network devices. By using SNMP to access management information data (such as packets per second and network error rates), network administrators can more easily manage network performance and find and solve network problems.
Today, SNMP is the most popular protocol for managing diverse commercial, university, and research internetworks. Standardization activity continues even as vendors develop and release state-of-the-art SNMP-based management applications. SNMP is a relatively simple protocol, yet its feature set is sufficiently powerful to handle the difficult problems presented by management of heterogeneous networks.
This chapter discusses two versions of SNMP: Version 1.0, which was the initial version of SNMP, and Version 2.0, which incorporates security features as well as improvements in protocol operations and management architecture.
In SNMP v.1, agents are software modules that run in managed devices. Agents have access to information about the managed devices in which they run and make this information available to network management systems (NMSs) via SNMP v.1. This model is graphically represented in
Figure 32-1.
Figure 32-1 : SNMP v.1 Management Model
A managed device can be any type of node residing on a network, including computer hosts, communication servers, printers, routers, bridges, and hubs. Because some of these devices may have limited ability to run management software (they may have relatively slow CPUs or limited memory, for example), management software must assume the lowest common denominator. In other words, management software must be built in such a way as to minimize its own performance impact on the managed device.
Because managed devices contain a lowest common denominator of management software, the management burden falls on the NMS. Therefore, NMSs are typically engineering workstation-caliber computers that have fast CPUs, megapixel color displays, substantial memory, and lots of disk space. One or more NMSs can exist on any managed network. NMSs run the network management applications that present management information to users. The user interface is typically based on a standardized graphical user interface (GUI).
Communication between managed devices and NMSs is governed by the network management protocol. The Internet-standard Network Management Framework assumes a remote-debugging paradigm, where managed devices maintain values for a number of variables and report those, on demand, to NMSs. For example, a managed device might keep track of the following:
If an NMS wishes to control a managed device, it can do so by sending a message requiring the managed device to change the value of one or more of its variables. Managed devices respond to or initiate four different types of commands:
Data Representation Differences
Exchange of information in a managed network is potentially compromised by differences in the data-representation techniques used by the managed devices. In other words, various computers represent information differently; these incompatibilities must be rationalized to allow communication between diverse systems. The combination of an abstract and a transfer syntax performs this function. SNMP v.1 uses a subset of Abstract Syntax Notation One (ASN.1), an abstract syntax defined as part of OSI. ASN.1 is used to define packet formats and managed objects. A managed object is simply a characteristic of things that can be managed. A managed object differs from a variable, which is an instance of a managed object. Managed objects can be scalar (meaning that there is always exactly one instance) or tabular (meaning that there may be zero, one, or more instances).
All managed objects are contained in the Management Information Base (MIB), which is essentially a database of objects. A MIB is depicted as a tree, with individual data items as leaves. Object identifiers uniquely identify MIB objects in the tree. Object identifiers are like telephone numbers, in that they are organized hierarchically, and parts are assigned by different organizations. For example, international telephone numbers consist of country codes (assigned by an international organization) and the telephone number, as defined by that country. U.S. telephone numbers are further subdivided into an area code, a central office number, and a station number associated with that central office. Top-level MIB object identifiers are assigned by the International Organization for Standardization/International Electrotechnical Commission (ISO/IEC). Lower-level object IDs are allocated by the associated organizations. Several prominent branches of the MIB tree appear in Figure 32-2.
The MIB tree is extensible by virtue of experimental and private branches (not shown in
Figure 32-2). Vendors, for example, can define their own private branches to include instances of their own products. MIBs that have not been standardized are typically positioned in the experimental branch.
The Structure of Management Information (SMI) document defines the structure of the MIB and the rules for defining MIBs. The SMI allows the use of standard ASN.1 data types: INTEGER, OCTET STRING, and OBJECT IDENTIFIER. It also defines the following data types:
SNMP v.1 itself is a simple request-response protocol. Four SNMP v.1 operations are defined:
SNMP v.1 messages contain two parts, a message header and a protocol data unit (PDU). The message header consists of a version number and a community name. The community name serves two functions. First, the community name defines an access environment for a set of NMSs using that community name. Second, because devices that do not know the proper community name are precluded from SNMP v.1 operations, network managers have also used the community name as a weak form of authentication.
The data portion of an SNMP v.1 message contains the specified SNMP v.1 operation (get, set, and so on) and associated operands. Operands indicate the object instances involved in the transaction.
Figure 32-3 shows the SNMP v.1 PDU format. All of the fields are variable in length as prescribed by the ASN.1 encoding rules.
Figure 32-3 : SNMP v.1 Message Format
SNMP v.1 get, get-next, response, and set PDUs consist of the following fields:
Trap PDUs are slightly different from the get, get-next, response, and set PDUs. They consist of the following fields:
SNMP Version 2.0 is an evolution of the initial version SNMP (now called SNMP v.1) derived from two specifications published in July 1992: Secure SNMP and the Simple Management Protocol (SMP).
Secure SNMP defined security features that are not available in SNMP v.1, but Secure SNMP used message formats that are incompatible with SNMP v.1. Compared with SNMP v.1, SMP offered greater flexibility in terms of the resources it can manage, the size of data transfers, and the environments in which it can operate (OSI networks and other communications architectures in addition to TCP/IP networks.) A subset of SMP capabilities allowed it to interoperate with SNMP v.1.
As the Internet community analyzed these two new specifications, a consensus emerged that SMP should serve as the basis for the development of a new SNMP standard and that many of the security features from Secure SNMP would be incorporated into that new standard. The result is SNMP v.2, which was published as a set of proposed Internet standards in the spring of 1993.
SNMP v.2 includes improvements in the SMI, in protocol operations, in management architecture, and in security.
The SNMP v.2 SMI supports several new data types and incorporates a new convention for creating and deleting conceptual rows in a table. The network address data type now supports OSI NSAP addresses, as well as IP addresses. There is now a 64-bit counter data type, as well as the existing 32-bit counter, and there is now an unsigned integer type to represent integers in the range 0 to 232--1.
SNMP v.2 introduces the concept of an information module, which specifies a group of related definitions. There are three kinds of information modules:
SNMP v.2 defines two new operations:
With the exception of the way SNMP v.2 responds to get, get-next, set, and trap operations, the SNMP v.2 versions of these operations are identical to their SNMP v.1 counterparts. In SNMP v. 1, if the responding agent cannot provide values for all the variables in the list, it does not provide any values. In SNMP v.2, a variable binding list is prepared even if values cannot be supplied for all variables. If an exception condition is associated with the variable, the variable is paired with the name of that exception condition.
To simplify PDU processing, all operations except the get-bulk operation use the same PDU format. Figure 32-4 shows the PDU format used by the get, get-next, set, response, and trap operations, as well as the new inform operation.
Figure 32-4 : PDU Format for the Get, Get-Next, Inform, Response, Set, and SNMP v.2 Trap Operations
The fields of the PDU for get, get-next, set, response, and trap operations are as follows:
When used by the get, get-next, set, trap, and inform operations, the error status and error index fields are set to 0. Only the response operation sets the error status and error index fields.
The get-bulk request operation uses the PDU format shown in Figure 32-5.
Figure 32-5 : PDU Format for the Get-Bulk Operation
The fields of the PDU for the get-bulk operation are as follows:
SNMP v.2 supports the centralized network management strategies of SNMP v.1 as well as distributed strategies based on the new manager-to-manager MIB. In a distributed architecture, some systems operate both in the role of manager and of agent. When acting as an agent, a system accepts commands from a superior management system. These commands can deal with access to information stored locally or can require the system (now acting as an intermediate manager) to provide summary information about subordinate agents. In addition, an intermediate manager can issue trap information to a superior manager.
The lack of authentication capability is the most serious security deficiency of SNMP v.1, making it vulnerable to unauthorized changes to the configuration of a network. For that reason, many vendors have not implemented set operations, thereby reducing SNMP v.1 to a monitoring facility.
SNMP v.2 includes provisions for preventing the following types of security threats:
Figure 32-6 : SNMP v.2 Message Format
The fields of the SNMP v.2 message formats are as follows:
SNMP v.2 supports three uses of the message format:
Through the authentication procedure, SNMP v.2 can assure that messages are received as sent, without modification or replays. A message-digest algorithm calculates a 128-bit digest over the appropriate portion of an SNMP v.2 message. The digest added to the message is recalculated by the recipient to verify that there has been no modification. The timestamps are based on the maintenance of loosely synchronized clocks among managers and agents. The message recipient uses the timestamp to verify that the message is recent, to determine the proper resequencing of multiple messages, and to detect message replays.
The new message formats, protocol operations, and security features make SNMP v.2 incompatible with SNMP v.1. The easiest way to accomplish to transition an existing network from SNMP v.1 to SNMP v.2 is to upgrade the manager systems to support SNMP v.2 in a way that allows coexistence of SNMP v.2 managers, SNMP v.2 agents, and SNMP v.1 agents. The issues fall into two categories:
One way to achieve coexistence at the protocol level is to reach existing SNMP v.1 agents through an SNMP v.2 agent that acts as a proxy agent on behalf of an SNMP v.2 manager. The proxy agent maps get-bulk PDUs to get-next PDUs and SNMP v.1 trap PDUs to SNMP v.2 trap PDUs, but passes get, get-next, and set PDUs unchanged, as shown in Figure 32-7.
Figure 32-7 : Mapping Approach for Interoperability
Another way to achieve coexistence at the protocol level is to use a "bilingual" SNMP v.2 manager that supports both SNMP v.1 and SNMP v.2. When a management application needs to contact an agent, it can use SNMP v.1 or SNMP v.2, based on information in a local database that identifies the agent as supporting SNMP v.1 or SNMP v.2, as shown in Figure 32-8.
Figure 32-8 : Bilingual Manager Approach for Interoperability
|
Copyright 1988-1996 © Cisco Systems Inc.