snmpwalk - retrieve a subtree of management values

snmpwalk [application options] [common options] [oid]

uses SNMP GETNEXT requests to query a network entity for a tree of information.

An object identifier (OID) may be given on the command line, specifies which portion of the object identifier space will be searched using GETNEXT requests. All variables in the subtree below the given OID are queried and their values presented to the user. Each variable name is given in the format specified in variables.

If no OID argument is present, snmpwalk will search the subtree rooted at SNMPv2-SMI::mib-2 (including any MIB object values from other MIB modules, that are defined as lying within this subtree). If the network entity has an error processing the request packet, an error packet will be returned and a message will be shown, helping to pinpoint why the request was malformed.

-Cc Do not check whether the returned OIDs are increasing.
Some agents (LaserJets are an example) return OIDs out of order, but can complete the walk anyway.
Other agents return OIDs that are out of order and can cause snmpwalk to loop .
By default, snmpwalk tries to detect this behavior and warns you when it hits an agent acting illegally. Use -Cc to turn off this check.
-CE {OID} End the walk at the specified OID, rather than a simple subtree.
Used to walk a partial subtree, selected columns of a table, or even two or more tables within a single command.
-Ci Include the given OID in the search range. Normally snmpwalk uses GETNEXT requests starting with the OID you specified and returns all results in the MIB subtree rooted at that OID.
you may wish to include the OID specified on the command line in the printed results if it is a valid OID in the tree itself. This option lets you do this explicitly.
-CI In fact, the given OID will be retrieved automatically if the main subtree walk returns no useable values.
This allows a walk of a single instance to behave as generally expected, and return the specified instance value. This option turns off this final GET request, so a walk of a single instance will return nothing.
-Cp Upon completion of the walk, print the number of variables found.
-Ct Upon completion of the walk, print the total wall-clock time it took to collect the data (in seconds). The timer is started before the beginning of the data request series and stopped after it finishes, does not include snmp library initialization, shutdown, argument processing, and any other overhead.

In addition to these options, snmpwalk takes the common options described in snmpcmd

examples

Retrieve all of the variables under system:
       snmpwalk -Os -c public -v 1 zeus system

       sysDescr.0 = STRING: "SunOS zeus.net.cmu.edu 4.1.3_U1 1 sun4m"
       sysObjectID.0 = OID: enterprises.hp.nm.hpsystem.10.1.1
       sysUpTime.0 = Timeticks: (155274552) 17 days, 23:19:05
       sysContact.0 = STRING: ""
       sysName.0 = STRING: "zeus.net.cmu.edu"
       sysLocation.0 = STRING: ""
       sysServices.0 = INTEGER: 72
       (plus the contents of the sysORTable).

retrieve the scalar values, but omit the sysORTable.
       snmpwalk -Os -c public -v 1 -CE sysORTable zeus system
SEE ALSO snmpcmd(1), snmpbulkwalk(1), variables(5).
USAGE: snmpwalk [OPTIONS] AGENT [OID]

  Version:  5.6
  Web:      http://www.net-snmp.org/
  Email:    net-snmp-coders@lists.sourceforge.net

OPTIONS:
  -h, --help        display this help message
  -H            display configuration file directives understood
  -v 1|2c|3     specifies SNMP version to use
  -V, --version     display package version number
SNMP Version 1 or 2c specific
  -c COMMUNITY      set the community string     (public)
SNMP Version 3 specific
  -a PROTOCOL       set authentication protocol (MD5|SHA)
  -A PASSPHRASE     set authentication protocol pass phrase
  -e ENGINE-ID      set security engine ID (e.g. 800000020109840301)
  -E ENGINE-ID      set context  engine ID (e.g. 800000020109840301)
  -l LEVEL          set security level (noAuthNoPriv|authNoPriv|authPriv)
  -n CONTEXT        set context name (e.g. bridge1)
  -u USER-NAME      set security name (e.g. bert)
  -x PROTOCOL       set privacy protocol (DES|AES)
  -X PASSPHRASE     set privacy protocol pass phrase
  -Z BOOTS,TIME     set destination engine boots/time
General communication options
  -r RETRIES        set the number of retries
  -t TIMEOUT        set the request timeout (in seconds)
Debugging
  -d            dump input/output packets in hexadecimal
  -D[TOKEN[,...]]   turn on debugging output for the specified TOKENs
               (ALL gives extremely verbose debugging output)
