Summary

  • SNMP GetNext returned the first accessible OBJECT IDENTIFIER after the requested name, so a manager could reuse each answer as the starting point for the next request.
  • Repeated successors made conceptual tables traversable without a prior list of row indices; leaving the intended subtree, not merely receiving an error, marked the table boundary.
  • SNMPv2 added per-binding endOfMibView and GetBulk efficiency, while access-control views, response limits and changing device state kept every walk partial and time-bound.

The manager began with a name that was not yet a row

Suppose a management station wants the destinations and next hops in a router's table. It knows the column identifiers defined by the MIB, but the instance suffixes belong to rows that exist on this device now. Asking an ordinary GetRequest for the bare column name will not enumerate them.

The 1988 specification in RFC 1067 offered a smaller operation. For each name in a GetNextRequest, the agent locates the immediate successor in the lexicographic ordering of variables available for get operations in the relevant MIB view. The response carries that successor's name as well as its value.

The name is the crucial part. If the first reply contains an instance ending in one route index, the manager sends that complete returned name in the next GetNextRequest. The agent advances to the next accessible instance. Repetition turns a single successor rule into a walk.

No separate “give me all rows” command is required. The manager owns the loop; the agent answers one ordered question at a time.

A table emerged from ordered identifiers

SNMP's Management Information Base was a virtual information store, not a relational database. Objects had globally structured OBJECT IDENTIFIER names. A table column and an instance index were combined into the name of a concrete variable. RFC 2578 later gave the SMIv2 form of these conceptual tables and INDEX clauses.

RFC 1067's worked example makes the design physical. A manager starts with three route-table column names. The reply supplies the first indexed destination, next hop and metric. The manager repeats those returned names and receives the next row. The ordering of numeric OID components, not the alphabetical order of friendly labels, determines what “next” means.

This was consistent with SNMP's larger economy. The early architecture deliberately minimized functions in the agent. Managers polled variables; a limited set of traps redirected the timing and focus of that polling. A rich inventory operation could be constructed at the edge from a thin shared primitive.

The end of a table was not necessarily an error

A lexicographic namespace continues after one table. When the final instance in a column has been returned, the next successor may be the first instance of the next column. After the final object in the target table, the successor may be an entirely different object elsewhere in the accessible MIB view.

RFC 3416 illustrates both transitions. A response can “wrap” to the next column and then leave the IP net-to-media table. That outside name is useful evidence: it tells the manager that the requested subtree has ended. It is not a malformed response.

The manager therefore has a duty the agent cannot infer: define the intended prefix and stop when a returned name no longer belongs beneath it. A walk that waits only for a protocol error can continue into unrelated management data and call the excess a discovery.

SNMPv1's terminal behavior was also coarse. Under RFC 1157, if any requested name did not precede an accessible successor, the response used noSuchName and an error index. One exhausted column could compromise the usefulness of a multi-binding request.

SNMPv2 made absence local to a binding

RFC 1448 changed the ordinary end condition. When one requested name has no lexicographic successor, its response binding can carry endOfMibView. Other bindings can still return names and values. RFC 1905 retained that model on the Standards Track, and RFC 3416 carries it into the current protocol-operations specification.

This was more than friendlier error reporting. It preserved the independence of several simultaneous walks. One column could finish while another continued. The result did not say that the device had no other information; it said that this binding had no later accessible name in the view governing this request.

SNMPv2 also introduced GetBulk. The first non-repeaters receive one successor each; the remaining bindings may receive up to max-repetitions successive positions. The same table can be traversed with fewer request-response exchanges.

But “bulk” never meant “complete.” A responder may return fewer bindings than the arithmetic maximum. Message-size limits still apply. RFC 1905 warns managers to choose repetition counts with path fragmentation in mind, especially under network stress. GetBulk batches the successor rule; it does not suspend transport physics.

The walk revealed a view, not the device in full

The word “accessible” appears inside the successor rule. It is not decoration. The administrative framework selects the MIB view visible to the operation. RFC 3415 defines views from included and excluded subtrees inside a context and allows different groups to receive different subsets.

Two properly authorized managers can therefore ask the same device for the successor to the same OID and receive different truthful answers. An excluded object is skipped as though it were not in that request's ordered list. endOfMibView proves the end of accessible names for that operation; it cannot prove that no hidden object, private module, other context or more privileged view exists.

Time creates a second boundary. A walk is a series of exchanges. The route table may change between the first and last reply, and GetBulk does not supply snapshot isolation. RFC 3416's example retrieves sysUpTime beside table values, which helps place observations in time, but the protocol does not turn separately sampled rows into one atomic inventory.

Sources and limits

The mechanism and its evolution are established by RFC 1067, RFC 1157, RFC 1448, RFC 1905, RFC 2578, RFC 3415 and RFC 3416. They establish naming, successor processing, table examples, bulk retrieval and view scoping. They do not certify a vendor implementation, measure present deployment, guarantee secure transport or make a walk proof of operational effect.