-
Notifications
You must be signed in to change notification settings - Fork 2
TUT:snmpwalk
The snmpwalk command is designed to perform a
sequence of chained GETNEXT requests automatically, rather than having
to issue the necessary snmpgetnext requests by hand.
The command takes a single OID, and will display a list of all the results which lie within the subtree rooted on this OID:
% snmpwalk`` ``-v`` ``2c`` ``-c`` ``demopublic`` ``test.net-snmp.org`` ``system
SNMPv2-MIB::sysDescr.0 = HP-UX net-snmp B.10.20 A 9000/715
SNMPv2-MIB::sysObjectID.0 = OID: enterprises.ucdavis.ucdSnmpAgent.hpux10
SNMPv2-MIB::sysUpTime.0 = Timeticks: (586998396) 67 days, 22:33:03.96
SNMPv2-MIB::sysContact.0 = Wes Hardaker wjhardaker@ucdavis.edu
SNMPv2-MIB::sysName.0 = net-snmp
SNMPv2-MIB::sysLocation.0 = UCDavis
SNMPv2-MIB::sysORLastChange.0 = Timeticks: (0) 0:00:00.00
SNMPv2-MIB::sysORID.1 = OID: SNMPv2-MIB::snmpMIB
SNMPv2-MIB::sysORID.2 = OID: IF-MIB::ifMIB
SNMPv2-MIB::sysORID.4 = OID: IP-MIB::ip
SNMPv2-MIB::sysORID.5 = OID: UDP-MIB::udpMIB
SNMPv2-MIB::sysORDescr.1 = The Mib module for SNMPv2 entities.
SNMPv2-MIB::sysORDescr.2 = The MIB module to describe generic objects for network interface sub-layers
SNMPv2-MIB::sysORDescr.4 = The MIB module for managing IP and ICMP implementations
SNMPv2-MIB::sysORDescr.5 = The MIB module for managing UDP implementations
SNMPv2-MIB::sysORUpTime.1 = Timeticks: (82) 0:00:00.82
SNMPv2-MIB::sysORUpTime.2 = Timeticks: (81) 0:00:00.81
SNMPv2-MIB::sysORUpTime.4 = Timeticks: (83) 0:00:00.83
SNMPv2-MIB::sysORUpTime.5 = Timeticks: (82) 0:00:00.82
It can also be used with a single MIB (scalar) object, or even an exact instance OID - returning the corresponding value:
% snmpwalk -v 2c -c demopublic test.net-snmp.org sysDescr
SNMPv2-MIB::sysDescr.0 = HP-UX net-snmp B.10.20 A 9000/715
% snmpwalk -v 2c -c demopublic test.net-snmp.org sysDescr.0
SNMPv2-MIB::sysDescr.0 = HP-UX net-snmp B.10.20 A 9000/715
Conversely, it's also possible to start the walk at a higher level, retrieving more than one group of information.
% snmpwalk -v 2c -c demopublic test.net-snmp.org .iso
would typically retrieve all the information known to an agent. (Output omitted here, for obvious reasons!)
The first example above contains both scalar and table instances.
Snmpwalk can also be used for retrieving a single column of a table,
by specifying the column object as the starting point.
% snmpwalk`` ``-v`` ``2c`` ``-c`` ``demopublic`` ``test.net-snmp.org`` ``sysORID
SNMPv2-MIB::sysORID.1 = OID: SNMPv2-MIB::snmpMIB
SNMPv2-MIB::sysORID.2 = OID: IF-MIB::ifMIB
SNMPv2-MIB::sysORID.4 = OID: IP-MIB::ip
SNMPv2-MIB::sysORID.5 = OID: UDP-MIB::udpMIB
Note that when retrieving a full table (either alone, or as part of a
wider walk), all the values for one column are displayed before moving
on to the next. This can be seen in the output of walking the system
group above.
This is precisely the behaviour described in the snmpgetnext
tutorial for a chain of GETNEXT requests.
However it sometimes comes as a surprise to those new to SNMP, who
expect such tables to be displayed one row at a time. The snmptable
command may provide a more familiar view of such tables.
If the agent does not implement any MIB objects underneath the specified
OID, then the snmpwalk command may return without displaying anything
at all, or it may display a vaguely informative message, depending on
the SNMP version being used:
% snmpwalk -v`` ``1 -c demopublic test.net-snmp.org ifXTable
(nothing displayed)
% snmpwalk -v`` ``2c -c demopublic test.net-snmp.org ifXTable
IF-MIB::ifXTable = No Such Object available on this agent at this OID
Alternatively, if the requested tree is later than the last MIB instance that the agent implements, a slightly different message will be displayed:
% snmpwalk -v`` ``1 -c demopublic test.net-snmp.org .2.0
End of MIB
% snmpwalk -v`` ``2c -c demopublic test.net-snmp.org .2.0
joint-iso-ccitt.0 = No more variables left in this MIB View (It is past the end of the MIB tree)
But in each case, the meaning is the same - the agent had nothing relevant to display.
Exactly the same behaviour holds if the agent does implement MIB objects within the requested subtree, but the access control settings are configured to deny access to them. That is effectively the same as not implementing these objects at all. (At least for the given administrative information settings)
The snmpwalk is designed to retrieve multiple OIDs and values from the
remote agent. But unlike most of the other command-line tools, it can
only work with a single starting OID. It is not possible to supply
multiple OIDs as part of the same command.
Or more accurately - it is possible to specify several OIDs, but everything other than the first one will be ignored!