What do the SNMP GetRequest, GetNextRequest, GetBulkRequest and SetRequest PDUs each ask an agent to do, and what comes back?
answer
- four requests, one kind of reply
- exact name versus next name
- many successors in one exchange
- a write that is all or nothing
- request-id pairs reply with request
basics
~20 sGetRequest reads exactly the named instances; GetNextRequest returns each name's successor in OID order; GetBulkRequest returns many successors at once; SetRequest writes values all or nothing. Each is answered by a Response-PDU with the same request-id, an error-status and an error-index.
solid answer
~40 sAll four are requests from a manager (a command generator) to an agent (a command responder), and the agent answers each with a `Response-PDU` (RFC 3416). `GetRequest` reads the instances whose names match exactly, such as `sysUpTime.0`. `GetNextRequest` returns, for each name, the first instance that follows it in lexicographic OID order, which is how a manager discovers instances it cannot name in advance. `GetBulkRequest` does the same repeatedly, governed by `non-repeaters` and `max-repetitions`, so one exchange returns many rows. `SetRequest` writes values, and its bindings succeed or fail together. The Response copies the request's `request-id`, so the manager can match it to the right outstanding request, and carries `error-status`, `error-index` and the variable bindings.
go deeper
Recall the four request PDUs and the one reply: exact read, next read, bulk read, all-or-nothing write, each answered by a Response-PDU with the same request-id.
Explain why GetNext exists at all: it returns the name of what it found, so a manager can discover instances, and GetBulk repeats that step inside one exchange.
Show you read error-status and error-index before trusting values, and that you choose GetBulk over chained GetNext when polling large tables on busy devices.
Frame the operations as a polling budget: request type, bindings per request and retry policy decide how much load a monitoring system puts on every agent it watches.
## The request and response model SNMP moves management information between two roles. RFC 3416, the protocol-operations document of the SNMP Internet Standard (STD 62), calls them a **command generator** (traditionally the *manager*) and a **command responder** (traditionally the *agent*). The manager sends a request; the agent processes it against the managed objects it exposes and sends back exactly one reply. Every request carries a **variable-binding list**: a list of pairs, each holding a *name* (an OBJECT IDENTIFIER that identifies one instance of an object, such as `sysUpTime.0`) and a *value*. In a retrieval request the value is ignored, and RFC 3416 defines the `unSpecified` NULL for that slot. The transport is UDP: RFC 3416 asks only for an unreliable datagram service, with every message contained in a single datagram, and RFC 3417 suggests that agents listen on UDP port 161. ## The four requests | PDU | ASN.1 tag | What the agent does with each binding | Bindings in the reply | |---|---|---|---| | `GetRequest-PDU` | `[0]` | returns the value of the instance whose name matches **exactly** | one per request binding | | `GetNextRequest-PDU` | `[1]` | returns the **first lexicographic successor** of the name, with its own name and value | one per request binding | | `GetBulkRequest-PDU` | `[5]` | returns one successor for the first *N* bindings and up to *M* successors for each remaining one | up to N + M x R | | `SetRequest-PDU` | `[3]` | validates every binding, then assigns all values **as if simultaneously** | one per request binding | The reply to all four is the `Response-PDU`, tag `[2]`. (SNMPv1, RFC 1157, now Historic, called it `GetResponse-PDU`.) - **GetRequest** is for names you already know: a scalar such as `sysUpTime.0`, or a column instance whose index you know. - **GetNextRequest** is for names you do not know. Because it returns the *next* name along with its value, a manager can start at a column's OID and keep feeding back the name it just received, which is how tables are walked. - **GetBulkRequest** is GetNext with a repeat count. Its `BulkPDU` replaces `error-status` and `error-index` with `non-repeaters` and `max-repetitions`, so one exchange can carry many rows. It travels only in SNMPv2c and SNMPv3 messages. - **SetRequest** is the only write. The agent checks every binding first and assigns nothing unless all of them pass; if an assignment then fails, the others are undone. ## What a Response-PDU carries 1. **`request-id`**: copied from the request. With several requests outstanding over UDP, this is the only field that ties a reply to its request. 2. **`error-status`**: `noError` (0), or a reason such as `tooBig` (1), `genErr` (5) or one of the SetRequest validation errors. 3. **`error-index`**: zero, or the position (counting from **one**) of the binding in the request that caused the error. 4. **`variable-bindings`**: the names and values. In SNMPv2 and later, an individual binding can carry an **exception** (`noSuchObject`, `noSuchInstance`, `endOfMibView`) instead of a value while `error-status` stays `noError`. When `error-status` is non-zero, RFC 3416 says the manager ignores the values in the bindings. ## One exchange, step by step 1. The manager builds a `GetRequest` naming `sysUpTime.0` and `ifDescr.1`, chooses a fresh `request-id`, and sends it to the agent. 2. The agent looks up each name in the MIB view this request is allowed to see. 3. It fills in each value (or an exception), sets `error-status` to `noError` and `error-index` to 0, and checks that the reply fits the largest message the manager can accept. 4. The manager receives the `Response-PDU`, matches its `request-id`, and hands the bindings to the application that asked. If no reply comes, RFC 3416 leaves retransmission to the requesting application and asks it to act responsibly about how often and how long it retries (BCP 41). ## What these PDUs are not The agent never sends a Response unasked. Unsolicited notifications use other PDUs (`SNMPv2-Trap-PDU`, `InformRequest-PDU`), which have different delivery rules. The `Report-PDU` belongs to the administrative framework, not to reads and writes. And a `Response-PDU` is not a value dump: it is a reply whose status fields have to be read before its values are trusted. ## Why the distinctions matter Many polling problems trace back to choosing the wrong request: a `GetRequest` used where the instance names are unknown, chained `GetNextRequest`s used to read a large table that `GetBulkRequest` would fetch in far fewer exchanges, or a `SetRequest` split into several requests so that a failure leaves the device half-configured. Knowing what each PDU promises is what lets you pick the right one.
- Why does an SNMP GetRequest carry a value field in each binding if the agent ignores it?Every PDU shares one variable-binding structure: a name paired with a value. RFC 3416 defines the `unSpecified` NULL for the value slot of retrieval requests, and the agent ignores it. The field must still be validly encoded, because the agent parses the whole PDU before acting on it.
- What should an SNMP manager do when no Response arrives for a request?Retransmit or give up; RFC 3416 leaves the choice to the application and asks it to retry responsibly, in line with BCP 41's congestion principles. Reusing the `request-id` lets a late reply to either copy satisfy the request; a new `request-id` lets the manager measure round-trip time, and RFC 3416 recommends that for most cases.
saying these in an interview costs you the question
- GetNextRequest returns the value of the OID you name.
- GetBulkRequest is just a GetRequest that names many OIDs at once.
- A SetRequest applies its bindings one by one, so earlier ones stick when a later one fails.
- Responses are matched to requests by the order in which they arrive.
- An agent answers a GetRequest by sending a trap back to the manager.