Simple Network Management Protocol

Arrows indicate RFCs that replace or update earlier RFCs.

The following sections discuss aspects of SNMP and SMI in more detail.

SNMP Versions

SNMP has gone through several revisions so far in its lifespan. The following sections provide details of those revisions.

SNMPv1

SNMPv1 was defined fairly quickly and with little dissension through the standards process. It supported a fairly simple set of operations: get, get-response, get- next , set-request, and trap. (See "SNMP Operations," later in this chapter, for definitions of these operations.)

SNMPv1 included the capability to use different security models, but the only one defined was the community-based security model. Using community-based security, each SNMP packet includes a community string that is used to determine the access level that the originator of the request will have to the MIB in the agent. Agents include the community string in the get-response and notification packets, but most managers do not check or use it. Agents can restrict access that a user of a particular community string has to the objects in its MIB. Commonly, access is given to either read-only objects or to read-write objects. Note that the MIB defines some objects as read-only and these objects can't be written, no matter what community string is used. Cisco Catalyst code includes another level—secret, or read-write-all—which adds the capability to access and change the MIB objects that control the community strings on the device.

SNMPv1 defined a capability called a view that enables you to restrict access to the MIB. ("SNMP Views," later in this chapter, describes the view capability in more detail.)

The Cisco Catalyst secret or read-write-all community string can be seen as a community string that has read-write access to, or view of, the whole MIB. The read and read-write community strings in Catalyst software can be seen as strings with a view applied that allow read and read-write access, respectively, to all objects except those that can view and change the community strings.

This security model has been criticized as being insecure , but it is only trivially less secure than Telnet or ftp, both of which pass usernames and passwords in clear text. There are some methods to increase security while still using SNMPv1, including using a dedicated network or VLAN for management and applying access lists to the SNMP community strings (supported in Cisco IOS software, but not in Cisco Catalyst software).

All SNMP MIB objects, including objects defined using SMIv1 or SMIv2, can be used with SNMPv1 (with the exception of objects of the 64-bit integer or derivative types, including Counter64). Cisco IOS and Catalyst software supports SNMPv1 in all releases.

SNMPv1 has the following limitations:

• A primitive security model

• Support for 32-bit integer objects only

• A perceived need for better performance

The next few sections discuss the efforts to solve these issues.

SNMPv2

SNMPv2 was designed to add security and increase performance. It included a party-based security mechanism and added both a get-bulk and an inform operation, as well as support for 64-bit integers, including counters. SNMPv2 also grouped traps and informs into notifications and cleaned up the way SNMP notifications (traps or informs) are identified. SNMPv2 is also known as SNMPv2p, where the p designates support for the party-based security mechanism. Competing versions with different security mechanisms include SNMPv2u, with a user-based security mechanism, and SNMPv2*, with an alternative user-based security mechanism.

The IETF standards committee (including some of the original authors of SNMPv2) could not agree on the security mechanism defined in SNMPv2, so it was never ratified. The disagreement was over concerns that the party-based security mechanism would be too complex to implement.

Cisco IOS devices supported SNMPv2 from early in the version 10 train until 11.2(4)F, when SNMPv2c support replaced SNMPv2. The 11.2F train features were rolled into 11.3, so all 11.2 trains support SNMPv2, whereas 11.3 and above support SNMPv2c instead. 64-bit counters were not supported while SNMPv2 was supported. Cisco Catalyst devices never supported SNMPv2. Neither SNMPv2u nor SNMPv2* have been supported by Cisco devices.

Because SNMPv2 never became a standard, few network management systems supported it. So, SNMPv2 can be and has been ignored by network managers for the most part.

SNMPv2c

Because of the dissension in the standards committee about SNMPv2 security, the committee decided to release RFCs that described the part of SNMPv2 that could be agreed upon. Thus, SNMPv2c was drafted without the troublesome security aspects of SNMPv2. The c in SNMPv2c signifies that it supports the same community-based security model of SNMPv1.

