Simple Network Management Protocol
| The Simple Network Management Protocol (SNMP) is the most commonly used protocol that is specific to network management. Network managers need a good understanding of the capabilities and limitations of SNMP. This section provides an overview of SNMP. If you desire a more complete treatment of SNMP, please see the references at the end of the chapter. SNMP is a protocol specifically designed to manage devices. It defines management entities, typically your NMS, and agent entities, typically your network devices, or more accurately, processes that run on your NMS and network devices. The information available through SNMP is organized into a Management Information Base (MIB). The structure of this information is defined in the Structure of Management Information (SMI). One or more MIB files define the MIB supported by a given SNMP agent. The bottom line is that SNMP provides management information in a structured manner that is well suited to retrieval and modification via applications. A variety of SNMP command line utilities give you the ability to do SNMP operations yourself, but sometimes the complexity of the operation or the number of operations is so high that it's best to leave the job to an application. The Remote Monitoring MIB document, RMON, is an important MIB document because it added a new level of complexity to SNMP agents, both in SNMP capabilities and in the ability of the agent to provide information to an NMS. RMON is also an example of an MIB document that is structured so that it is almost a requirement that you use an application that understands the RMON MIB document to be able to use the capabilities defined in the MIB document. SNMP has been (and continues to be) defined in a series of RFCs. Table 8-2 shows the different RFCs and their relationships. For explanations of the different statuses, see the Best Practice document BCP0009, currently also published as RFC 2026.
Arrows indicate RFCs that replace or update earlier RFCs. The following sections discuss aspects of SNMP and SMI in more detail. SNMP VersionsSNMP has gone through several revisions so far in its lifespan. The following sections provide details of those revisions. SNMPv1SNMPv1 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:
The next few sections discuss the efforts to solve these issues. SNMPv2SNMPv2 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. SNMPv2cBecause 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. SNMPv3The 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 FormatsThis section shows the packet formats for the three versions of SNMP still in use: SNMPv1, SNMPv2c, and SNMPv3. SNMPv1 Packet FormatsAn 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. Figure 8-2. SNMPv1 Packet Format
As can be seen from Figure 8-2, SNMPv1 protocol headers contain two fields: version number and community name.
SNMPv1 Protocol Data UnitSNMPv1 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 FormatThis 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. Figure 8-3. SNMPv1 get, get-next, get-response, and set-request PDUs
The following describes each of the fields in Figure 8-3:
Trap PDU FormatFigure 8-4 shows the fields of the SNMPv1 Trap PDU. Figure 8-4. The SNMPv1 Trap PDU
The following list discusses the various fields in Figure 8-4:
SNMPv2c Packet FormatSNMPv2c packets have the same format at this level as SNMPv1 packets. The version number for SNMPv2c is 2. SNMPv2c Protocol Data UnitSNMPv2c 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 FormatsSNMPv2c 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 FormatFigure 8-5 shows the fields of the SNMPv2c get-bulk request. Figure 8-5. SNMPv2c get-bulk PDU format
The following descriptions summarize the fields illustrated in Figure 8-5:
SNMPv3 Packet FormatSNMPv3 packets have a different header format from SNMPv1. All PDU formats are identical to SNMPv2c. Figure 8-6 shows this new header format. Figure 8-6. SNMPv3 Packet Format
Each of the fields in Figure 8-6 is described as follows:
SNMP OperationsSNMPv1 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. GetThe 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-responseThe 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-nextThe 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?
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-bulkThe 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:
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-requestThe 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. NotificationsSNMPv1 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. TrapsTrap 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.
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:
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. InformsInforms 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 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 InformationThe 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. Figure 8-7. High-level MIB Tree
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. SMIv1SMIv1 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." SMIv2SMIv2 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 TypesSNMP 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.
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.
Note that the only 64-bit type defined is Counter. Work is proceeding on defining other 64-bit types. SNMP ViewsCisco IOS devices allow you to apply a view to an SNMPv1 community string, an SNMPv2 party, or an SNMPv3 user. Views give network managers the capability of limiting what can be accessed through each access method defined. For example, service providers could define a community string that has access only to the statistics for one interface. They could then provide the community string for a particular interface to the customer attached to that interface, therefore allowing that customer to monitor just that interface. The customer could provide the same level of access to the service provider to their external access router. A common use for SNMP views is to limit access to certain tables. This capability is useful because SNMP can have an impact on the CPU load on the devices polled. More specifically, Cisco IOS devices store the routing and address resolution protocol (ARP) tables in the most efficient order for routing and ARP lookups. However, the SNMP tables defined by MIB II (RFC 1213) require that these tables be delivered in lexicographical order. Therefore, Cisco IOS devices must sort these tables if they receive a request for these tables via the get-next or get-bulk operations. This can cause the CPU load on these devices to increase significantly. Because the SNMP process runs at low priority in Cisco IOS devices, this added CPU load will usually not affect core services. However, certain services also run at low priority and can be affected by a high CPU load caused by SNMP polling, including X.25 translation services. Starting before IOS 11.1(20)CC, a change was made in the method used to traverse the routing table to improve multitasking that further exacerbated this issue when polling the routing table. This change affected the 11.1CA and CC trains, as well as all 12.0 releases, but not 11.2 or 11.3. A subsequent change was made to allow SNMP to query the CEF table for routing entries if CEF switching is used. This significantly improves the situation. Network managers sometimes choose to disable access to these tables via an SNMP view. Doing so prevents network management stations from polling these tables and, therefore, placing a high CPU load on network devices. Disabling the polling of the ARP table can cause problems with programs that use the ARP table to convert MAC addresses to IP addresses, such as user tracking applications. Disabling the polling of the routing table may slow down network auto-discovery by an NMS, but will usually not disable it. Cisco IOS devices started supporting views in IOS version 10.0. Cisco Catalyst devices do not support SNMP views as of software release 5.1. Evolution of the Interfaces GroupThe interfaces group was first defined in the original MIB at the same time SNMPv1 was defined. This MIB was revised in RFC 1158 and then redefined in RFC 1213 to become the MIB-II that network managers know and love. This MIB made certain assumptions and enforced certain limitations based on a static view of the interfaces table. These assumptions and limitations became problematic as networking equipment evolved from devices with a fixed number of interfaces or ports to devices that can have physical interfaces swapped in and out without rebooting the system, and virtual and logical interfaces defined and deleted at any time during their operation. The problems were first addressed in RFC 1573, which has been superceded with RFC 2233. One important problem was that the interfaces group defines an object, ifNumber, which is defined as the number of interfaces, and a table of interfaces with an index (ifIndex) of 1 to ifNumber. Now, take an NMS that is collecting information about a particular interface. The objects that this NMS is interested in are indexed with a particular ifIndex. If an interface is removed from the device, the corresponding row in the interfaces table is deleted and ifNumber is decremented by 1, or else the interfaces table ends up cluttered with unused entries, with no standard way to define unused entries. According to the definition of the interfaces table in RFC 1213, if a row is deleted and ifNumber decremented, then all ifIndexes for all interfaces with a higher ifIndex than the one deleted would have to be decremented. There is no standard way to report this event to the NMS, which may blithely continue to collect data using the original ifIndex, despite the change. This can severely impact the accuracy of the collected data. RFC 1573 separated ifIndex from ifNumber. It also required the agent to use a particular ifIndex for a single interface only. If this interface is deleted, its row should be deleted from the interfaces table and the corresponding ifIndex should not be reused. RFC 1573 suggests using ifName or ifAlias as keys to determining what ifIndex is what when the SNMP agent is reinitialized (sysUpTime is reinitialized). Cisco Catalyst software will attempt to reuse ifIndexes only if a physical interface is removed and an identical interface is reinserted. RFC 1573 also allows ifIndexes to be renumbered if the SNMP agent is reinitialized. Cisco Catalyst software versions since 3.1 will also attempt to preserve ifIndex numbers through reboots. Another problem is that no method of associating sub-interfaces with the main interface or virtual interfaces with physical interfaces the way the interface table was defined in RFC 1213. RFC 1573 adds a new table, the ifStackTable, to address this issue. Remote Monitoring MIB and Related MIBsRMON is just another SNMP MIB. Yet it was one of the first MIBs to support row creation in tables, thus allowing much more flexibility in designing MIBs. RMONv1 defined a method to manipulate rows, called the EntryStatus or RMON method. RMONv2 was defined after RFC 1903 was released and, therefore, uses that RFC's method to manipulate rows, known as the RowStatus method. The RMON MIB allows an NMS to request that an agent do many types of things, some of which are usually thought of as the domain of either the NMS itself or network analyzers. The advantage of this capability is that the network can monitor itself in a more autonomous fashion. Conversely, RMON requires more resources from the SNMP agent than the typical MIB. RMON can quite easily exhaust an agent's memory or processing resources if not used with caution. RMONv1 supports nine groups, as follows:
RMONv2 adds nine new groups, mostly concentrated on the higher layers of the protocol stack:
Cisco IOS devices have supported RMONv1 since IOS 11.1. All Cisco IOS devices support two groups: the alarms and the events groups. These two groups allow an agent to trigger RMON events when an integer object crosses a threshold and to have that RMON event trigger an action such as logging that event or sending an SNMP notification. See Chapter 5, "Configuring Events," for more information about these groups. In addition, certain Cisco IOS devices support more groups. Cisco 2500 routers, and AS5200 and AS5300 access servers support all nine groups on ethernet interfaces only. Cisco IOS-based switches such as 29xxXL and 85xx devices support four groups: statistics, history, alarm, and events. This set of four groups is also known as mini-RMON. Cisco Catalyst devices support the four mini-RMON groups. Cisco SwitchProbes and Network Analysis Modules (NAMs) support all of RMONv1 as well as RMONv2. Although RMONv1 was very centered on the OSI Layers 1 and 2, RMONv2 can be used to monitor points in the protocol stack all the way to Layer 7. The HC-RMON MIB (Internet draft draft-ietf-rmonmib-rmonhc-00.txt) adds 64-bit counter support to RMONv1 tables. It is not supported in Cisco IOS software; it is supported starting in Cisco Catalyst software version 5.1. |
1098
EAN: 2147483647
Pages: 200