MIB Viewer

SNMP GETBULK

GETBULK, introduced in SNMPv2c, does the same fundamental job as GETNEXT - retrieve whatever comes next in the tree - but can return many results in a single request/response exchange instead of exactly one. For anything involving a table with more than a handful of rows, this is the difference between a handful of packets and hundreds or thousands of them, and it's why GETBULK is what real-world table walks actually use today.

It's only available in SNMPv2c and SNMPv3 - SNMPv1 doesn't support it at all, and a v1-only device has to be walked the slower way, with repeated GETNEXT calls.

The two parameters that control it

A GETBULK request takes two extra parameters beyond the OIDs you're asking about:

  • non-repeaters - how many of the OIDs in your request should be treated as simple, single "give me the next one" lookups (like a plain GETNEXT), rather than repeated.
  • max-repetitions - how many "next" values to return for each of the remaining (repeating) OIDs, in one response.

In practice, for a typical table walk, non-repeaters is usually 0 and max-repetitions is set to something like 10-50, telling the agent "give me the next N rows of this table in one shot" rather than one row per request.

snmpbulkwalk -v2c -c public -Cn0 -Cr20 192.168.1.1 1.3.6.1.2.1.2.2.1.2

Most tools (like snmpbulkwalk above) handle the repeated GETBULK calls and the non-repeaters/max-repetitions tuning for you automatically - you rarely need to think about the exact numbers unless you're troubleshooting an unusually slow or failing walk.

Picking a reasonable max-repetitions

Set too low, and you lose most of the efficiency benefit GETBULK exists for - you're back to something close to one row per round trip. Set too high, and a single response can end up larger than the network's or agent's practical packet size limits, causing the agent to truncate the response or the request to fail outright on constrained/older hardware. Most tooling defaults to something reasonable (10-25 or so); it's rarely worth tuning manually unless you're dealing with an unusually large table or an agent with tight resource limits.

GETBULK vs. GETNEXT vs. GET

GET needs an exact OID and returns exactly one value per OID requested. GETNEXT walks one step at a time. GETBULK walks many steps at once, in a single exchange - functionally the same result as repeated GETNEXT calls, just dramatically more efficient for anything beyond a handful of values. If a specific device or an older SNMPv1-only agent doesn't support GETBULK, well-behaved tooling falls back to GETNEXT-based walking automatically.