Some notes on using
snmpwalk to poke at devices with SNMP
Suppose, not hypothetically, that you're exploring what some
device exposes over SNMP. You're probably using
snmpbulkwalk). Snmpwalk is
probably completely clear to people who use it all of the time, but
it's not clear to people like me who touch it only once in a while.
So here are some notes from my recent experiences (for future me,
among others), assuming general background in reading SNMP.
To start with, many of the interesting snmpwalk options are covered
in the snmpcmd manual page because they're
common across all of the 'snmp*' commands. Generally you'll
want to specify some SNMP version (often '
-v2c', but some old
devices may require '
-v1') and the public community ('
If you have collected vendor MIBs for your
device and put them in a directory, you'll want to add that directory
to the search list and then load some or all MIB modules:
snmpwalk -M +/tmp/mibs -m +VENDOR-MIB1:VMIB2 -v2c -c public ....
-m ALL' is what you want, which tells snmpwalk to load all
of the MIBs it can find. Generally you don't want to use -M without
a + or a -, because vendor MIBs will try to import things from
standard MIBs and fail if the standard MIB search path has been
scrubbed away (ask me how I know).
As the snmpwalk manual page says, if you don't give it an OID to start from it starts from SNMPv2-SMI::mib-2, 126.96.36.199.2.1, and only looks at things underneath that. If you're exploring a device's SNMP information, this is probably not what you want. If you want to see everything, start from OID 1:
snmpwalk [...] example.com .1
(The leading '.' forces snmpwalk to consider this a fully qualified OID and start from the root.)
If you're pretty certain that what you're looking for is in the proper vendor-specific OID space, you can start from there:
snmpwalk [...] example.com .188.8.131.52.4.1
You can further restrict this to a specific vendor OID, ege
184.108.40.206.4.1.21317, and this can be useful in various situations
(there are some standard things under this 'vendor' OID prefix,
such as a standard set of Net-SNMP MIBs). If you know the root
identifier name of a MIB you're interested in, you can also specify
where to start from as '<MIB>::<root>', eg '
however, this may require reading the MIB to find the identifier
(If you're a keen person you can remember that 220.127.116.11.4.1 is
also known as '
SNMPv2-SMI::enterprises', and actually it can
be shortened to '
If you're lucky, you'll have a vendor MIB and it will be accurate.
If you're not, you're trying to explore what information is there
and you'll probably start wanting some snmpwalk -O output options.
One useful one is '
-Oa', which gets snmpwalk to display more
things as strings (there's also '
-OT', but really why bother).
If you want to see what OIDs are being found under some level, you
may want to de-clutter the output by forcing all numeric OIDs with
As far as I know, there's no option to snmpwalk to tell it to exclude output for known MIBs and only give you unknown OIDs, which would make it convenient to fish for non-standard areas of the device's SNMP OID tree. The best you can do is snmpwalk things and fish for appropriate patterns, like:
snmpwalk -v2c -c public example.com enterprises | fgrep SNMPv2-SMI::enterprises.
It turns out that another way to find the specific vendor OID root is to query for the special OID SNMPv2-MIB::sysObjectID:
; snmpwalk -v2c -c public example.com sysObjectID SNMPv2-MIB::sysObjectID.0 = OID: SNMPv2-SMI::enterprises.21317
(This special OID is 18.104.22.168.22.214.171.124 if you need it in OID form, which you may do on some systems where installing SNMP tools doesn't also pull in standard MIBs for you. Thanks, Ubuntu.)
Note that this may not give you all of what the vendor stashes away in SNMP. On one of our Dells that I checked, this reports only about enterprises.674.10892.5, when there is other stuff at enterprises.674.10892.2 as well.