Data Collection Protocols: SNMP, SMI, and MIB

There are so many valuable references, books, and tutorials dedicated to the technical aspects of Simple Network Management Protocol (SNMP), Structure of Management Information (SMI), and Management Information Base (MIB) that there is no point in covering everything in detail in this book. However, this section describes in a few pages the necessary concepts, theory, and terminology. Chapter 4, "SNMP and MIBs," details some useful accounting and performance MIB modules. Furthermore, this chapter provides the complete list of RFCs for further reference.

Internet Management Model and Terminology

SNMP is an Internet protocol developed by the IETF. It is designed to facilitate the exchange of management information between network elements. By transporting information over the SNMP protocol (such as packets per second and network error rates), network administrators can easily manage network performance and accounting, find and solve network problems, and plan for network growth.

The most basic elements of the Internet management model are shown in Figure 3-5.

Figure 3-5. Internet Management Model

[View full size image]

As specified in IETF RFCs and other documents, a managed device is composed of the following:

• SNMP agent— A software module that resides in network elements; it collects and stores management information specified in the supported MIB modules. The SNMP agent responds to SNMP requests from an NMS station for information and actions. The SNMP agent can send fault notifications proactively to the SNMP manager.

• Managed object— A representation of something that can be managed. For example, a list of currently active TCP circuits in a particular 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 network element. Managed objects can be scalar (defining a single object instance) or tabular (defining multiple related instances).

• Management Information Base (MIB)— A collection of managed objects residing in a virtual information store. A collection of related managed objects is defined in a specific MIB module. A MIB can be considered a local data store at the network element.

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

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

The NMS, which contains an SNMP manager, executes management applications that monitor and control network elements. At least one NMS is required in each managed environment.

Interactions between the SNMP manager and managed network elements (SNMP agents) can be any of three different types of commands:

• Read— To monitor managed network elements, SNMP managers read MIB variables maintained by the SNMP agents.

• Write— To control managed network elements, SNMP managers write MIB variables stored within the SNMP agents.

• Notification— SNMP agents use traps or informs to asynchronously report certain events to SNMP managers. Traps are unacknowledged notifications, and informs are notifications acknowledged by the SNMP manager.

SNMP runs on top of UDP in most cases. However, other transport mappings exist, such as IPX. For details, see RFC 3417, Transport Mappings for SNMP.

MIB Modules and Object Identifiers

An SNMP MIB module is a specification of management information on a device. The SMI represents the MIB database structure in a tree form with conceptual tables, where each managed resource is represented by an object. The SNMP agent on a device has access to this local repository. A management application may read and modify this repository via SNMP operations.

Relative to this tree structure, the term MIB is used in two senses. In one sense it is actually a MIB branch, usually containing information for a single aspect of technology, such as a transmission medium or a routing protocol. A MIB used in this sense is more accurately called a MIB module and is usually defined in a single document. In the other sense, a MIB is a collection of such branches. Such a collection might comprise, for example, all the MIB modules implemented by a given SNMP agent, or the entire collection of managed objects.

A MIB module is an abstract tree with an unnamed root. Individual data items, the MIB variables, make up the leaves of the tree. The MIB variables are identified by specifying a "path" through the tree; Object Identifiers (OIDs) uniquely identify or name MIB variables in the tree. An OID is an ordered sequence of nonnegative integers written left to right, containing at least two elements. For easier human interaction, string-valued names also identify the OIDs. They are like telephone numbers, organized hierarchically with specific digits assigned by different organizations.

The OID top structure of the SNMP MIB tree defines three main branches:

• Consultative Committee for International Telegraph and Telephone (CCITT)

• International Organization for Standardization (ISO)

• Joint ISO/CCITT

Much of the current MIB module activity occurs in the portion of the ISO branch defined by object identifier .1.3.6.1, dedicated to the Internet community. After a MIB module is published, OIDs are bound for all time to the objects defined. OIDs cannot be deleted and can only be made obsolete; even minor changes to an object are discouraged.

The MIB tree is extensible with new standard MIB modules or by experimental and private branches. Vendors can define their own private branches to include instances of their own products. For example, the Cisco private MIB is represented by the object identifier .1.3.6.1.4.1.9. It includes objects such as rttMonLatestHTTPOperRTT, which is identified by object ID 1.3.6.1.4.1.9.9.42.1.5.1.1.1, and specifies the round-trip time taken to perform a configured HTTP operation.

