Simple Network Management Protocol (SNMP)

• More Information on Cisco Enterprise Network Management

SNMP Background

Like the Transmission Control Protocol (TCP), SNMP is an Internet protocol. Internet protocols are created by the Internet community, a group of individuals and organizations that developed and/or regularly use a large, diverse international network called the Internet. The Internet derived from the Advanced Research Projects Agency network (ARPANET), which was created by packet switching researchers in the early 1970s.

There are two versions of SNMP: Version 1 and Version 2. Most of the changes introduced in Version 2 increase SNMP's security capabilities. Other changes increase interoperability by more rigorously defining the specifications for SNMP implementation. SNMP's creators believe that after a relatively brief period of coexistence, SNMP Version 2 (SNMPv2) will largely replace SNMP Version 1 (SNMPv1). SNMP is part of a larger architecture called the Internet Network Management Framework (NMF), which is defined in Internet documents called requests for comments (RFCs). The SNMPv1 NMF is defined in RFCs 1155, 1157, and 1212, and the SNMPv2 NMF is defined by RFCs 1441 through 1452.

Today, SNMP is the most popular protocol for managing diverse commercial internetworks as well as those used in universities and research organizations. SNMP-related standardization activity continues even as vendors develop and release state-ofthe-art, SNMP-based management applications. SNMP is a relatively simple protocol, yet its feature set is sufficiently powerful to handle the difficult problems presented in trying to manage today's heterogeneous networks.

SNMP Technology

The Internet Management Model

As specified in Internet RFCs and other documents, a network management system comprises:

• Network elements -- Sometimes called managed devices, network elements are hardware devices such as computers, routers, and terminal servers that are connected to networks.

• Agents -- Agents are software modules that reside in network elements. They collect and store management information such as the number of error packets received by a network element.

• Managed object -- A managed object is a characteristic of something that can be managed. For example, a list of currently active TCP circuits in a particular host computer is a managed object. Managed objects differ from variables, which are particular object instances. Using our example, an object instance is a single active TCP circuit in a particular host computer. Managed objects can be scalar (defining a single object instance) or tabular (defining multiple, related instances).

• Management information base (MIB) -- A MIB is a collection of managed objects residing in a virtual information store. Collections of related managed objects are defined in specific MIB modules.