As noted previously, Cisco IOS devices first supported SNMPv2c in version 11.2(4)F and support for SNMPv2 was dropped at the same time. Because this feature train's capabilities were rolled into 11.3, SNMPv2c is supported in all 11.3 and above IOS versions. Cisco Catalyst devices added support for SNMPv2c in version 3.1 software, including support for 64-bit counters.

In general, 64-bit counter support didn't become available until Cisco IOS version 12.0(3)T. The Cisco 12000 GSR routers supported an enterprise MIB, CISCO-C12000-IF-HC-COUNTERS-MIB, to add limited support for 64-bit counters. This MIB paired two 32-bit integers together that could be combined at the management station to create a 64-bit counter. It provided support only for the ifInOctets, ifOutOctets, ifInUcastPkts, and ifOutUcastPkts objects. This MIB had a very limited lifespan and was supported only in the 11.2GS train for the 12000 GSR routers.

SNMPv3

The IETF SNMP standards committees were able to hammer out a security scheme that could be agreed upon, and added this capability to SNMPv2c to make SNMPv3.

SNMPv3's security is a user-based security model (USM). It supports secure authorization of the user sending a packet, as well as the privacy or encryption of the packet. SNMPv3 allows you to use SNMPv1-style community strings as well as v3 users.

Authorization of the source of the packet not only increases the security of network management, but may also increase its reliability.

You can still use views (now renamed View-based Access Control Models (VACMs)) to limit what users and community strings can access and modify in the MIB.

Users contemplating using SNMPv3 authorization or privacy will need to implement a key management system that will manage the keys required to authorize and encrypt the packets.

Cisco IOS devices started supporting SNMPv3 in IOS version 12.0(3)T, and 64-bit counter support for SNMPv2c and SNMPv3 were added at the same time. Cisco Catalyst devices support SNMPv3 as of software version 5.4.

Until SNMPv3 security can be used in production networks, there are some methods that can be used to significantly increase the security of your network management transactions. See the section called "Controlling SNMP Access Using Views and Access Lists" in Chapter 18, "Best Practices for Device Configuration," for coverage of some of these methods.

SNMP Packet Formats

This section shows the packet formats for the three versions of SNMP still in use: SNMPv1, SNMPv2c, and SNMPv3.

SNMPv1 Packet Formats

An SNMPv1 packet contains two pieces: a message header and a protocol data unit (PDU). The message header has two fields: the version number and the community name . Figure 8-2 illustrates the basic format of an SNMPv1 packet.

As can be seen from Figure 8-2, SNMPv1 protocol headers contain two fields: version number and community name.

• Version number . Specifies the version of SNMP used. SNMPv1 is version 1.

• Community name. Defines the community string that determines the access rights of this packet.

SNMPv1 Protocol Data Unit

SNMPv1 PDUs vary in format depending on the PDU type. The following sections will detail these formats.

Get, Get-next, Get-response, and Set-request PDU Format

This PDU format specifies an operation (get, set-request, etc.), a unique ID, error fields, and fields that specify the objects to be operated on with values. SNMPv1 PDU fields are variable in length, as prescribed by Abstract Syntax Notation One (ASN.1). Figure 8-3 illustrates the fields of the SNMPv1 get, get-next, get-response, and set-request PDUs.

The following describes each of the fields in Figure 8-3:

• PDU Type . Specifies the type of PDU (get, get-next, etc.).

• Request ID . A unique ID for this request. Responses use the same ID as the request they are satisfying .

• Error Status . The status of a get-response. Zero indicates no error.

• Error Index . Specifies the variable binding that the error status refers to.

• Variable Bindings . Each variable binding specifies an OID and the value of this OID. Each of these values (the OID and its value) are encoded using Basic Encoding Rules (BER) and are represented as a triplicate of the object type, length in bytes, and value. For example, for an OID the type is OID, the length is the encoded length of the OID, and the value is the BER-encoded OID. A 32-bit integer would have a type of integer, and the length would be the encoded length of the integer, which could be from 0 for a 0 or null value and up to 5 for a 32-bit integer with the high-order bit on. The value is the BER-encoded value of the integer.

