By the SNMP Monitoring team · Reviewed July 2026
You've probably already used SNMP without thinking hard about the wire. Graph spikes, a red CPU tile, somebody yells about a dead switch—behind that noise is a boring little UDP chat. Manager asks. Agent answers. Or the agent yells first (trap). That's most of the story.
Still, the details matter when a poll times out at 03:00 and you're staring at Wireshark. Below is the actual path of a query, a real snmpget for uptime, and how polling and traps fit together. Broader context lives under What is SNMP. Terms you can look up later: glossary.
The manager–agent model
Two players. Not three, not a mesh.
The manager is whatever is doing the asking—LibreNMS, Zabbix, a one-off shell on your laptop, a SaaS poller. It picks OIDs and timers. The agent sits on the box you care about (snmpd, a vendor daemon on a firewall, whatever ships with the appliance). It listens. It answers from its MIB. It does not stream metrics all day like a modern telemetry pipeline.
For almost every capacity graph you own, the manager started the conversation. Agents can push events (traps / informs). Day-to-day line charts still come from polls. Deeper layout of processes and AgentX: architecture.
You'll bump into three more things whether you like it or not:
- Credentials — community string on v2c, or SNMPv3 user/auth/priv
- A MIB that names objects and types
- OIDs that point at one scalar or one cell in a table
Skip any of those and "SNMP is broken" usually means "I guessed the string" or "that OID isn't on this image."
The request/response cycle, step by step
Forget the pretty sequence slides for a second. A Get looks like this in the real world:
- Manager builds a PDU. GetRequest is the simple case. GetNext and GetBulk show up when you're walking tables. Varbinds = OID list (value empty on a pure read).
- Packet leaves as UDP toward the agent, port 161. No TCP session. No keep-alive handshake. Fire and hope.
- Agent checks community or v3 USM, then tries to resolve the OID against what it actually implements—not against the PDF on Cisco's site from 2014.
- Agent stuffs a Response back: same request-id, each varbind filled with type + value, or an error status if you asked for something missing / not-in-view / too fat for the packet.
- Manager matches the request-id, stores the sample, maybe converts TimeTicks, maybe alerts. Product magic starts after the Response. The protocol itself is done.
SetRequest rides the same path but writes. Most shops never allow Set from the NMS. Read-only views keep you out of "someone flipped a VLAN via SNMP" tickets. PDU field-level stuff: PDU types.
UDP drops packets. That's not theoretical. Your poller retries; a silent host is unknown, not "looks fine, no data." I've watched people mark devices green because the last successful sample was still on screen. Don't do that.
Polling vs traps (pull vs push)
Polling = you ask on a clock. Interval, OID list, source IP—all under your control. Interface counters, disk, CPU: almost always polled.
Traps (and InformRequest) = the agent pokes your trap receiver on UDP 162 when something happens. Link down. Cold start. Vendor event. They're async. They do not replace a 5-minute poll for "how full is the disk," but they beat waiting five minutes to learn the uplink died.
Run both if you can. Poll for trends. Trap for discrete failures. Reliability quirks (unacked traps vs informs) are chewed over in traps vs polling.
A real example: reading uptime with snmpget
Enough talk. Net-SNMP on a host that still answers v2c:
snmpget -v2c -c public 192.0.2.10 1.3.6.1.2.1.1.3.0
What you hope to see:
DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (12345600) 1 day, 10:17:36.00
That single line is a full round trip. Manager sent GetRequest for 1.3.6.1.2.1.1.3.0 (sysUpTime.0). Agent replied Response, type TimeTicks, value in hundredths of a second since the SNMP engine (often the agent subsystem) came up—not always identical to "OS uptime," which bites people during agent restarts.
HOST-RESOURCES has another uptime-ish object: 1.3.6.1.2.1.25.1.1.0 (hrSystemUptime). Some templates poll both when they care about the difference. Tooling notes: snmpget, walks: snmpwalk.
And yes—public is a lab string. Don't ship it. Random RO community or v3. The example is for muscle memory, not production policy.
Where the data lives: MIB & OID
Agents don't freestyle field names. MIB modules define objects; OIDs address them. Your CLI might print a name if it loaded the same MIB; the wire is still numeric.
Common PDUs in one ugly table:
| PDU | Who starts it | What it's for |
|---|---|---|
| GetRequest | Manager | Read these OIDs |
| GetNextRequest | Manager | Next object—table walks the old way |
| GetBulkRequest | Manager | Fatter walks (v2c/v3) |
| SetRequest | Manager | Write (if the view allows it) |
| Response | Agent | Answer or error |
| Trap / InformRequest | Agent | Async event (inform wants an ack) |
Values aren't "just numbers." You get an SMI type—Integer, Counter32, Gauge32, TimeTicks, OCTET STRING, etc. Counters only go up (until wrap). Gauges can fall. TimeTicks is that weird hundredths clock. Encoding is BER; you almost never touch ASN.1 unless you're writing an agent. Good.
More structure: MIB, OID. Firewall notes: ports.
What you can read this way
Same pattern scales. Interface octets. Memory. Disk. Process table. UPS. Temp sensors if the hardware bothers to expose them. Catalog by metric: sensors/all. "How do I actually monitor X" guides: monitoring.
Before you trust a new class of device in prod, I do this—every time:
- Poller source can hit UDP 161 (and back)
- Community / v3 user is RO and not a default
- One
snmpgetor a short walk proves the OIDs exist on this image - Decide what needs a trap vs a shorter poll interval
No magic. Addressed reads. Typed answers. Timeouts mean unknown.
Frequently asked questions
How does SNMP poll a device?
Manager fires Get / GetNext / GetBulk at UDP 161. Agent resolves OIDs it implements, returns a Response with types and values (or an error). Your NMS stores the sample and waits for the next interval. Nothing streams by default.
What port does SNMP use?
Queries: UDP 161 on the agent. Traps/informs: UDP 162 toward the manager/receiver. Both UDP—so write the firewall rules like you mean it, both directions as needed.
Is SNMP push or pull?
Both. Polling is pull. Traps/informs are push. Capacity graphs lean pull; "link just died" leans push.
What is an SNMP GetRequest?
It's the "give me these OIDs" PDU. One shot, one or more varbinds. Agent answers with Response. snmpget is basically GetRequest with a pretty printer.
Key takeaways
- Manager asks, agent answers from a MIB—or the agent shouts a trap first.
- Poll path: Get* → UDP 161 → Response with typed varbinds. Traps use 162.
- OIDs address data; SMI types tell you how to treat the number.
- Prove the path with
snmpgetonsysUpTime(1.3.6.1.2.1.1.3.0) before you build a template farm. - Next stops: architecture, PDUs, traps vs polling, OID catalog.