skip to content

In an SNMP Response-PDU, what do error-status and error-index tell the manager, and how do SNMPv2 exceptions such as noSuchInstance differ?

level: middleimportance: should knowfreq 20%

answer

  1. whole request versus one binding
  2. index counts from one
  3. non-zero status voids every value
  4. object missing or instance missing
  5. SNMPv1 failed the whole request

basics

~20 s

A non-zero error-status says the whole request failed, and error-index names the failing binding, counting from one. SNMPv2 exceptions instead mark one binding (noSuchObject, noSuchInstance, endOfMibView) while error-status stays noError and the other values are returned.

solid answer

~40 s

`error-status` is a verdict on the **whole** request: `noError`, or a reason such as `tooBig`, `genErr` or a SetRequest validation error. When it is non-zero, RFC 3416 says the binding values are ignored, and a non-zero `error-index` gives the position of the failing binding in the request, counting from one. SNMPv2 added **exceptions**, which live inside a single binding instead: `noSuchObject` when the name falls under no object the request can see, `noSuchInstance` when the object exists but that instance does not, and `endOfMibView` when a GetNext or GetBulk runs off the end of the view. With an exception, `error-status` stays `noError` and every other binding keeps its value. SNMPv1 had no exceptions: one missing name failed the whole request with `noSuchName`.

go deeper

for a junior

Remember that error-status judges the whole request, error-index counts from one, and SNMPv2 marks a missing name inside its own binding.

for a middle

Explain the three exceptions and when each appears, why values are ignored under a non-zero error-status, and what tooBig's empty reply means.

for a senior

Read noSuchObject versus noSuchInstance as a diagnosis, design pollers that survive one unsupported object, and recognise that view restrictions look like absence.

for a principal

Treat per-binding exceptions as data-quality signals across a fleet, distinguishing unsupported objects, vanished rows and access gaps in what a monitoring platform reports.

## Two levels of failure An SNMP `Response-PDU` (RFC 3416) can say "something went wrong" at two different levels, and confusing them is the root of many broken pollers. - **Request level.** The `error-status` field says whether the request as a whole succeeded. If it is anything other than `noError`, RFC 3416 tells the manager to ignore the values in the variable bindings: none of them is a trustworthy answer. - **Binding level.** Since SNMPv2, an individual variable binding can carry an **exception** in place of its value. The request still succeeds, `error-status` is `noError`, and every other binding carries a normal value. ## error-status and error-index `error-status` is an INTEGER drawn from a fixed list. For retrievals the ones that matter are: | Value | Name | Meaning for a retrieval | error-index | |---|---|---|---| | 0 | `noError` | the request succeeded | 0 | | 1 | `tooBig` | the reply would not fit the size limit | 0 | | 5 | `genErr` | a binding failed for a reason no other code covers | the failing binding | The remaining codes (`noAccess`, `wrongType`, `wrongValue`, `notWritable`, `inconsistentValue`, `commitFailed`, `undoFailed` and others) come from SetRequest processing. Three more, `noSuchName` (2), `badValue` (3) and `readOnly` (4), are kept "for proxy compatibility": an SNMPv2 agent never generates them, but RFC 3416 requires a manager to handle them in a reply. `error-index` points at the culprit. RFC 3416 is explicit that **the first variable binding is index one**, the second index two, and so on, and that the index refers to the binding list **of the request**. Zero means "no particular binding": success, `tooBig`, or a SetRequest `undoFailed`. ## The three SNMPv2 exceptions | Exception | Raised by | What it means | |---|---|---| | `noSuchObject` | GetRequest | the name does not fall under any object type the request can see | | `noSuchInstance` | GetRequest | the object type exists, but there is no instance with this index | | `endOfMibView` | GetNextRequest, GetBulkRequest | nothing follows this name in the request's MIB view | The difference between the first two is diagnostic gold. `noSuchObject` for `ifHCInOctets.3` says this agent does not implement that column (or does not let this request see it). `noSuchInstance` says the column is there but row 3 is not, perhaps because the interface was removed. Exceptions are also how SNMPv2 keeps access control quiet: an object outside the request's MIB view is reported exactly as if it did not exist, so a retrieval does not reveal that a hidden object is there. ## The same mistake under SNMPv1 and SNMPv2 Picture a poller that bundles ten names into one `GetRequest`, one of which this device model does not implement. 1. **SNMPv1 (RFC 1157, now Historic).** The agent answers with `error-status` `noSuchName` and `error-index` pointing at the bad binding. The other nine values are not delivered. The manager must remove that name and send the request again, and one unsupported object blanks the whole poll until someone notices. 2. **SNMPv2c or SNMPv3.** The agent answers `noError`, nine bindings carry values, and the tenth carries `noSuchObject`. The poller records nine values and flags one gap. RFC 3584 (BCP 74) describes the translation in between: when an agent serves an SNMPv1 request, a `noSuchObject`, `noSuchInstance` or `endOfMibView` exception becomes `noSuchName` with the matching `error-index`. ## tooBig and the empty reply When a reply to a Get, GetNext or Set would exceed either the agent's own limit or the largest message the manager can accept, an SNMPv2 agent sends an alternate Response with `tooBig`, `error-index` 0 and an **empty** binding list. If even that does not fit, it drops the reply silently and increments `snmpSilentDrops` (RFC 3418). The manager's cure is fewer bindings per request. GetBulk has no `tooBig` path: it trims bindings from the end instead. ## Reading a reply in the right order - Check `request-id` to match the reply to its request. - Check `error-status`; if it is non-zero, use `error-index` to find the cause and **ignore the values**. - Only then read the bindings, treating each exception as a per-name result, never as a value.

  • An SNMPv2c GetRequest for ten names returns tooBig; what should the poller change?
    Split the request: send fewer bindings per GetRequest, or raise the maximum message size the manager accepts if the path allows it. A tooBig reply carries error-index 0 and an empty binding list, so no value from it is usable and the request has to be sent again in smaller pieces.
  • Why might an SNMP agent answer noSuchObject for an object that is in its MIB?
    Because exceptions are judged against what the request may see, not against what the agent implements. An object outside the request's MIB view is reported as if it did not exist, so a missing access grant and a missing implementation look identical in the reply.

saying these in an interview costs you the question

  • error-index counts from zero, so 0 means the first binding failed.
  • With a non-zero error-status, the other bindings still carry valid values.
  • noSuchInstance means the agent does not implement the object at all.
  • An SNMPv2 agent answers a missing name with the noSuchName error.
  • An exception in one binding sets error-status to genErr.