Trap PDU Format

Figure 8-4 shows the fields of the SNMPv1 Trap PDU.

The following list discusses the various fields in Figure 8-4:

• PDU Type. Specifies the type of PDU (trap).

• Enterprise . For generic traps, specifies an OID that indicates the type of device generating the trap. For specific traps, this field specifies the trap (SMIv1) or notification (SMIv2) section's OID for the MIB document containing the definition of the specific trap.

• Agent Address . Specifies the address of the device generating the trap.

• Generic Trap Type. Indicates which SNMPv1 generic trap this trap is or if it is not a generic trap (see Table 8-4).

• Specific Trap Code . Indicates a specific trap number. Specific traps are defined in MIB documents. The combination of the enterprise OID and the specific trap specifics a unique trap.

• Time Stamp . Provides sysUpTime at the time the trap was generated.

• Variable Bindings . As in other SNMP packets, this field consists of one or more variable bindings. Each variable binding consists of an OID and a value for that OID.

SNMPv2c Packet Format

SNMPv2c packets have the same format at this level as SNMPv1 packets. The version number for SNMPv2c is 2.

SNMPv2c Protocol Data Unit

SNMPv2c PDUs vary in format depending upon the PDU type. The following sections detail these formats.

Get, Get-next, inform, Get-response, set-request, and Trap PDU Formats

SNMPv2c get, get-next, inform, get-response, set-request, and trap PDUs all contain the same fields as the SNMPv1 packet format shown in Figure 8-2. Note that this is a change for the trap PDU from SNMPv1. Also, the trap and inform PDUs in SNMPv2c format include two mandatory variable bindings: the trap enterprise OID and the value of sysUpTime at the time the trap was generated, must be the first two variable bindings for these PDU types.

Get-bulk PDU Format

Figure 8-5 shows the fields of the SNMPv2c get-bulk request.

The following descriptions summarize the fields illustrated in Figure 8-5:

• PDU Type . Identifies the PDU as a get-bulk operation.

• Request ID . Same as for a SNMPv1 PDU.

• Non-repeaters . The number of variable bindings that should be retrieved no more than once. This field is non-zero when some of the variable bindings are not objects in a table. All non-repeaters (if any) must appear first in the list of variable bindings.

• Max-repetitions . Defines the maximum number of times that the repeating variables should be retrieved.

• Variable Bindings . Same as for a SNMPv1 PDU.

SNMPv3 Packet Format

SNMPv3 packets have a different header format from SNMPv1. All PDU formats are identical to SNMPv2c. Figure 8-6 shows this new header format.

Each of the fields in Figure 8-6 is described as follows :

• Message Version . Specifies the protocol version. SNMPv3 is 3.

• Message ID . Specifies which message stream this packet belongs to.

• Message Max Size . The maximum size of an SNMP packet that the sender can receive.

• Message Flags . Contains the reportable, priv, and auth flags. The reportable flag indicates that the sender expects a reply, for example, for a get, get-next, get-bulk, set-request, or inform operation. The priv and auth flags indicate whether encryption and authentication are used for this packet.

• Message Security Model . Indicates which security model is used. SNMPv1 is 1, SNMPv2c is 2, and the User Security Model (USM), defined with SNMPv3, is 3.

• Message Security Parameters . Defined by the particular security model selected.

• Context Engine ID . A unique identifier of the sender of the packet.

• Context Name . A name associated with the current context.

• PDU . All SNMPv3 packets use the same PDUs as defined for SNMPv2c.

SNMP Operations

SNMPv1 defined five protocol operations: get, get-response, get-next, set-request, and trap. SNMPv2 added get-bulk and inform, and redefined the trap operation packet format. All of these operations were carried over to SNMPv2c and SNMPv3. Neither added any new operations. Each of these operations will be discussed briefly in the following sections.

