tools

snmpwalk Command Guide: Syntax, Examples & Options

Walk an SNMP subtree with snmpwalk — v2c and v3 syntax, output formatting, snmpbulkwalk for large tables, and common errors.

By the SNMP Monitoring team · Reviewed July 2026

snmpwalk is the command you'll type more than any other in SNMP work. It walks a whole subtree — issuing a chain of GetNext requests and printing every object it finds — so you can discover what a device exposes, dump a table, or sanity-check that your agent config actually works. This guide covers the syntax for v2c and v3, ready-to-copy examples for the metrics you'll actually query, the output flags that make results readable, and the two errors everyone hits. It's a how-to; for the OID reference side, cross to the sensor index.

Parent: tools. Siblings: snmpget, Net-SNMP, MIB browser.

Basic syntax

The anatomy of a walk is a version, a credential, a host, and a starting OID:

snmpwalk -v2c -c <community> <host> <OID|MIB-name>

From that starting point, snmpwalk uses GetNext to step through every OID underneath it, stopping when it leaves the subtree. The flags you'll use most:

FlagMeaning
-v 1|2c|3SNMP version
-c <community>Community string (v1/v2c)
-OnPrint numeric OIDs
-OsShort OID names
-OqvValues only (no OID)
-t / -rTimeout / retries

A bare snmpwalk -v2c -c <community> <host> with no OID walks from the default start, which usually dumps the entire MIB-2 subtree — handy for discovery, noisy for anything else.

v2c examples

Walk the system group to confirm identity and uptime:

snmpwalk -v2c -c S3cr3tR0str1ng 10.0.0.20 system
SNMPv2-MIB::sysDescr.0 = STRING: Linux app01 5.15.0-generic x86_64
SNMPv2-MIB::sysUpTime.0 = Timeticks: (45678901) 5 days, 6:53:09.01
SNMPv2-MIB::sysName.0 = STRING: app01

Walk host-resources storage to see disks and RAM:

snmpwalk -v2c -c S3cr3tR0str1ng 10.0.0.20 hrStorageDescr
HOST-RESOURCES-MIB::hrStorageDescr.1 = STRING: Physical memory
HOST-RESOURCES-MIB::hrStorageDescr.31 = STRING: /
HOST-RESOURCES-MIB::hrStorageDescr.32 = STRING: /var

Walk the interface table to list NICs:

snmpwalk -v2c -c S3cr3tR0str1ng 10.0.0.20 ifName
IF-MIB::ifName.1 = STRING: lo
IF-MIB::ifName.2 = STRING: eth0
IF-MIB::ifName.3 = STRING: eth1

Each of these is a discovery step — you learn the index numbers, then use snmpget to read specific instances. This walk-then-get pattern is the backbone of most SNMP work: a table's row indices aren't predictable in advance (an interface might be index 2 on one box and index 7 on another), so you walk once to map the names to indices, then query the specific instances you care about from then on. It's why snmpwalk is a discovery tool first and a monitoring tool second — you reach for it when you're figuring out what a device offers, not when you're polling the same metric every thirty seconds in production.

A reliable discovery routine when you meet a new device:

  1. Walk system first to confirm the credential works and identify the box.
  2. Walk ifName (or ifDescr) to map interface indices to names.
  3. Walk hrStorageDescr to see disks and memory and their indices.
  4. Note the indices you care about, then switch to snmpget for ongoing polls.

One habit worth forming early: always start a walk as high in the tree as you can tolerate and no higher. Walking system gives you three or four lines; walking from the root gives you the entire device and can take minutes on a large router while hammering the agent. Scope the starting OID to the subtree you actually want, and the walk stays fast and readable.

v3 examples

For an authenticated, encrypted walk, swap the community for a v3 user and security level:

snmpwalk -v3 -l authPriv -u monitor -a SHA -A "AuthPass" -x AES -X "PrivPass" 10.0.0.20 system

