By the SNMP Monitoring team · Reviewed July 2026
PDUs are the verbs of SNMP. Get this. Walk next. Bulk-fetch that table. Set a value. Answer. Yell a trap. If you only memorize OIDs and never look at message types, troubleshooting stays superstition—"snmpwalk hung" without knowing whether you asked for GetNext storms or GetBulk.
This page names the common PDUs, when each shows up, and the fields you'll see in a capture or a debug log. Spec anchor: RFC 3416 (PDU definitions in the SNMPv3 architecture docs people still use for the type set). Parent: What is SNMP. Conversation flow: how it works.
What is a PDU in SNMP
PDU = Protocol Data Unit. Fancy way to say "the SNMP message type and its payload."
A manager doesn't send "please give CPU" as English. It sends a GetRequest (or friends) with varbinds—OID slots that come back filled with type + value in a Response. Notifications use different PDUs entirely (Trap / Inform).
Why care:
- Tooling maps 1:1 to PDUs (
snmpget≈ GetRequest,snmpwalk≈ GetNext/GetBulk loops,snmpset≈ SetRequest) - Errors live in Response fields (
error-status,error-index) - Version limits matter: GetBulk is not in SNMPv1
Also keep in mind:
- Request PDUs and notification PDUs fail differently—don't debug traps with Get timeouts
- Captures lie less than dashboards when you're arguing about what was sent
If a junior says "SNMP packet," ask which PDU. The answer tells you who started the talk and what they wanted.
The request PDUs
Manager → agent (usual direction):
- GetRequest — fetch these exact OIDs. Scalar smoke tests.
snmpget. - GetNextRequest — give me the next object after this OID. Classic walks. Slow on huge tables if that's all you use.
- GetBulkRequest — efficient multi-varbind retrieval (SNMPv2c+). What modern walks should use.
- SetRequest — write values. Needs write access. Most monitoring never should.
Bullets from the field:
- Prefer Get for known scalars (
sysUpTime.0). - Prefer GetBulk for tables (interfaces, storage, processes).
- GetNext is what old agents and v1-only paths force you into.
- Set is a change-control event, not a monitoring default.
Version matrix: versions.
GetBulk and performance
GetBulkRequest arrived with SNMPv2c (and exists in v3). It tells the agent "give me multiple successors" so you don't round-trip once per leaf like a GetNext crawl from hell.
Net-SNMP helper:
snmpbulkwalk -v2c -c <RO_string> <host> system
SNMPv2-MIB::sysDescr.0 = STRING: Linux poller-lab 6.1.0 ...
SNMPv2-MIB::sysObjectID.0 = OID: NET-SNMP-MIB::netSnmpAgentOIDs.10
SNMPv2-MIB::sysUpTime.0 = Timeticks: (72000) 0:12:00.00
SNMPv2-MIB::sysContact.0 = STRING: ops@example.com
Under the hood that's GetBulk (or a bulk-ish walk strategy), not you hand-crafting non-repeaters/max-repetitions every time—though libraries expose those knobs when you care.
When GetBulk misbehaves: agent implementation bugs, too-big responses (tooBig error-status), or middleboxes fragmenting UDP badly. Fall back carefully; don't assume v1 forever. Troubleshooting mindset: setup troubleshooting.
Plain walk for comparison (often GetNext loop):
snmpwalk -v2c -c <RO_string> <host> 1.3.6.1.2.1.1.3.0
DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (72000) 0:12:00.00
Response PDU
The agent answers requests with a Response PDU.
Older SNMPv1 docs called the reply GetResponse. In v2c/v3 naming, it's Response. Same job: echo request-id, fill varbinds or set error-status / error-index.
Managers match request-id to know which outstanding poll came home. If you timeout, you never got a Response—or it arrived after you gave up. UDP doesn't care about your feelings.
Notification PDUs (Trap, Inform)
Agent → manager (push):
- SNMPv2-Trap (and the older v1 trap format in legacy gear) — fire-and-forget event message toward UDP 162.
- InformRequest — like a trap that wants an acknowledgment and can retransmit (v2c+ world).
Polling vs push trade-offs: traps vs polling. Informs detail: informs.
Traps are not "Get in reverse" for continuous metrics. They're for discrete events. If you try to replace all polling with traps, you'll miss silent capacity creep and you'll still lose UDP messages.
PDU structure
Common fields you'll see discussed (exact encoding is BER; you rarely hand-edit that):
- request-id — correlate request and response
- error-status —
noError(0),tooBig(1),noSuchName(2),genErr(5), others - error-index — which varbind blew up (when relevant)
- variable-bindings (varbinds) — list of OID + value slots
| PDU | Direction | Typical version | Role |
|---|---|---|---|
| GetRequest | Manager → agent | v1+ | Read specific OIDs |
| GetNextRequest | Manager → agent | v1+ | Walk / next object |
| GetBulkRequest | Manager → agent | v2c / v3 | Efficient multi-get |
| SetRequest | Manager → agent | v1+ | Write |
| Response (GetResponse in v1) | Agent → manager | all | Reply or error |
| Trap / SNMPv2-Trap | Agent → manager | v1 / v2c+ | Unacked notification |
| InformRequest | Agent → manager | v2c+ | Acked notification |
When error-status isn't noError, read the index, fix the OID list or the view—don't just lengthen the timeout and hope. Glossary: glossary.
Mapping tools to PDUs (cheat sheet)
| You run… | You're roughly doing… |
|---|---|
snmpget | GetRequest → Response |
snmpwalk | repeated GetNext (or bulk under the hood) |
snmpbulkwalk | GetBulk-oriented walk |
snmpset | SetRequest → Response |
snmptrap / agent trap | Trap / SNMPv2-Trap toward 162 |
| informs | InformRequest + ack path |
When a GUI says "SNMP timeout," you don't know if GetBulk is too fat, Set is denied, or traps never left the box—unless you know which PDU the feature uses. Push vendors (and your own scripts) to log PDU type + error-status. Future you will thank present you.
Also: mixing v1-only devices into a v2c GetBulk template produces mysterious partial failures. Pin version per device class. See versions.
One more ops detail: error-index points at a varbind position starting from the conventions your stack documents—when you multi-get ten OIDs and one is not-in-view, the Response may carry an error while other bindings are empty or partial depending on agent. Don't assume atomic all-or-nothing without testing that agent. For flaky devices, split critical OIDs into separate Gets so one bad leaf doesn't poison the batch. Painful? Yes. Clearer pages at 2 a.m.? Also yes. Worth the extra Get every time.
Frequently asked questions
What is a PDU in SNMP?
A Protocol Data Unit—the SNMP message type (Get, GetBulk, Response, Trap, etc.) plus its fields (request-id, errors, varbinds). Defined in the RFC 3416 family of specs.
GetNext vs GetBulk?
GetNext returns the next object—fine but chattier for big tables. GetBulk (v2c+) pulls many successors per request. Prefer GetBulk when the agent supports it.
What replaced GetResponse?
In v2c/v3 naming, the reply PDU is Response. SNMPv1 literature called it GetResponse. Same role: answer the manager.
What is an InformRequest?
A notification that expects an acknowledgment and can be retransmitted—more reliable than a pure trap over UDP, at the cost of complexity. See informs.
Key takeaways
- PDUs = SNMP verbs; RFC 3416 is the type reference people cite.
- Requests: Get, GetNext, GetBulk (v2c+), Set → Response.
- Notifications: Trap / InformRequest.
- Fields: request-id, error-status, error-index, varbinds.
- Next: how it works, traps vs polling, versions.