skip to content

An SNMP agent answers noSuchObject for an object its device's MIB module defines; how can the agent's MIB view explain that?

level: middleimportance: should knowfreq 18%

answer

  1. the agent never shows everything
  2. accessible by this request
  3. hidden looks the same as absent
  4. exception values, not an error-status
  5. chosen per request, by who is asking

basics

~20 s

An SNMP agent answers each request only from the MIB view selected for that requester. An object outside the view is treated exactly like one that does not exist, so a Get gets noSuchObject or noSuchInstance and a walk skips it.

solid answer

~50 s

An SNMP agent never exposes "the MIB" as a whole. For each incoming message the administrative framework picks a **MIB view** - in SNMPv1 and v2c from the community, in SNMPv3 from the user, security level and context - and the command responder processes the PDU against only the variables "accessible by this request" (RFC 3416 §4.2). A `GetRequest` for an object type with no accessible instance gets `noSuchObject` in that varbind; an accessible type with a missing instance gets `noSuchInstance`; a `GetNextRequest` returns the next *accessible* object, so hidden subtrees are skipped and a walk can reach `endOfMibView` early. The answer carries no reason: an object out of view is indistinguishable from one the agent never implemented. So `noSuchObject` can mean an unimplemented module, an excluding view or the wrong context - retry with a broad-view principal before blaming the device. If no view applies at all, the whole request fails with `authorizationError`.

go deeper

for a junior

Remember that an agent shows each requester only a subset of its objects, and that a hidden object looks exactly like a missing one.

for a middle

Walk through RFC 3416's rules - noSuchObject, noSuchInstance, endOfMibView, and SNMPv1's noSuchName - and say which principal selects the view in each version.

for a senior

Diagnose an unexpected noSuchObject by separating an unimplemented module, a restrictive view and a wrong context, using a known broad-view principal as the control.

for a principal

Decide which managers and tools get which views across an estate, trading least privilege against the silent data gaps a narrow view creates in shared dashboards.

## What a MIB view is A **MIB module** defines managed objects - their names (OBJECT IDENTIFIERs), syntax and meaning. A device's **agent** implements some set of those objects. But the agent does not answer every requester from that whole set. RFC 1157 already defined an **SNMP MIB view** as "a subset of objects in the MIB that pertain to" a network element, and noted that it need not be a single subtree. In SNMPv3, RFC 3415 defines a MIB view as a combination of included and excluded **view subtrees** - every object instance sharing an OID prefix. The practical consequence: two managers polling the same agent can see different objects, because each request is answered from the view that its credentials select. ## How a request gets its view The chain is the same in every version; only the selector differs: 1. The message arrives on the agent's UDP 161 and the **SNMP engine** authenticates it as far as its security model allows. 2. The administrative framework maps the message to a principal: in SNMPv1 the **community** selects a community profile (an access mode plus a MIB view, RFC 1157 §3.2.5); in SNMPv2c the community is mapped the same way (RFC 3584 describes the coexistence tables); in SNMPv3 the **user**, the **security level** and the **context** go to the access control model. 3. The command responder asks, for each variable, whether it is in view - RFC 3413 §3.2 calls this the `isAccessAllowed` check - and builds the response from the variables that are. How views are defined and granted per user is the access control model's business; what matters here is the *effect* on what the agent exposes. ## What the requester actually sees RFC 3416 §4.2 phrases every rule in terms of variables "accessible by this request": | Request | Situation | Agent's answer | |---|---|---| | `GetRequest` | object type not accessible at all | varbind value `noSuchObject` | | `GetRequest` | type accessible, instance missing | varbind value `noSuchInstance` | | `GetNextRequest` | next object lies outside the view | the next *accessible* object instead | | `GetNextRequest` | nothing accessible after the name | `endOfMibView` | | any | no view applies to the principal | error-status `authorizationError`, error-index 0 | | any (SNMPv1) | object not available | error-status `noSuchName` | The last row is the older behaviour: SNMPv1 has no per-varbind exception values, so a missing or hidden object fails the whole request with `noSuchName`. In SNMPv2c and v3 the exceptions sit inside the individual varbinds and the rest of the response is still useful. Two details deserve attention: - **Hidden equals absent.** Nothing in the reply says "you may not see this". An object outside the view gets the same answer as one the agent never implemented, so an unauthorised requester cannot even confirm that the object exists. - **A walk shrinks quietly.** Because `GetNextRequest` and `GetBulkRequest` jump to the next accessible object, a restricted view makes a table walk skip rows or columns without any error - the manager just receives fewer objects. ## Diagnosing an unexpected noSuchObject When a manager gets `noSuchObject` for an object the MIB module defines, there are three common explanations: - **The agent does not implement that module** (or that object) at all - common for optional groups. - **The view excludes it** for this community or user, so it is hidden rather than missing. - **The request names the wrong context.** RFC 3411 §3.3.1 defines a context as a collection of management information; the same agent may hold several, and an object present in one need not appear in another. A quick discriminator is to repeat the request with a principal you know has a broad view. If the object appears, the view - not the device - is the cause. A related surprise: on an extensible agent built with AgentX, an object whose subagent has not registered (or has died) is likewise not accessible. ## Why the view lives in the agent The view is enforced where the objects are. RFC 3413 §1.5 draws the line explicitly: a **command responder** "must have the detailed definition of the MIB view", while a **proxy forwarder** relays requests by context "irrespective of the managed object types" and has no need of one. On an AgentX agent, the master agent applies the views on behalf of every subagent (RFC 2741 §4.1). Either way, the manager cannot widen what it sees from its own side; only the agent's configuration can.

  • When does an SNMP agent return authorizationError instead of a per-varbind exception?
    When the access check finds no usable view for the principal at all - RFC 3413 §3.2 lists noSuchView, noAccessEntry and noGroupName. The command responder then halts, returns the original varbinds with error-status `authorizationError` and error-index 0. A view that exists but excludes the object yields `noSuchObject` or `noSuchInstance` in that varbind instead.
  • Why might a walk of a table return fewer rows for one SNMP community than for another?
    `GetNextRequest` and `GetBulkRequest` return the next object *accessible by this request* (RFC 3416). If one community's view excludes some columns or rows, the walk skips them silently and may reach `endOfMibView` sooner. Nothing in the response signals the omission, so compare walks with both credentials.

saying these in an interview costs you the question

  • noSuchObject proves the agent does not implement that MIB module.
  • An object outside the view returns authorizationError pointing at that varbind.
  • Every manager sees the same objects on an agent, because the MIB is fixed.
  • A proxy forwarder filters each relayed object through its own MIB view.
  • A walk that ends early means the table on the device is short.