The basic structure of an SNMP packet is a header that includes an authentication structure (a community string, SNMPv2 party information, or SNMPv3 user information), a request-id or sequence number, and an error status and error index. (Get-bulk overlays the error status and error index fields with the non-repeaters and max-repetitions fields. See the section "Get-bulk.") See the previous section for more details.

Get

The get operation is the simplest of the operations. Basically, a get operation is a request for an agent to return one or more objects or specific pieces of information. For each object requested , the agent will return that object's value.

The network management system can request as many objects as will fit into one packet. However, as the length of the objects in the packet are zero (a value of null), the agent may not be able to send a get-response packet back with all the information filled in if doing so would cause the packet to exceed the maximum size that the agent supports for an SNMP packet. Although the standard doesn't mention a maximum size, all agents and managers have a maximum that they can handle. If the agent can't finish filling the packet, it will return an error of tooBig. All agents must be able to handle 484-byte packets.

Cisco IOS devices had a default maximum size of 484 bytes until IOS version 10.3, when the default maximum was increased to 1500. By using the Cisco IOS global configuration command, snmp-server packetsize byte-count, you can change the maximum size. The command will accept any number up to 8192, but there are other factors in the SNMP implementation that limit the maximum to 3072 until IOS 12.1. Cisco Catalyst devices have a hard-coded maximum of 1500 bytes.

Get-response

The get-response operation is the packet type that SNMP agents send in response to receiving a get, get-next, get-bulk, or set-request packet. Management stations send a get-response operation to acknowledge . A get-response packet is virtually the same format as all of these requests , so it is very easy for the agent to construct. The agent just has to fill in the blanks, change the packet type to get-response, and send it back. Although this is a rather simplistic representation of the operation of an SNMP agent, it is sufficiently accurate for most network managers (with the exception of when the received packet is a get-bulk type. See the "Get-bulk" section for further details).

Get-next

The get-next operation allows a network management system to request the "next" object or objects in the MIB supported by the agent. For each object requested, the agent will return the object that is next in the MIB tree, in lexicographical order. Lexicographical ordering means that the next item must always have a greater OID than the last.

This operation allows an NMS to request information from an agent without knowing all the information about the MIB supported by that agent or the instances of all objects. In particular, it is useful for retrieving rows of information from tables without requiring the NMS to know all the indexes for the tables. This is the SNMP operation that is most commonly used to implement a method to retrieve a table or the whole MIB from an agent. This is commonly known as an SNMP walk.

There were some changes in how the interface table is structured that first occurred in RFC 1573. These changes were solidified in RFC 2233 and are now considered a best practice for all SNMP tables. Basically, the major change that affects polling tables is the requirement that objects that don't have data for a particular row must not be instantiated . The result is called a sparse table because fields that don't make sense don't exist. See section 3.1.4 of RFC 2233 for more details.

For example, consider a Frame Relay connection, consisting of the physical connection and one or more virtual connections. Error counters such as ifInErrors have no meaning for virtual connections; if the packet contains an error, determining which virtual connection the packet was meant for isn't possible. Therefore, standards-compliant implementations of the interfaces table will contain holes or missing data for these instances. In particular, Cisco IOS software started supporting sparse tables in version 11.1. Cisco Catalyst software does not support sparse tables as of version 5.1; however, LANE modules installed in a Catalyst switch and polled through the supervisor module do support sparse tables.

Sparse tables mean that certain assumptions that have been made are no longer true. The assumption that affects get-next is that all columns in the table will have the same number of entries. Consider the sparse interfaces table in Table 8-3. What happens when you query it using get-next?

Table 8-3. Example of Part of a Sparse Interfaces Table

Following are a query and results for the first row of the table:

>snmpnext <device> ifInOctets ifInErrors ifOutOctets
ifInOctets.1 = INTEGER 20345
ifInErrors.1 = INTEGER 123
ifOutOctets.1 = INTEGER 14325

