SNMP GETNEXT

GETNEXT doesn't ask for a specific OID's value directly - it asks the agent for whatever comes immediately after a given OID, in the agent's own tree order. That distinction is what makes it possible to walk through an entire subtree of data without needing to already know every individual OID in it ahead of time, which is exactly what GET requires.

How walking actually works

The classic pattern - what snmpwalk does under the hood in its simplest form - is a loop: start with a base OID (say, the root of a table), issue a GETNEXT, get back the next OID and its value, then issue another GETNEXT using that OID as the new starting point, and repeat. You keep going until the returned OID falls outside the subtree you started in, which tells you you've walked past the end of what you were looking for.

snmpgetnext -v2c -c public 192.168.1.1 1.3.6.1.2.1.2.2.1.2

That single command doesn't return the whole ifDescr column - it returns exactly one thing: whatever OID comes right after 1.3.6.1.2.1.2.2.1.2 in the agent's tree (typically 1.3.6.1.2.1.2.2.1.2.1, the first row) along with its value. A real walk repeats this, feeding each result back in as the next request.

"Next" means tree order, not just a bigger number

It's worth being precise about what "next" means here: it's lexicographic order across the whole OID tree, not simply "increment the last digit." If you GETNEXT the very last OID under one branch, the response can legitimately jump into a completely different, unrelated branch - whatever is lexicographically next in the agent's whole tree, not just nearby. That's actually how you detect you've walked past the end of what you meant to enumerate: the returned OID no longer starts with the prefix you were walking.

Why GETBULK mostly replaced it for real work

GETNEXT works, but it's one request and one response per single value - walking a table with a thousand rows means a thousand round trips. GETBULK, added in SNMPv2c, does the same fundamental "give me what's next" job but can return many results in a single exchange, which is why most modern tooling uses GETBULK for actual table walks and falls back to GETNEXT mainly for SNMPv1 devices (which don't support GETBULK at all) or for single, one-off "what comes after this" lookups.

End of the tree

If you GETNEXT past the very last OID the agent has, older implementations may return an error; SNMPv2c/v3 have a specific value for this case, endOfMibView, so a walking client can tell "there's genuinely nothing more" apart from a real error.