snmpwalk and snmpget: MIB and OID Troubleshooting

SNMP is the backbone of every monitoring platform, and the two commands you debug it with are snmpget for a single value and snmpwalk for a subtree. When they fail the error messages are precise but easy to misread - a timeout and a noSuchName look like different faults, and a missing .0 index produces an error that send people hunting for the wrong MIB. This guide covers the failure modes in the order you should test them.

The Three Parts of Every Request

snmpget -v 2c -c demopublic 10.0.0.5 SNMPv2-MIB::sysUpTime.0
#        ^ver  ^community ^target  ^OID

snmpwalk -v 3 -l authPriv -u monitor -a SHA -A "authpass"   -x AES -X "privpass" 10.0.0.5 1.3.6.1.2.1.2.2

Where to send the request, how to authenticate (v1/v2c community or v3 user plus security level), and which object you want. Isolating which of the three is wrong is the whole of SNMP troubleshooting.

Error 1: Unknown Object Identifier or "No Such Instance"

Scalar objects always require an instance suffix, and for scalars that suffix is .0. Omitting it produces an error rather than a useful value:

$ snmpget -v 2c -c demopublic 10.0.0.5 sysUpTime
SNMPv2-MIB::sysUpTime = No Such Instance currently exists

$ snmpget -v 2c -c demopublic 10.0.0.5 sysUpTime.0
SNMPv2-MIB::sysUpTime.0 = Timeticks: (586731977) 67 days, 21:48:39.77

Case matters as well: object descriptors are case-sensitive, so sysuptime is not recognised while sysUpTime is. If the name is simply unknown, the MIB is not loaded - solve that with the -m flag or by naming the module explicitly:

snmpget -m ALL -v 2c -c demopublic 10.0.0.5 sysUpTime.0
snmpget -v 2c -c demopublic 10.0.0.5 RFC1213-MIB::sysUpTime.0
snmptranslate -On IF-MIB::ifDescr

Note that the module name is used, not the file name, and that snmptranslate -On converts a symbolic OID into dotted numeric form, which is often the fastest way to give a vendor TAC the exact object you are querying.

Error 2: Timeouts

snmpwalk -v 2c -c public -t 5 -r 2 -On 10.0.0.5 .1.3.6.1.2.1.1

A timeout with a snmpwalk that normally works usually means access control on the agent rather than a network problem: the community string is wrong, or the source address is outside the permitted range. Confirm the agent is reachable at all - nc -u -z 10.0.0.5 161 or an ICMP ping - then check the device's configured SNMP access list. Under SNMPv3, a timeout with the correct credentials almost always means the engine ID does not match, which happens after an engine reboot that changed the ID.

Error 3: Empty or Partial Walks

An agent that ends early with "End of MIB" is not necessarily broken - the subtree you asked for may simply be empty on that platform. But an agent that returns OIDs out of order can loop forever, which is why snmpwalk checks for increasing OIDs by default. Some older agents require the check to be disabled:

snmpwalk -Cc -v 1 -c public 10.0.0.5 system
snmpwalk -CE sysORTable -v 1 -c public 10.0.0.5 system   # stop at an OID
snmpwalk -Cp -Ct -v 2c -c public 10.0.0.5 1.3.6.1.2.1.2   # count + timing

-Cp prints the number of variables found and -Ct the wall-clock collection time - both are useful when comparing polls against a slow device before adding it to a monitoring system at 60-second intervals.

SNMPv3 Troubleshooting Order

Test in escalating security levels rather than jumping to authPriv. If -l noAuthNoPriv works but -l authNoPriv does not, the authentication protocol or password is wrong. If authNoPriv works but authPriv does not, the privacy protocol or passphrase is wrong. This three-step test isolates which credential is misconfigured in about a minute.

Turning It Into Monitoring

Once the walk returns sane data, point a poller at those exact OIDs. Adding a device to Zabbix or Prometheus without confirming the OIDs by hand is how you end up with graphs of nothing - see Zabbix SNMP monitoring for network devices. Traps are a separate path with their own configuration, covered in SNMP traps and snmptrapd.

原文链接：https://www.net-snmp.org/wiki/index.php/TUT:snmpget