And for the next row:

>snmpnext <device> ifIndex.1 ifInOctets.1 ifInErrors.1 ifOutOctets.1
ifInOctets.2 = INTEGER 345
ifInErrors.4 = INTEGER 11
ifOutOctets.2 = INTEGER 432

What happened here? The query returned all the content of the second row of the table, but ifInErrors is from the third row with the ifIndex of 4. You need to be careful not to assume you got just objects from row 2.

Continuing with the third row:

>snmpnext <device> ifInOctets.2 ifInErrors.4 ifOutOctets.2
ifInOctets.4 = INTEGER 1311
ifInUnknownProtos.1 = INTEGER 0
ifOutOctets.4 = INTEGER 103

This time, ifInErrors is not returned, but rather the next object in the table. This result indicates that all the ifInErrors column has been returned. You should continue to try to get the next row, as follows:

>snmpnext <device> ifInOctets.4 ifOutOctets.4
ifInUcastPkts.1 = INTEGER 19871
ifOutUcastPkts.1 = INTEGER 13210

This result indicates that all the other rows in the previous get-response have been returned because all the columns have returned data beyond what we are interested in. So you're done.

There are commercially available packages that query sparse tables incorrectly. If you see strange results when polling data through SNMP, an inaccurate package might be the reason. You can test to see if the inability to support sparse tables is the problem by turning off sparse tables in Cisco IOS software with the no snmp-server sparse-tables global configuration command. There is no way to turn off sparse tables on a LANE module in a Catalyst switch.

Get-bulk

The get-bulk operation was added by SNMPv2 and improves the performance of retrieving large amounts of SNMP data. This operation allows the agent to pack as many values in each get-response packet as will fit without exceeding the maximum SNMP packet size. This can significantly reduce the management overhead on a network and also can significantly increase the speed of retrieving large amounts of data.

The get-bulk operation allows the agent to maximize the amount of information returned in a packet. You need to give the command some hints about what you want it to do in the form of two arguments. The first argument is the number of objects that are specified exactly, that is, objects that you want just one of, such as sysUpTime.0, sysDescr.0, or ifNumber.0. Such items are referred to as non-repeaters. All non-repeaters must be specified before the repeating arguments.

The second argument, for the repeating objects, is the maximum number of repeats you want. The agent will fill the get-response with as many objects as will fit in one packet, up to the maximum number of objects non-repeaters and repeaters you asked for.

There are at least three methods to handle instances when you don't know how many rows exist in a table you want to retrieve:

• Determine how many rows by querying an object, if one exists for the table in question.

• Specify a very high repeaters number and deal with the possibility that you will receive lots of stuff you don't want.

• Specify a relatively small repeaters number and realize that you may have to do more get-bulk requests to get the whole table.

The first method can be used only for tables where there is an object to tell you how many rows there are. The ifTable has such an object, called ifNumber. Using the data from Table 8-3 as an example, here is what querying the object looks like:

>snmpget <device> ifNumber.0
ifNumber.0 = INTEGER 3

Now, consider how to retrieve the ifTable information in Table 8-3 with the get-bulk operation. There are no non-repeaters to retrieve, so set that argument to 0 and use ifNumber+1 for the number of repeaters you want. The reason for adding 1 to ifNumber is so you get at least one set of objects beyond the end of the table. This will ensure that you get the whole table in cases where rows get added after you queried ifNumber. Example 8-2 shows the query and results.

Example 8-2 Using the get-bulk operation.

>

snmpbulk <device> 0 4 ifInOctets ifInErrors ifOutOctets

ifInOctets.1 = INTEGER 20345
ifInErrors.1 = INTEGER 123
ifOutOctets.1 = INTEGER 14325
ifInOctets.2 = INTEGER 345
ifInErrors.4 = INTEGER 11
ifOutOctets.2 = INTEGER 432
ifInOctets.4 = INTEGER 1311
ifInUnknownProtos.1 = INTEGER 0
ifOutOctets.4 = INTEGER 103
ifInUcastPkts.1 = INTEGER 19871
ifInUnknownProtos.2 = INTEGER 0
ifOutUcastPkts.1 = INTEGER 13210