The flags map directly: -l authPriv sets the level, -u the user, -a SHA -A the auth protocol and passphrase, -x AES -X the privacy protocol and passphrase. Everything after the host works identically to v2c — only the credential handling changes. See SNMPv3 setup for creating the user these flags reference.

Output formatting

The -O flags reshape output for humans or for scripts. The ones that earn their keep:

  • -On — numeric OIDs, when a name won't resolve or you need the raw number.
  • -Os — short names, dropping the MIB prefix for readability.
  • -Oqv — values only, perfect for piping one metric into a script.
  • -Ofn — full numeric path, the most verbose form.

For example, -Oqv strips everything but the value:

snmpwalk -v2c -c S3cr3tR0str1ng -Oqv 10.0.0.20 sysUpTime
5 days, 6:53:09.01

That's the difference between output meant to be read and output meant to be parsed.

snmpwalk vs snmpbulkwalk

On a large table, plain snmpwalk is slow — it's one GetNext round-trip per object, and a full interface table on a busy router is hundreds of them. snmpbulkwalk uses GetBulk (v2c and later) to fetch many objects per request, cutting the round-trips dramatically:

snmpbulkwalk -v2c -c S3cr3tR0str1ng 10.0.0.20 ifTable

Same output, far fewer packets. Use snmpbulkwalk whenever you're walking a big table and the agent supports v2c+; keep plain snmpwalk for small subtrees and v1 agents. The whole suite is covered on Net-SNMP.

Common errors

Two failures dominate. A timeoutTimeout: No Response from <host> — means no reply came back: a firewall block, the agent isn't running, a wrong host/port, or a source-IP ACL. It's rarely a credential problem. A noSuchObject (v2c) or noSuchName (v1) means the agent replied but the OID isn't there — a typo, an unimplemented MIB, or an OID outside your VACM view. Distinguishing "no reply" from "the agent replied with an error" points you at the right fix; the full playbook is on troubleshooting.

Frequently asked questions

How do I use snmpwalk?

Run snmpwalk -v2c -c <community> <host> <OID-or-name> — for example snmpwalk -v2c -c public 10.0.0.20 system. It walks the subtree beneath the starting OID using GetNext and prints every object. For v3, replace -c with -u <user> -l authPriv -a SHA -A <authpass> -x AES -X <privpass>.

What's the difference between snmpwalk and snmpbulkwalk?

snmpwalk issues one GetNext per object, which is simple but slow on large tables. snmpbulkwalk uses GetBulk (SNMPv2c and later) to retrieve many objects in a single request, greatly reducing round-trips. Use snmpbulkwalk for big tables on v2c+ agents; snmpwalk is fine for small subtrees or v1.

How do I show numeric OIDs in snmpwalk?

Add the -On flag: snmpwalk -On -v2c -c <community> <host> <OID>. This prints dotted-decimal OIDs instead of resolving them to MIB names — useful when a name won't resolve because a MIB isn't loaded, or when you need the exact numeric OID for a script or config.

Why does snmpwalk time out?

A timeout means no response came back at all — usually a firewall blocking UDP 161, the agent not running, the wrong host or port, or a source-IP ACL that excludes your machine. It's normally not a credential issue. Confirm reachability and that snmpd is running; see troubleshooting for the full workflow.

Key takeaways

  • snmpwalk walks a subtree via GetNext: snmpwalk -v2c -c <community> <host> <OID>.
  • Use -v3 -l authPriv -u … -a SHA -A … -x AES -X … for authenticated, encrypted walks.
  • Format with -On (numeric), -Os (short), -Oqv (values only).
  • For big tables use snmpbulkwalk (GetBulk) — far fewer round-trips.
  • Timeout = no reply (firewall/agent/host); noSuchObject = bad or out-of-view OID.
  • Pair with snmpget for single values; explore OIDs via the sensor index.

Monitor it from outside the network

SNMP only tells you a box is healthy while something is still asking. ostr.io polls your endpoints externally and fires email + SMS alerts the moment a reading crosses your line — or the agent goes silent.