Chapter 4. SNMP and MIBs
After studying this chapter, you should have a good understanding of the capabilities of the different SNMP protocol versions on Cisco network elements. Simple Network Management Protocol (SNMP) and Management Information Base (MIB) configuration examples and feature comparison tables help you understand and apply the information. This chapter also summarizes the most relevant accounting and performance MIBs.
Chapter 3, "Accounting and Performance Standards and Definitions," analyzes SNMP from a theoretical point of view. It describes the Internet management model and terminology, comparing the different SNMP versions, explaining the Structure of Management Information (SMI), and considering the SNMP operations.
This chapter explains how to configure SNMP on Cisco devices and how to use tools such as snmpget and snmpwalk to retrieve the managed objects content. However, the remote SNMP configuration of the accounting and performance MIB modules is a pure configuration task (remember the Configuration part of the FCAPS model). Therefore, the examples in this chapter do not explain the use of the snmpset utility.
The three different versions of SNMP (1, 2, and 3) clearly indicate the evolution of SNMP since the initial version, RFC 1067, in 1988. SNMPv1 is not used as much anymore. More and more MIB modules need the high-capacity counters (64-bit, counter64) specified in SMIv2, which in turn requires the SNMPv2c encodings. Furthermore, the SNMPv1 protocol has the status of historical, as designated by the IETF. Therefore, this chapter does not contain a specific SNMPv1 configuration example. Instead, the configuration of the SNMPv2c agent on the router implicitly enables SNMPv1.
After long discussions without a clear consensus, the IETF abandoned the SNMPv2 standard because of a flawed security portion in the initial design. As a result, the community-based approach of SNMPv2c was chosen. This chapter contains an example of SNMPv2c because it is still widely deployed in the current networks. SNMPv3 became the successor of SNMPv2 and is an IETF standard (RFC 3411).
This chapter also contains two SNMPv3 examples explained in detail. They cover authentication only (AuthNoPriv) and authentication combined with encryption (AuthPriv).
Every network element that can be managed by SNMP contains a Management Information Base (MIB), which is a conceptual data store for management information. The SMI defines the framework for constructing MIBs. RFC 1155, which specifies SMI version 1, was extended by RFC 2578 to SMI version 2. The basic elements are described by the Abstract Syntax Notation 1 (ASN.1) notation. The Basic Encoding Rule (BER) defines the elements coding. MIB managed objects are specified by a series of numbers called object identifiers (OID). The managed objects are arranged in a hierarchical tree.
For example, if you want to identify the ifPhysAddress, representing an interface's physical or MAC address, the OID is 1.3.6.1.2.1.2.2.1.6:
iso-1
org-3
dod-6
internet-1
mgmt-2
mib-21
interfaces-2
ifTable-2
ifEntry-1
ifPhysAddress-6
A specific instance of such a managed object is called a MIB variable or managed object instance (ifPhysAddress in the preceding example). The two different object types are scalar and column. A scalar object has only one instance, and a columnar object has multiple instances.
The focus of the MIBs described in this chapter is on accounting and performance management. The following books offer an in-depth description of SNMP and MIBs:
SNMP, SNMPv2, SNMPv3, and RMON 1 and 2, Third Edition, William Stallings, Addison-Wesley Professional, 1998.
A Practical Guide to SNMPv3 and Network Management, David Zeltserman, Prentice-Hall, 1999.
Understanding SNMP MIBs, David Perkins, Prentice-Hall, 1997.
MIB objects need to be polled by a Network Management System. Remember that the first priority of a router or switch is to forward packets. Therefore, depending on the platforms, the SNMP counters might not be updated in real time. Distributed platform systems such as line cards and Versatile Interface Processors (VIP) do not update the counters in real time, because this would overload the internal bus with counter update messages. Polling the counters less frequently than every 30 seconds is a good deployment guideline.