In Example 8-2, only one request was made and the whole table was returned. It is quite possible that you would not receive the whole table in the first packet. In that case, you would have to count the number of rows you did receive, subtract that number from the number of repeaters you requested, and set the objects to be retrieved to the last set of objects received in your next request. You would continue this process until you retrieved the entire table and one set of objects beyond.

Set-request

The set-request operation is virtually identical to the get operation, with the exception that the manager fills in the desired values for the objects and the agent is requested to change the value of these objects. The agent sends back a get-response packet with the new values of the objects set, along with the status of the set-request operation.

Note that the agent will not allow a set-request operation unless the manager has write access through the correct community string or other authorization method, the object(s) are writeable by the agent, and the SNMP view for the security method used allows write access to the object(s).

Just like the other SNMP operations, with set-request it is possible to specify several objects—as many as will fit into one packet. And, just like the get operation, it is possible to specify more objects than the agent can fit in the return packet. In this case, the set-request operation is not done and an error of tooBig is returned in the get-response packet.

All set-requests should succeed on all objects or should fail for all objects. The errIndex in the reply (a get-response operation) should point to the first object that was found to be in error.

Notifications

SNMPv1 defined a method for an SNMP agent to asynchronously deliver event notifications. This operation was called a trap. In SNMPv1, the event notification was also called a trap. SNMPv2 defined a new operation, inform, which added acknowledgment of the receipt of the notification and retransmission in the event that an acknowledgment was not received. SNMPv2 clarified the difference between the operations and the event notifications by redefining event notifications from traps to notifications. Traps and informs are covered in more detail in the following sections.

Traps

Trap operations allow an SNMP agent to send asynchronous notifications that an event has occurred. Traps are sent on a best-effort basis and without any method to verify whether they were received.

Traps have identifiers that specify which trap this operation is for. SNMPv1 defined a fairly awkward method of determining the trap identifier. This method involved using two fields—generic-trap and specific-trap—as well as the enterprise field, which holds an OID. To determine which trap it is, you must first look at the generic-trap field. This field can have the settings listed in Table 8-4.

Table 8-4. Generic-trap Field Values

If generic-trap is anything but enterpriseSpecific(6), the value of generic-trap specifies the trap type. If generic-trap is enterpriseSpecific(6), the value of the specific-trap field specifies which trap this is, relative to the enterprise field. The enterprise field is usually populated with the OID of the trap portion of the MIB that the trap is defined in. Therefore, it is usually possible to look at the enterprise field and determine where the trap is defined. Then, the specific-trap value will specify the trap number within the relevant MIB.

Let's look at an example SNMPv1 trap and see how we would need to determine what trap it is.

Here are the relevant fields from the packet:

• generic-trap = enterpriseSpecific(6)

• specific-trap = 1

• enterprise = 1.3.6.1.4.1.9.9.41.2

