MIB Table Retrieval Example

In all previous SNMPv2c and SNMPv3 examples, a simple SNMP Get operation illustrated how to query a managed object. This section covers the other SNMP operations, such as SNMP Get-Next and Get-Bulk, and explains how the indexing works in an SNMP table. Even if in reality the ifTable contains more managed objects, the sample ifTable shown in Table 4-2 serves for illustration purposes. To simplify the examples, SNMPv2c is used.

Table 4-2. Table Representation of the ifTable
ifTable (ifEntry)ifDescrifTypeifSpeedifAdminStatus
ifIndex.1Ethernet0/06 (ethercsmacd)10 MbpsUp
ifIndex.2Serial0/022 (propPointToPointSerial)128 kbpsUp

Figure 4-1 shows a hierarchical representation of the ifTable.

Figure 4-1. Hierarchical Representation of the ifTable

[View full size image]

As required by the SNMP Get operation, the snmpget utility always needs to specify a leaf managed object:

SERVER % snmpget -c public -v 2c <router> ifDescr.1
RFC1213-MIB::ifDescr.1 = STRING: "Ethernet0/0"

However, the SNMP specifications do not impose a single SNMP request for each managed object to be polled; instead, multiple managed objects can be polled with a single request. For example, to poll all managed objects related to Serial0/0 in this table, a single SNMP Get operation is sufficient:

SERVER % snmpget -c public -v 2c router ifDescr.2 ifType.2 ifSpeed.2 ifAdminStatus.2
RFC1213-MIB::ifIndex.2 = INTEGER: Serial0/0
RFC1213-MIB::ifType.2 = INTEGER: 22
RFC1213-MIB::ifSpeed.2 = Gauge32: 10000000
RFC1213-MIB::ifAdminStatus.2 = INTEGER: up(1)


The SNMP Get-Next operation polls the next managed object. If you specify ifDescr.1 as the argument, Figure 4-1 shows that the next managed object is ifDescr.2:

SERVER % snmpgetnext -c public -v 2c router ifDescr.1
RFC1213-MIB::ifDescr.2 = STRING: "Serial0/0"

Following the same logic, a SNMP GetNext operation on ifDescr.2 returns the next object, which is ifType.1:

SERVER % snmpgetnext -c public -v 2c router ifDescr.2
RFC1213-MIB::ifType.1 = INTEGER: ehernetCsmacd(6)

The snmpwalk utility initiates a series of SNMP GetNext operations, one per polled managed object:

SERVER % snmpwalk -c public -v 2c router ifTable
RFC1213-MIB::ifIndex.1 = INTEGER: Ethernet0/0
RFC1213-MIB::ifIndex.2 = INTEGER: Serial0/0
RFC1213-MIB::ifDescr.1 = DISPLAY STRING-(ascii): Ethernet0/0
RFC1213-MIB::ifDescr.2 = DISPLAY STRING-(ascii): Serial0/0
RFC1213-MIB::ifType.1 = INTEGER: 6
RFC1213-MIB::ifType.2 = INTEGER: 22
RFC1213-MIB::ifSpeed.1 = Gauge32: 10000000
RFC1213-MIB::ifSpeed.2 = Gauge32: 128000
RFC1213-MIB::ifAdminStatus.1 = INTEGER: up(1)
RFC1213-MIB::ifAdminStatus.2 = INTEGER: up(1)

Executing the snmpbulkwalk -c public -v 2c router ifTable command returns exactly the same output as the snmpwalk -c public -v 2c router ifTable command. However, the SNMP Get-Bulk operation is used! Fewer SNMP packets are exchanged, which improves performance and reduces the bandwidth requirements to exchange management traffic.

Note that the snmptable utility repeatedly uses the SNMP GETNEXT or GETBULK requests to query for information on a MIB table and formats the output into a readable format. Especially interesting are the -Cb parameter, which displays only a brief heading (any common prefixes of the table field names are deleted), and the -Ci parameter, which prepends the entry's index to all printed lines. The following output displays the output of Table 4-2 with the snmptable utility:

SERVER % snmptable -c public -v 2c -Cb -Ci router ifTable
               SNMP table: IF-MIB::ifTable
 index Index  Descr                        Type     Speed  AdminStatus
     1     1  Ethernet0/0           ethercsmacd  10000000           up
     2     2  Serial0/0  propPointToPointSerial    128000           up

Part II: Implementations on the Cisco Devices