snmpwalk on an SNMP-enabled device and been disappointed by the available information? There may well be a very simple reason for that.
The Net-SNMP implementation of the SNMP stack has some default settings that may be far from optimal in many cases. Specifically, the
snmpbulkwalk applications poll only a specific subset of the full MIB tree.
SNMP variables are arranged in a tree structure, each layer of which becomes more and more specific. Each node of this tree is assigned an unique OID formed from the path to this node, which may be translated by a MIB entry to something more human-readable. For example, a standard OID found on most devices is:
With the appropriate MIB files available, this will be translated to:
So far, so good.
snmpwalk should, as it’s name suggests, walk through the OID tree and report each node, translating the entries, as far as possible, from the available MIB library. However, if you run a default
snmpwalk against a device, forcing numeric OID output e.g.
snmpwalk -v2c -On -c <community> device
there is something a little strange about the returned list. The root node of the returned values is:
By default, both
snmpbulkwalk only walk the OID tree below this node. The problem is most manufacturer-specific information is not below this node, but rather this one:
To give you an example of the amount of data skipped by a default
snmpwalk, consider the following:
snmpwalk -v2c -c <community> <cisco837>
This default run against a local Cisco 837 router returns 4283 nodes and totals 256733 bytes.
snmpwalk -v2c -c <community> <cisco837> .18.104.22.168
Forcing the root node for the walk two levels higher in the tree returns 13553 nodes and totals 866504 bytes.
Next time you cannot find the information you require in an
snmpwalk, double-check that you’re looking at the whole tree and not just a small subset.