General options
  -m MIB[:...]      load given list of MIBs (ALL loads everything)
  -M DIR[:...]      look in given list of directories for MIBs
    (default: /Users/uusseerr/.snmp/mibs:/usr/share/snmp/mibs)
  -P MIBOPTS        Toggle various defaults controlling MIB parsing:
              u:  allow the use of underlines in MIB symbols
              c:  disallow the use of "--" to terminate comments
              d:  save the DESCRIPTIONs of the MIB objects
              e:  disable errors when MIB symbols conflict
              w:  enable warnings when MIB symbols conflict
              W:  enable detailed warnings when MIB symbols conflict
              R:  replace MIB symbols from latest module
  -O OUTOPTS        Toggle various defaults controlling output display:
              0:  print leading 0 for single-digit hex characters
              a:  print all strings in ascii format
              b:  do not break OID indexes down
              e:  print enums numerically
              E:  escape quotes in string indices
              f:  print full OIDs on output
              n:  print OIDs numerically
              q:  quick print for easier parsing
              Q:  quick print with equal-signs
              s:  print only last symbolic element of OID
              S:  print MIB module-id plus last element
              t:  print timeticks unparsed as numeric integers
              T:  print human-readable text along with hex strings
              u:  print OIDs using UCD-style prefix suppression
              U:  don't print units
              v:  print values only (not OID = value)
              x:  print all strings in hex format
              X:  extended index format
  -I INOPTS     Toggle various defaults controlling input parsing:
              b:  do best/regex matching to find a MIB node
              h:  don't apply DISPLAY-HINTs
              r:  do not check values for range/type legality
              R:  do random access to OID labels
              u:  top-level OIDs must have '.' prefix (UCD-style)
              s SUFFIX:  Append all textual OIDs with SUFFIX before parsing
              S PREFIX:  Prepend all textual OIDs with PREFIX before parsing
  -L LOGOPTS        Toggle various defaults controlling logging:
              e:           log to standard error
              o:           log to standard output
              n:           don't log at all
              f file:      log to the specified file
              s facility:  log to syslog (via the specified facility)

              (variants)
              [EON] pri:   log to standard error, output or /dev/null for level 'pri' and above
              [EON] p1-p2: log to standard error, output or /dev/null for levels 'p1' to 'p2'
              [FS] pri token:    log to file/syslog for level 'pri' and above
              [FS] p1-p2 token:  log to file/syslog for levels 'p1' to 'p2'
  -C APPOPTS        Set various application specific behaviours:
              p:  print the number of variables found
              i:  include given OID in the search range
              I:  don't include the given OID, even if no results are returned
              c:  do not check returned OIDs are increasing
              t:  Display wall-clock time to complete the request
              E {OID}:  End the walk at the specified OID


variables

Format of specifying variable names to SNMP tools.

The syntax and semantics of management information in SNMP is given by the definitions of MIB objects, loaded from one or more MIB files (or "MIB modules"). These definitions are not strictly required for the SNMP protocol to operate correctly, but are typically needed by SNMP client applications to display information in a meaningful manner. The MIB file also serves as a design document when developing an SNMP agent (or sub-agent) that provides this information, and ensures that client and server share a common understanding about what management information represents.

OIDs

MIB objects are specified using Object Identifiers (OIDs), which can take a number of forms. Note that all of the examples in this section refer to the same MIB object.

Numeric OIDs

The fundamental format of an OID is a sequence of integer values (or "subidentifiers"), typically written using dots to separate the individual subidentifiers.
.1.3.6.1.2.1.1.1
This is the format that is used within the SNMP protocol itself, in the packets that are sent over the network.

This form of representing an OID does not require MIB files or MIB object definitions to be available. However it does rely on the client application and/or network administrator knowing what a given numeric OID refers to. As such, it is not a particularly helpful representation to anyone just starting out with SNMP.

This format can be obtained by giving the command-line option -On to most Net-SNMP commands.

Full OID path

A similar (but somewhat more informative) format uses the same dotted list representation, but with the numeric subidentifiers replaced by names, taken from the relevant MIB file(s).
.iso.org.dod.internet.mgmt.mib-2.system.sysDescr
This uniquely identifies a particular MIB object (as with the numeric OID), but the list of names should hopefully give some indication as to what information this object represents. However it does rely on the relevant MIB files being available (as do all formats other than the purely numeric OID). Such OIDs also tend to be fairly long!

This format can be obtained by giving the command-line option -Of to most Net-SNMP commands.

A variant of this (typically used when writing OIDs in descriptive text, rather than running programs), is to combine the name and numeric subidentifier: .iso(1).org(3).dod(6).internet(1).mgmt(2).mib-2(1).system(1).sysDescr(1)

Module-qualified OIDs

An alternative way to (more-or-less) uniquely specify an OID, is to give the name of the MIB object, together with the MIB module where it is defined.
SNMPv2-MIB::sysDescr
MIB object names are unique within a given module, so as long as there are not two MIB modules with the same name (which is unusual, though not unheard of), this format specifies the desired object in a reasonably compact form. It also makes it relatively easy to find the definition of the MIB object.

This is the default format for displaying OIDs in Net-SNMP applications. It can also be specified explicitly by giving the command-line option -OS to most Net-SNMP commands.

Object name

Possibly the most common form for specifying MIB objects is using the name of the object alone - without the full path or the name of the module that defines it.
sysDescr
This is by far the shortest and most convenient way to refer to a MIB object. However the danger is that if two MIB modules each define a MIB object with the same name (which is perfectly legal in some circumstances), then it's not necessarily clear which MIB object is actually meant. For day-to-day use, particularly when using standard MIB objects, this is probaby safe. But it's important to be aware of the potential ambiguities.

This format can be obtained by giving the command-line option -Os to most Net-SNMP commands.

UCD-format

Previous versions of the code (UCD v4.x and earlier) used a simple approach to shortening the way OIDs were specified. If the full path of the OID began with .iso.org.dod.internet.mgmt.mib-2 then this prefix was removed from the OID before displaying it. All other OIDs were displayed in full.

Similarly, if an OID was passed to the UCD library that did not begin with a dot (and wasn't in the module::name for- mat), then the same prefix was prepended. The example OID from the formats listed above would therefore be given or displayed as

system.sysDescr
The inconsistent handling of OIDs, depending on their location within the OID tree, proved to be more trouble than it was worth, and this format is no longer recommended.

The previous behaviour can be obtained by giving the command-line option -Ou (for displaying output), or -Iu (for interpreting input OIDs without a leading dot) to most Net-SNMP commands.