Book HomeEssential SNMPSearch this book

8.2. Retrieving Multiple MIB Values

The syntax for snmpwalk is similar to the syntax for its cousin, snmpget. As discussed in Chapter 2, "A Closer Look at SNMP", snmpwalk traverses a MIB starting with some object, continuously returning values until it gets to the end of that object's branch. For example, the upcoming Perl script begins walking the .iso.org.dod.internet.mgmt.mib-2.interfaces.ifTable.ifEntry.ifDescr object and provides a description of each Ethernet interface on the device it polls.

This new script is a minor modification of snmpget.pl. We turned the scalar $value into the array @values;[33] we need an array because we expect to get multiple values back. We also called the function snmpwalk instead of snmpget (syntactically, the two functions are the same):

[33]The Perl program we used earlier could have used the array instead of the scalar as well. This is possible because Perl's version of snmpget allows for multiple OIDs, not just one. To specify multiple OIDs, place a comma (,) between each OID. Remember to enclose each OID within its own double quotes.

#!/usr/local/bin/perl
#filename: /opt/local/perl_scripts/snmpwalk.pl
use SNMP_util;
$MIB1 = shift;
$HOST = shift;
($MIB1) && ($HOST) || die "Usage: $0 MIB_OID HOSTNAME";
(@values) = &snmpwalk("$HOST","$MIB1");
if (@values) { print "Results :$MIB1: :@values:\n"; }
else { warn "No response from host :$HOST:\n"; }
Here's how to run the script:

$ /opt/local/perl_scripts/snmpwalk.pl .1.3.6.1.2.1.2.2.1.2 orarouter1
This command walks down the .iso.org.dod.internet.mgmt.mib-2.interfaces.ifTable.ifEntry.ifDescr object, returning information about the interfaces that are on the router. The results look something like this:

Results :.1.3.6.1.2.1.2.2.1.2: :1:Ethernet0 2:Serial0 3:Serial1:
The output depends on the interfaces on the host or router you are polling. To give some examples, I've run this script against some of the machines on my network. Here are the results.

Cisco 7000 router:

Results :.1.3.6.1.2.1.2.2.1.2: :1:Ethernet0/0 2:Ethernet0/1 3:TokenRing1/0 
4:TokenRing1/1 5:TokenRing1/2 6:TokenRing1/3 7:Serial2/0 8:Serial2/1  
9:Serial2/2 10:Serial2/3 11:Serial2/4 12:Serial2/5 13:Serial2/6 14:Serial2/7 
15:FastEthernet3/0 16:FastEthernet3/1 17:TokenRing4/0 18:TokenRing4/1:
Sun workstation:

Results :.1.3.6.1.2.1.2.2.1.2: :1:lo0 2:hme0:
Windows NT PC:

Results :.1.3.6.1.2.1.2.2.1.2: :1:MS TCP Loopback interface 
2:PCI2 Token-Ring Network 16/4 Adapter         :
APC uninterruptible power supply:

Results :.1.3.6.1.2.1.2.2.1.2: :1:peda:
For each device, we see at least one interface. As you'd expect, the router has many interfaces. The first interface on the router is listed as 1:Ethernet0/0, the second is listed as 2:Ethernet0/1, and so on, up through interface 18. SNMP keeps track of interfaces as a table, which can have many entries. Even single-homed devices usually have two entries in the table: one for the network interface and one for the loopback interface. The only device in the example above that really has a single interface is the APC UPS -- but even in this case, SNMP keeps track of the interface through a table that is indexed by an instance number.

This feature allows you to append an instance number to an OID to look up a particular table element. For example, we would use the OID .1.3.6.1.2.1.2.2.1.2.1 to look at the first interface of the Cisco router, .1.3.6.1.2.1.2.2.1.2.2 to look at the second, and so on. In a more human-readable form, ifDescr.1 is the first device in the interface description table, ifDescr.2 is the second device, and so on.

8.2.1. Walking the MIB Tree with OpenView

Switching over to OpenView's snmpwalk, let's try to get every object in the .iso.org.dod.internet.mgmt.mib-2.system subtree:

$ /opt/OV/bin/snmpwalk oraswitch2 .1.3.6.1.2.1.1
system.sysDescr.0 : DISPLAY STRING- (ascii):  Cisco Internetwork Operating 
System Software IOS (tm) C2900XL Software (C2900XL-H-M), Version 11.2(8)
SA1,RELEASE SOFTWARE (fc1)Copyright (c) 1986-1998 by cisco Systems, Inc.
Compiled Tue 03-Feb-98 14:59 by rheaton
system.sysObjectID.0: OBJECT IDENTIFIER: 
.iso.org.dod.internet.private.enterprises.cisco.ciscoProducts.cisco2509
system.sysUpTime.0 : Timeticks: (168113316) 19 days, 10:58:53.16
system.sysContact.0 : DISPLAY STRING- (ascii):  J.C.M. Pager 555-1212
system.sysName.0 : DISPLAY STRING- (ascii):  oraswitch2.ora.com
system.sysLocation.0 : DISPLAY STRING- (ascii): Sebastopol CA
system.sysServices.0 : INTEGER: 6
Let's go to the GUI MIB Browser and try that same walk. Repeat the steps you took for the snmpget using the GUI. This time insert the OID .1.3.6.1.2.1.1 and hit the "Start Query" button. Check out the results.

TIP: The GUI figures out whether it needs to perform an snmpwalk or snmpget. If you give an instance value (being specific), the browser performs an snmpget. Otherwise, it does an snmpwalk. If you are looking for more speed and less cost to your network, include the instance value.

What will happen if you walk the entire .iso subtree? It may hurt or even crash your machine, because in most cases the device can return several thousand values. Each interface on a router can add thousands of values to its MIB tables. If each object takes .0001 seconds to compute and return, and there are 60,000 values to return, it will take your device 6 seconds to return all the values -- not counting the load on the network or on the monitoring station. If possible, it is always a good idea to perform an snmpwalk starting at the MIB subtree that will provide you with the specific information you are looking for, as opposed to walking the entire MIB.

It might be useful to get a feel for how many MIB objects a given device has implemented. One way to do this is to count the number of objects each snmpwalk returns. This can be accomplished with the Unix grep command. The -c switch to grep tells it to return the number of lines that matched. The period (.) tells grep to match everything. Starting from the .system object (.1.3.6.1.2.1.1), let's go back one and see how many objects are implemented in the mib-2 subtree. Take off the last .1 off the object ID and run the snmpwalk command again, this time piping the results into grep -c:

$ /opt/OV/bin/snmpwalk oraswitch2 .1.3.6.1.2.1 |  grep -c .
The number of objects you see will depend on the type of device and the software running on it. When I tried several different devices, I got results ranging from 164 to 5193.

This command is great when you want to walk a MIB to see all the types of values that a device is capable of returning. When I am trying out a new device or MIB, I often walk some decent-sized portion of the MIB and read through all the returned values, looking for any info that may be of interest. When something catches my eye, I go to the MIB definition and read its description. Many GUI MIB Browsers allow you to check the description with the click of a button. In OpenView's GUI, click on the OID and then on "Describe."

8.2.2. Walking the Tree with Net-SNMP

Net-SNMP's snmpwalk is very similar in form and function to OpenView's. Here's how you use it:

$ snmpwalk orarouter1 public .1.3.6.1.2.1.1
system.sysDescr.0 = Cisco Internetwork Operating System Software 
IOS (tm) C820 Software (C820-Y6-M), Version 12.1(3)XG3, EARLY DEPLOYMENT RELEASE
SOFTWARE (fc1)
TAC:Home:SW:IOS:Specials for info
Copyright (c) 1986-2000 by cisco Systems, Inc.
Compiled Wed 20-Dec-00 16:21
system.sysObjectID.0 = OID: enterprises.9.1.284
system.sysUpTime.0 = Timeticks: (100946413) 11 days, 16:24:24.13
system.sysContact.0 = [email protected]
system.sysName.0 = [email protected]
system.sysLocation.0 = Sebastopol CA
system.sysServices.0 = 6
system.sysORLastChange.0 = Timeticks: (0) 0:00:00.00
There aren't any real surprises. Again, you can use an object name instead of a numerical ID; because you're walking a tree, you don't need to specify an instance number.



Library Navigation Links

Copyright © 2002 O'Reilly & Associates. All rights reserved.