For example, the Internet prototypical standard MIB module is MIB-II (RFC 1213), which contains 171 objects. MIB-II contained branches for the basic areas of instrumentation, such as the system, its network interfaces, and protocols such as IP, TCP, SNMP, and others. Note, for completeness, that all these branches started out in a single MIB module, but as SNMPv2 evolved, they were split into separate modules. 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 3-6.

Figure 3-6. Basic MIB Structure

[View full size image]

SMI Definitions

The SMI defines the framework in which a MIB module can be defined or constructed. In other words, it defines the components of a MIB module and the formal language for describing the managed objects. The SMI specifies that all managed objects should have a name, syntax, and encoding. The name is characterized by the OID. The syntax defines the managed 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.

The two versions of SMI are SMIv1 (RFC 1155) and SMIv2 (RFC 2578). SMIv2 offers richer, more precise syntax for defining MIB modules.

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:

• Integer— A unique value that is a positive or negative whole number (including 0).

• OctetString— A unique value that is an ordered sequence of zero or more octets, more commonly called bytes.

• ObjectID— A unique value from the set of all object identifiers allocated according to the rules specified in ASN.1.

• Bits— New in SMIv2, these are zero or more named bits that specify a value.

Application-wide data types refer to special data types defined by the SMI:

• Network address— Represents an address from a particular protocol family. Examples are InetAddressType and InetAddress.

• Counter— A nonnegative integer that increments by +1 until it reaches a maximum value, when it is reset to 0. The total number of bytes received on an interface is an example of a counter. In SMIv1, counter size was not specified (it was 32-bit by default). In SMIv2, 32-bit and 64-bit counters are defined.

• Gauge— A nonnegative integer that can increase or decrease but that latches at a maximum value. The interface load is an example of a gauge. SMIv2 redefined the gauge as gauge32.

• Timetick— Hundredths of a second since an event. The time since an interface entered its current state is an example of a tick.

• 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. Although SMIv1 specifies only integer, SMIv2 redefines INTEGER as Integer32.

• Unsigned integer— Represents unsigned integer-valued information. It is useful when values are always nonnegative. This data type redefines the ASN.1 integer simple data type, which has arbitrary precision in ASN.1 but bounded precision in the SMI. SMIv2 defines UInteger32 (where U stands for unsigned).

Simply constructed types include two ASN.1 types that define multiple objects in tables and lists:

• 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 IETF mandates that all IETF-produced MIB modules use the SMIv2 specifications. However, SMIv2, which is the data structure, does not require SNMPv2 as the "transport protocol." Therefore, SNMPv1 could still be used. SNMPv2 is required only in case the MIB module defined with SMIv2 contains a Counter64 data type, because SNMPv1 does not support this data type. If the MIB module does not contain any Counter64 data type, MIB compilers can translate MIB modules from SMIv2 to SMIv1.

Another ISO specification, called the Basic Encoding Rule (BER, International Telecommunication Union Recommendation X.209), details SMI encodings. The BER allows dissimilar machines to exchange management information by specifying both the position of each bit within the transmitted octets and the structure of the bits. Bit structure is conveyed by describing the data type, length, and value.

SNMP Versions

SNMP version 1 (SNMPv1) is the original version of SNMP. SNMPv1 uses a clear-text community string for context selection. Although sometimes used for security-like purposes, this community string offers only limited security, because it is transmitted in clear text over the wire. Therefore, eavesdropping must be avoided, such as deploying an out-of-band management infrastructure. The community string is defined as an OCTET STRING that can contain any value: spaces, any character, or hex values. However, it is suggested that you avoid $, #, &, /, !, and so on, because those characters might be misinterpreted by NMS applications and scripts. According to the specifications, there is no limitation in terms of length; Cisco IOS limits the length to 128 bytes, though.

SNMPv1 is a simple request/response protocol that specifies five SNMP operations, also called Protocol Data Unit (PDU):

• Get— Allows the SNMP manager to retrieve an object instance from the agent.

• Get-Next— Allows the SNMP manager to retrieve the next object instance from a table or list within an SNMP agent. In SNMPv1, when an SNMP manager wants to retrieve all elements of a table from an agent, it initiates a Get-Next operation to the base OID of the table/column, which returns the first instance (row). Then it continues sending Get-Next requests until a return value is outside of the table, indicating that all elements have been retrieved.

• Set— Allows the SNMP manager to set values for object instances within an SNMP agent.

• Trap— Used by the SNMP agent to asynchronously notify the SNMP manager of some event.

• Response— Used as a response for the Get and Set.

