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.
ifTable (ifEntry) | ifDescr | ifType | ifSpeed | ifAdminStatus |
---|---|---|---|---|
ifIndex.1 | Ethernet0/0 | 6 (ethercsmacd) | 10 Mbps | Up |
ifIndex.2 | Serial0/0 | 22 (propPointToPointSerial) | 128 kbps | Up |
Figure 4-1 shows a hierarchical representation of the ifTable.
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