So we know that this trap is not a standard trap because generic-trap is marked as enterpriseSpecific. We then need to search for the MIB that contains this trap. Usually, subtracting one field from the enterprise OID will yield the desired result. So, searching for 1.3.6.1.4.1.9.9.41 in the OID directory (http://www.cisco.com/public/mibs/oid) shows that this trap is in the CISCO-SYSLOG-MIB. Because this is an SNMPv1 trap, let's look at the SMIv1 form of the MIB. Searching that MIB (http://www.cisco.com/public/mibs/v1/CISCO-SYSLOG-MIB-V1SMI.my), you see the following line:

ciscoSyslogMIBNotificationPrefix OBJECT IDENTIFIER ::= { ciscoSyslogMIB 2 }

This is consistent with the .2 at the end of the enterprise OID. There may be multiple traps or notifications defined in this MIB, so we use the specific-trap to determine which one this trap is. Looking further down in the MIB, you see the following:

clogMessageGenerated TRAP-TYPE
-- Reverse mappable trap
    ENTERPRISE ciscoSyslogMIBNotificationPrefix
    VARIABLES {
        clogHistFacility, clogHistSeverity, clogHistMsgName,
        clogHistMsgText, clogHistTimestamp }
--  Status
--    mandatory
    DESCRIPTION
        "When a syslog message is generated by the device a
        clogMessageGenerated notification is sent.  The
        sending of these notifications can be enabled/disabled
        via the clogNotificationsEnabled object."
    ::= 1

The ::= 1 corresponds to the specific-trap field, so you now know that this trap is a clogMessageGenerated trap.

SNMPv2 redefined the trap PDU, making its format the same as the rest of the SNMP PDU types. It simplified the determination of the trap type by combining the enterprise, generic-trap, and the specific-trap fields into a varbind, snmpTrapOID.0, which contains a single OID that specifies what this trap is.

So, let's take the same SNMP notification delivered as an SNMPv2 trap. Here, we need to look at only one field to determine what trap we are looking at, snmpTrapOID.0, which is always the second varbind in a SNMPv2 trap:

snmpTrapOID.0 = 1.3.6.1.4.1.9.9.41.2.0.1

Here, you subtract three fields from the OID and search for this OID again. Because you get the same OID as previously (1.3.6.1.4.1.9.9.41), you get the same MIB: CISCO-SYSLOG-MIB. Because this time you are looking at a SNMPv2 format trap, you'll look at the SMIv2 format MIB (http://www.cisco.com/public/mibs/v2/CISCO-SYSLOG-MIB.my). Here, you see the same line as before:

ciscoSyslogMIBNotificationPrefix OBJECT IDENTIFIER ::= { ciscoSyslogMIB 2 }

This corresponds to the third to the last field in snmpTrapOID. Looking further, you see the following:

ciscoSyslogMIBNotifications OBJECT IDENTIFIER
                                ::= { ciscoSyslogMIBNotificationPrefix 0 }

This 0 corresponds to the second to last field in snmpTrapOID. Finally, we find the trap or notification definition:

clogMessageGenerated NOTIFICATION-TYPE
        OBJECTS    {    clogHistFacility,
                        clogHistSeverity,
                        clogHistMsgName,
                        clogHistMsgText,
                        clogHistTimestamp
                   }
        STATUS     current
        DESCRIPTION
               "When a syslog message is generated by the device a
                clogMessageGenerated notification is sent.  The
                sending of these notifications can be enabled/disabled
                via the clogNotificationsEnabled object."
        ::= { ciscoSyslogMIBNotifications 1 }

Here, ciscoSyslogMIBNotifications 1 corresponds to the last field in snmpTrapOID. So, with a SNMPv2 trap, you have to look at only one field, snmpTrapOID, to know exactly what trap you received.

Informs

Informs allow the agent to keep track of the notifications sent to each recipient and receive acknowledgments of the receipt of these notifications. The agent can resend the notifications if an acknowledgement is not received in a reasonable time.

It is important to note several reasons why a particular event notification will not be received by a NMS. These include the following:

• The agent was reinitialized.

• The agent ran out of space to save informs and had to drop one or more.

• The agent suppressed certain notifications.

• The network lost or dropped the packet containing the notification multiple times.

• There is not currently network connectivity between the agent and the NMS.

The agent is not state-full through reinitializations. That is, if the agent is reset, it does not remember any notifications sent before the reset and therefore cannot determine whether they were received.

All agents have finite resources and may have to throw away informs that have not been delivered if those resources are exhausted.

Many agents will suppress notifications if they come at a rate above a certain value. This helps the agent, manager, and network to not be overwhelmed with notifications in the event of very rapid state changes that generate event notifications. Take, for example, the case of a flapping WAN interface, where the operational status is changing several times a second. If a linkDown or linkUp notification were sent for every state change, the agent, manager, and network could be flooded with information, making the problem even worse .

Cisco IOS devices limit traps to two per second to a particular device. Any notifications received over this limit will not be sent. Note that this means that it is possible for an NMS to receive multiple linkDown notifications in a row or for the interface to be up and operational. Yet, the NMS has not received a linkUp notification—it was not sent by the agent because the agent limited the volume of traps.

Decoding a SNMPv2 inform is done in the identical way as a SNMPv2 trap because the second varbind is also snmpTrapOID and is formatted in the same way. See the previous section for an example of determining which trap is received.

Structure of Management Information

The Structure of Management Information (SMI) for SNMP was first defined as part of SNMPv1 in RFC 1065. SMI defines how SNMP objects and the MIBs in which they are defined are structured.

SMI defines that the structure of all objects is a tree, starting at or rooted at iso (see Figure 8-7). All names of objects have corresponding numbers; iso is 1 and is commonly represented as iso(1). All SNMP objects exist under a branch off of iso, org(3), dod(6), and then internet(1). Thus, the pathway to SNMP objects can be represented as iso.org.dod.internet or 1.3.6.1. This designation is known as an Object Identifier (OID). OIDs can be represented as all text, all numeric, or a combination of both. A fully-qualified OID (one starting at iso(1)) is guaranteed to be unique.

The branch that most of the standard MIBs are defined under is mgmt(2). New MIBs expected to be standardized are defined initially under the experimental(3) branch. MIBs defined by other organizations are defined under the private(4) branch. Security is defined as the security(5) branch, and finally, SNMPv2- related items are defined under the snmpV2(6) branch. Some other interesting points on the tree are mib-2, which is defined as the first branch off of the management branch, and the cisco branch, which is off of enterprise, which in turn is off of the private branch.

So far, there have been two major versions of SMI: v1 and v2. The next two sections discuss these versions. The third section discusses the different SNMP object types.

SMIv1

SMIv1 was first defined in RFC 1065 and re-released as RFC 1155 with no substantial changes. SMIv1 was revised into concise format in RFC 1212, which was compatible with the previous definition, but more rigorous in its definitions. For a good description of the changes, see section 4 of RFC 1212 (because it is interesting mainly for historical purposes, we are not covering it here).

All MIBs that Cisco provides are in either the SMIv1 concise format or in the SMIv2 format. Most SMIv2-format MIBs are also provided in SMIv1 concise format for the use of management stations that don't support the SMIv2 format. For more information on this, see Appendix A,"CCO, MIBs, Traps, and Your NMS."

SMIv2

SMIv2 was defined at the same time as SNMPv2, but SMIv2 format-defined MIB objects can be used by any version of SNMP, with the exception of 64-bit integer objects. 64-bit integers can be used only with SNMP version 2 and higher; SNMPv1 has no method to handle these objects in the protocol.

SNMP Object Types

SNMP is based upon ASN.1 syntax and inherits several object types from it. Additional object types are defined by SNMP as extensions to these base types. A method to add further object types as extensions to any existing type is defined in SNMP.

Some of the more commonly used object types are listed in Table 8-5 using the SMIv1 syntax.

Table 8-5. SMIv1 Object Types

Counters should never be reset or zeroed unless the SNMP agent is reinitialized (and sysUpTime is reset) or a corresponding time value is also reinitialized.

The reason clearing counters should not be allowed on an SNMP agent is that it becomes a problem when an agent is being managed by more than one management application. This is because if an application is monitoring a particular counter, it has no way to tell whether another application clears that counter. So, if the application suddenly sees a counter go to zero, it may assume the counter has wrapped, and calculates an inaccurate (probably huge) delta value for that counter.

See Chapter 12, "Monitoring System Interfaces" for more information on calculating rates from objects with the type of counter.

SMIv2 redefined some of these types, so Table 8-6 lists these new or redefined types.

Table 8-6. SMIv2 Object Types