SNMPv2, specified in RFC 1445 through RFC 1447, specified a new party-based security model. However, SNMPv2 never caught on and was finally moved to historic. Hence, SNMPv2c, where the "c" stands for "community," was specified in RFC 1901. This community-based SNMP version 2 (SNMPv2c) is an experimental SNMP framework that supplements the SNMPv2 framework (RFC 3416). Indeed, it uses the SNMPv2 PDUs specified in the SNMPv2 Framework within a community-based message wrapper. Note that SNMPv2c is still widely used throughout the industry.

Even though SNMPv2c has no improved security compared to SNMPv1, it offers some advantages, thanks to the SNMPv2 Framework:

• Richer error handling (error-status: wrongType, wrongLength, wrongEncoding, etc.)

• New data types (for example, 64-bit counters )

• New PDUs:

  - GetBulk— 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. As an example, retrieving a routing table of 100 entries from a network element requires one GetBulk operation in SNMPv2 compared to 101 GetNext PDUs in SNMPv1 (the 101st operation indicates the end of the row). This assumes that all entries fit into a single packet. However, a total of 83 Integer32s values are the maximum to fit into a 1500-byte packet.
  
  

  - Inform— The Inform operation was added to allow the acknowledgment of notification, because one of the drawbacks of the trap is its unreliability due to the UDP transport protocol. The Inform is retransmitted until it is acknowledged (with a maximum retry count) and thus is more reliable than traps. Note that full reliability would require an infinite number of retries, hence infinite queue on the SNMP agent.
  
  

  - Trap— The trap operation has been redesigned in SNMPv2. The Trap PDU is now similar to the other PDUs, which ease the processing at the SNMP manager. Furthermore, the first two variable bindings in the variable binding list of an SNMPv2-Trap-PDU are always sysUpTime.0 and snmpTrapOID.0, respectively (both of them are defined in RFC 3418).
  
  

Figure 3-7 illustrates the SNMPv2 operations, along with the respective direction: from the SNMP manager to the SNMP agent or vice versa.

Figure 3-7. SNMP Operations

[View full size image]

The SNMP version 3 (SNMPv3) Management Framework addresses the deficiencies in SNMPv2 related to security and administration. Although the concept of a view was defined in SNMPv1, SNMPv3 redefined it and gave a structure to security that included the View-based Access Control Model (VACM) for the Simple Network Management Protocol (RFC 3415). VACM defines the controlling elements for accessing the management information.

SNMPv3 provides secure access to network elements through a combination of authenticating and encrypting packets over the network. Here are the security features provided in SNMPv3:

• Message integrity— Ensuring that a packet has not been tampered with in transit.

• Authentication— Determining that the message is from a valid source.

• Encryption— Encrypting the content of a packet prevents eavesdropping on the exchanges between the SNMP manager and agent.

• Message stream modification— Avoids malicious reordering, delay, or replay of messages.

Therefore, data can be collected securely from SNMP agents without fear that it was tampered with or corrupted. Also, confidential information, such as SNMPSet PDU packets that change a router's configuration, can be encrypted to prevent their contents from being exposed on the network.

SNMPv3 provides for both security models and security levels. A security model is an authentication strategy that is set up for a user; it specifies the user's permitted level of security within a security model. RFC 3414, User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3), defines the details of SNMP message-level security. A combination of a security model and a security level determines which security mechanism is employed when handling an SNMP packet. Three security models are available: SNMPv1, SNMPv2c, and SNMPv3. Table 3-1 identifies what the combinations of security models and levels mean.

While the SNMPv3 architecture adoption takes time throughout the industry, discussions are occurring about the efficiency and suitability of SNMP as a configuration protocol. However, SNMP is a sufficient protocol for retrieving performance and accounting data.

References for SMIv1 and SMIv2

For the sake of completeness and for further reading, Tables 3-2 and 3-3 list the IETF references for the two SMI versions and three different SNMP versions. Note that SNMPv1 attained historic status. The Status column differentiates informational versus standard-track RFCs, along with the standard-track maturity level (Proposed Standard, Draft Standard, Internet Standard) as specified in the Internet Standards Process (RFC 2026). The list following the tables references relevant books.

Books for further reference:

• SNMP, SNMPv2, SNMPv3, and RMON 1 and 2, 3rd Edition by William Stallings (Addison-Wesley Professional, 1998)

• A Practical Guide to SNMPv3 and Network Management by David Zeltserman (Prentice-Hall, 1999)

• Understanding SNMP MIBs by David Perkins (Prentice-Hall, 1997)