When you decide that you want to write an SNMP monitoring application for a given device you need to start by understanding whats available to you. If you have a MIB you can read through it to get a feel. If you have MIB documentation you have an even better leg up. Whether you have a MIB or not, the best way to start out is to walk the device asking the device agent for every value it can supply you. Given this output you can then know exactly what is being reported where and how you want to tackle it in code.
The snmpwalk tool can walk the OID tree based on a starting OID or by default with no OID which just returns the MIB-II OIDs.
Lets walk a device (APC UPS) and look at whats output using the snmpwalk command.
$ snmpwalk -v1 -c public 10.10.1.224 SNMPv2-MIB::sysDescr.0 = STRING: APC Web/SNMP Management Card SNMPv2-MIB::sysObjectID.0 = OID: SNMPv2-SMI::enterprises.318.1.3.7 SNMPv2-MIB::sysUpTime.0 = Timeticks: (47372422) 5 days, 11:35:24.22 SNMPv2-MIB::sysContact.0 = STRING: Ben Rockwood SNMPv2-MIB::sysName.0 = STRING: APC-3425 SNMPv2-MIB::sysLocation.0 = STRING: 3425EDISON SNMPv2-MIB::sysServices.0 = INTEGER: 72 IF-MIB::ifNumber.0 = INTEGER: 1 IF-MIB::ifIndex.1 = INTEGER: 1 IF-MIB::ifDescr.1 = STRING: veya ........ SNMPv2-MIB::snmpOutGetResponses.0 = Counter32: 338 SNMPv2-MIB::snmpOutTraps.0 = Counter32: 0 SNMPv2-MIB::snmpEnableAuthenTraps.0 = INTEGER: 0 $
A large amount of the output was removed for clarity, but you get the idea. We can see the System, Interfaces, and SNMP groups from the MIB-II standard in the example output.
While the MIB-II information is interesting, unless your probing a basic router you'll want a lot more information than is supplied. To get an extended idea of whats available we need to give the tool a starting OID from which to walk. To see everything we can supply the enterprise OID, since all OIDs will start from that root. This can be done both with and without a MIB. Without a MIB you'll be forced to use a "best guess" approach to interpreting values. However if you do have a MIB the output is generally self explanatory and can serve as a reference when writing your application.
Lets first walk without a MIB (there is a lot of output, I recommend redirecting output to a file):
$ snmpwalk -v1 -c public 10.10.1.224 .1.3.6.1.4.1.318 SNMPv2-SMI::enterprises.318.1.1.1.1.1.1.0 = STRING: "Silcon DP340E" SNMPv2-SMI::enterprises.318.1.1.1.1.1.2.0 = STRING: "UPS_IDEN" SNMPv2-SMI::enterprises.318.1.1.1.1.2.1.0 = STRING: "314.10.D" .....
In this example we're asking the snmpwalk tool to walk all OIDs starting from our base OID .1.3.6.1.4.1.318 (the fully qualified OID up to the vendor identification, which is 318 for APC). For this device I get a total of 308 OIDs returned. However, because all we have to judge the OIDs meaning by is the output this isn't entirely helpful unless the OID value is a string.
If we do have a vendor MIB we can use that to walk the device and get far more useful output:
$ snmpwalk -v1 -c public -m "./APC-POWERNET.txt" 10.10.1.224 apc PowerNet-MIB::upsBasicIdentModel.0 = STRING: "Silcon DP340E" PowerNet-MIB::upsBasicIdentName.0 = STRING: "UPS_IDEN" PowerNet-MIB::upsAdvIdentFirmwareRevision.0 = STRING: "314.10.D" .....
In this example we're performing the same operation as before but we're supplying a MIB to be used (the -m option) and instead of using the numeric representation of the APC enterprise prefix we can simply use the unique identifier "apc" instead to accomplish the same thing. In both cases I returned a total of 308 OIDs, but clearly the MIB assisted output is far more understandable.
SNMP walking is the SNMP application developers equivalent to a port scan, providing a sound base on which to continue exploring and developing applications for your device. To avoid confusion it is recommended that all development begin by redirecting a full walk to a local file for reference.