• Syntax notation -- A syntax notation is a language used to describe a MIB's managed objects in a machine-independent format. Consistent use of a syntax notation allows different types of computers to share information. Internet management systems use a subset of the International Organization for Standardization's (ISO's) Open System Interconnection (OSI) Abstract Syntax Notation 1 (ASN.1) to define both the packets exchanged by the management protocol and the objects that are to be managed.

• Structure of Management Information (SMI) -- The SMI defines the rules for describing management information. The SMI is defined using ASN.1.

• Network management stations (NMSs) -- Sometimes called consoles, these devices execute management applications that monitor and control network elements. Physically, NMSs are usually engineering workstation-caliber computers with fast CPUs, megapixel color displays, substantial memory, and abundant disk space. At least one NMS must be present in each managed environment.

• Parties -- Newly defined in SNMPv2, a party is a logical SNMPv2 entity that can initiate or receive SNMPv2 communication. Each SNMPv2 party comprises a single, unique party identity, a logical network location, a single authentication protocol, and a single privacy protocol. SNMPv2 messages are communicated between two parties. An SNMPv2 entity can define multiple parties, each with different parameters. For example, different parties can use different authentication and/or privacy protocols.

• Management protocol -- A management protocol is used to convey management information between agents and NMSs. SNMP is the Internet community's de facto standard management protocol.

Figure 1: The Internet Management Model

Interactions between the NMS and managed devices can be any of four different types of commands:

• Reads -- To monitor managed devices, NMSs read variables maintained by the devices

• Writes -- To control managed devices, NMSs write variables stored within the managed devices

• Traversal operations -- NMSs use these operations to determine which variables a managed device supports and to sequentially gather information from variable tables (such as IP routing tables) in managed devices

• Traps -- Managed devices use traps to asynchronously report certain events to NMSs

A MIB can be depicted as an abstract tree with an unnamed root. Individual data items make up the leaves of the tree. Object identifiers (IDs) uniquely identify or name MIB objects in the tree. Object IDs are like telephone numbers -- they are organized hierarchically with specific digits assigned by different organizations.

The object ID structure of an SNMP MIB defines three main branches: Consultative Committee for International Telegraph and Telephone (CCITT), International Organization for Standardization (ISO), and joint ISO/CCITT. Much of the current MIB activity occurs in the portion of the ISO branch defined by object identifier 1.3.6.1 and dedicated to the Internet community.

The current Internet-standard MIB, MIB-II, is defined in RFC 1213 and contains 171 objects. These objects are grouped by protocol (including TCP, IP, User Datagram Protocol [UDP], SNMP, and others) and other categories, including "system" and "interfaces."

The MIB tree is extensible by virtue of experimental and private branches. Vendors can define their own private branches to include instances of their own products. For example, Cisco's private MIB is represented by the object identifier 1.3.6.1.4.1.9. It includes objects such as "HostConfigAddr," which is identified by object ID 1.3.6.1.4.1.9.2.2.1.51. The HostConfigAddr object specifies the address of the host that provided the host configuration file for a specific Cisco device.

The basic MIB structure, including MIB-II (object ID = 1.3.6.1.2.1) and the Cisco private MIB (object ID = 1.3.6.1.4.1.9), is shown in Figure 2. A more detailed version of Cisco's private MIB is illustrated in Figure 5.

Figure 2: The Basic MIB Structure

SMI Definitions

The SMI specifies that all managed objects should have a name, a syntax, and an encoding. The name is the object ID, which was discussed in the preceding section. The syntax defines the object's data type (for example, "integer" or "string"). A subset of ASN.1 definitions are used for the SMI syntax. The encoding describes how the information associated with the managed object is formatted as a series of data items for transmission on the network. Another ISO specification, called the Basic Encoding Rules (BERs), details SMI encodings.

SMI data types are divided into three categories: simple types, application-wide types, and simply constructed types.

Simple types include four primitive ASN.1 types:

• Integers -- Unique values that are positive or negative whole numbers, including zero.

• Octet strings -- Unique values that are an ordered sequence of zero or more octets.

• Object IDs -- Unique values from the set of all object identifiers allocated according to the rules specified in ASN.1.

• Bit strings -- New in SNMPv2, these comprise zero or more named bits that specify a value.

• Network addresses -- Represent an address from a particular protocol family.

• Counters -- Non-negative integers that increment by positive one until they reach a maximum value, when they are reset to zero. The total number of bytes received on an interface is an example of a counter. In SNMPv1, counter size was not specified. In SNMPv2, 32-bit and 64-bit counters are defined.

• Gauges -- Non-negative integers that can increase or decrease, but latch at a maximum value. The length of an output packet queue (in packets) is an example of a gauge.

• Time ticks -- Hundredths of a second since an event. The time since an interface entered its current state is an example of a tick.

• Opaque -- Represents an arbitrary encoding. This data type is used to pass arbitrary information strings that do not conform to the strict data typing used by the SMI.

• Integer -- Represents signed, integer-valued information. This data type redefines the ASN.1 "integer" simple data type, which has arbitrary precision in ASN.1 but bounded precision in the SMI.

• Unsigned integer -- Represents unsigned integer-valued information. It is useful when values are always non-negative. This data type redefines the ASN.1 "integer" simple data type, which has arbitrary precision in ASN.1 but bounded precision in the SMI.

• Row -- References a row in a table. Each element of the row can be a simple type or an application-wide type.

• Table -- References a table of zero or more rows. Each row has the same number of columns.

The SMI for SNMPv2 includes two documents: RFCs 1443 and 1444. RFC 1443 (Textual Conventions) defines the data types used within the MIB modules, while RFC 1444 (Conformance Statements) provides an implementation baseline. The SNMPv2 SMI also defines two new branches of the Internet MIB tree: security (1.3.6.1.5) and SNMPv2 (1.3.6.1.6).

SNMP Operations

SNMP itself is a simple request/response protocol. NMSs can send multiple requests without receiving a response. Six SNMP operations are defined:

• Get -- Allows the NMS to retrieve an object instance from the agent.

• GetNext -- Allows the NMS to retrieve the next object instance from a table or list within an agent. In SNMPv1, when an NMS wants to retrieve all elements of a table from an agent, it initiates a Get operation, followed by a series of GetNext operations.

• GetBulk -- New for SNMPv2. The GetBulk operation was added to make it easier to acquire large amounts of related information without initiating repeated get-next operations. GetBulk was designed to virtually eliminate the need for GetNext operations.

• Set -- Allows the NMS to set values for object instances within an agent.

• Trap -- Used by the agent to asynchronously Inform the NMS of some event. The SNMPv2 trap message is designed to replace the SNMPv1 trap message.

• Inform -- New for SNMPv2. The Inform operation was added to allow one NMS to send trap information to another.

Figure 3: SNMP v1 Message Format

The version field is used to ensure that all network elements are running software based on the same SNMP version. The community name assigns an access environment for a set of NMSs using that community name. NMSs within the community can be said to exist within the same administrative domain. Because devices that do not know the proper community name are precluded from SNMP operations, network management personnel also have used the community name as a weak form of authentication.

The SNMP PDU has the following fields:

• PDU type -- Specifies the type of PDU being transmitted.

• Request-ID -- Associates requests with responses.

• Error-status -- Indicates an error and an error type. In SNMPv2 GetBulk operations, this field becomes a NonRepeaters field. For these operations, this field defines the number of request-ed variables listed that should be retrieved no more than once from the beginning of the request. The field is used when some of the variables are scalar objects with only one variable.

• Error-index -- Associates the error with a particular object instance. In SNMPv2 GetBulk operations, this field becomes a Max Repetitions field. For these operations, this field defines the maximum number of times that other variables beyond those specified by the NonRepeaters field should be retrieved.

• Variable-bindings -- Comprises the data of an SNMP PDU. Variable bindings associate particular object instances with their current values.

Figure 4: SNMP v2 Message Format

The first part of an SNMPv2 message is often called a wrapper. The wrapper includes authentication and privacy information in the form of destination and source parties. As mentioned earlier, a party includes the specification of both an authentication and a privacy protocol. In addition to a destination and a source party, the wrapper includes a context. A context specifies the managed objects visible to an operation.

The authentication protocol is designed to reliably identify the integrity of the originating SNMPv2 party. It consists of authentication information required to support the authentication protocol used. The privacy protocol is designed to protect information within the SNMPv2 message from disclosure. Only authenticated messages can be protected from disclosure. In other words, authentication is required for privacy.

The SNMPv2 specifications discuss two primary security protocols: one for authentication and one for privacy. These are the Digest Authentication Protocol and the Symmetric Privacy Protocol.

The Digest Authentication Protocol verifies that the message received is the same one that was sent. Data integrity is protected using a 128-bit message digest calculated according to the Message Digest 5 (MD5) algorithm. The digest is calculated at the sender and enclosed with the SNMPv2 message. The receiver verifies the digest. A secret value, known only to the sender and the receiver, is prefixed to the message. After the digest is used to verify message integrity, the secret value is used to verify the message's origin.

To help ensure message privacy, the Symmetric Privacy Protocol uses a secret encryption key known only to the sender and the receiver. Before the message is authenticated, this protocol uses the Data Encryption Standard (DES) algorithm to effect privacy. DES is a documented National Institute of Standards and Technology (NIST) and American National Standards Institute (ANSI) standard.

Originally, SNMPv1 specified that SNMP should operate over the User Datagram Protocol (UDP) and IP. The SNMPv2 transport mapping document (RFC 1449) defines implementations of SNMP over other transport protocols, including OSI Connectionless Network Service (CLNS), AppleTalk's Datagram Delivery Protocol (DDP), and Novell's Internet Packet Exchange (IPX). RFC 1449 also includes instructions on how to provide a SNMPv1 proxy and use of the BER. UDP/IP is still SNMPv2's preferred transport mapping because UDP is compatible with SNMPv1 at both the transport and network layers.

Cisco Systems' SNMP Implementation

SNMP V1/V2 Coexistence

As a member of the Internet Engineering Task Force (IETF), Cisco is active in defining the SNMPv2 standard. When the standard is final, Cisco will support the SNMPv2 agent in its router software. Cisco routers will then be "bilingual," supporting both SNMPv1 and SNMPv2.

Bilingual support of SNMP gives users optimal flexibility by allowing them to migrate to SNMPv2 on their own timetables. During the period when SNMPv1 and SNMPv2 coexist, Cisco customers will not lose any management functionality. Cisco routers will be able to communicate with both SNMPv1 and SNMPv2 NMSs.

RFC 1452 defines a SNMPv1/v2 coexistence strategy. This strategy defines two basic techniques: a proxy agent and a bilingual NMS. The proxy agent translates between SNMPv1 and SNMPv2 messages. The bilingual NMS incorporates both SNMPv1 and SNMPv2 manager software, and therefore, can communicate with both types of agents. When communication with an agent is required, the manager selects the appropriate protocol.

Cisco's bilingual agent support will work with both the proxy agent and the bilingual NMS coexistence strategies, but neither will be a requirement. Since bilingual agents can communicate equally well with both SNMPv1 and SNMPv2 NMSs, users will not be forced to purchase additional SNMPv2 manager software or proxy agents.

System Monitoring and Management Capabilities

Cisco routers provide many useful system monitoring and management capabilities to help administrators manage large Cisco router-based internetworks. System statistics can be tracked both by interface and by protocol. For example, administrators can query for and receive the number of cyclic redundancy check (CRC) errors on a particular interface or the number of AppleTalk packets sent to or received from an interface. This kind of information is an invaluable component of network baselining (establishing a baseline traffic profile for an internetwork).

Cisco routers also can report a wide variety of information about their internal configuration and status. For example, administrators can ascertain:

• The number of successful and unsuccessful attempts to allocate internal router buffers for information storage. These values tell administrators whether the router is in danger of losing packets because of lack of available queue space.

• The average CPU usage over five-second, one-minute, and five-minute periods. These values tell administrators whether the router is overused, underused, or correctly used.

• The temperature of air entering and leaving the router. This reading gives administrators information about the router's environmental situation. Specifically, the temperature of air entering the router can be too high if the router is installed in a room with insufficient ventilation. The temperature of air leaving the router can be too high if one or more of the router's air vents is covered.

• The voltage that exists on various electrical lines in the router. These values tell administrators about the router's electrical status. Specifically, the voltages on the +5 and +12V lines to the router's power supply can be discovered. Abnormal values can indicate power faults.

With over 450 objects, Cisco's private MIB provides network managers with broad, powerful monitoring and control facilities. Cisco's private MIB supports DECnet (including DECnet routing and host tables), XNS, AppleTalk, VINES, NetWare, and additional system variables that highlight such information as average CPU utilization over selectable intervals. Further, Cisco users can add private extensions to the MIB as required. This capability gives users the flexibility to mold Cisco's SNMP products to their own networks, optimizing management capabilities. Cisco's private MIB tree is shown in Figure 5. This figure expands upon the lower right section of the diagram shown in Figure 2.

Figure 5: Cisco's Private MIB Tree

Cisco also supports other MIBs relevant to router operation. For example, support for some chassis MIB objects allows users to retrieve information about router chassis and installed cards. Card types, card serial numbers, the number of cards in a particular router, the ROM version of those cards, and many other useful variables can be retrieved. Support for the chassis MIB eases network administration. Those responsible for network maintenance can remotely query Cisco routers to quickly discover a router's hardware configuration, thereby saving time and money.

Access Lists for SNMP

Access lists can be used to prevent SNMP messages from traversing certain router interfaces, and therefore, from reaching certain network devices. For example, this feature can be used to prevent other NMSs from altering the configuration of a given router or router group. Access lists are extremely useful in complex internetworks and are implemented across the majority of Cisco's supported protocols.

Multiple Community Strings

For SNMPv1 operation, Cisco permits multiple community strings so that a router can belong to multiple communities. Further, community strings can be either read only or read/write. This feature provides further security by restricting the ability to alter the configuration of Cisco devices.

Traps

Cisco's SNMP implementation allows trap messages to be directed to multiple management stations. This capability allows virtually instantaneous notification of network problems across the internetwork. If, for example, message queue lengths are excessive in one area of the network, management stations throughout the internetwork can be notified immediately.

Cisco provides two extra traps useful in internetwork environments: reload and tty connection-closed. These traps serve to alert network administrators that routers are being reloaded (which, in turn, may indicate more serious problems) and that virtual terminal connections are closing.

Conclusion

Copyright 1994 © Cisco Systems Inc.