SNMP Architecture
What is Architecture — definition
SNMP architecture is the client–server design that the Simple Network Management Protocol is built on: a small number of SNMP components — managers, agents, managed devices, and the shared MIB data model — arranged so that one system can read health data from many others. Put plainly, the SNMP manager agent relationship is the whole show. A manager asks; an agent answers; the managed device is whatever the agent runs on. Everything else is plumbing around that exchange.
What makes the architecture durable is that it's asymmetric and loosely coupled. The agent doesn't need to know how many managers exist or what they'll do with the data. The manager doesn't need code specific to each device — it just needs the OID it wants and permission to read it. That separation is why one monitoring server can poll a fleet of wildly different hardware with the same handful of commands. This page maps the pieces and how they talk; for the protocol's history and definition, see what is SNMP.
There's a nice consequence of that loose coupling worth stating up front. Because the agent is stateless from the manager's point of view — it holds no session, remembers no caller — you can point as many managers at it as you like, and none of them interferes with the others. Your in-house monitoring server, a colleague's ad-hoc snmpwalk, and an independent external checker can all poll the same agent at the same time. The agent just answers each request on its merits. That property is what makes redundant, layered monitoring practical instead of a coordination nightmare.
How it works
The managed-device model has three tiers, and traffic flows between the top two. At the bottom sits the managed device — a server, switch, router, UPS, printer. Running on it is the agent, a daemon (on Linux, typically snmpd) that holds a local view of the device's manageable objects and answers requests about them. Somewhere on the network is the manager, the network management station that initiates polls and collects results.
A normal exchange is short, and it runs in a fixed order:
- The manager sends a request PDU naming an OID to the agent's UDP port 161.
- The agent resolves that OID against its MIB view and checks access rules.
- The agent reads the current value from the underlying system.
- The agent returns a response PDU carrying that value.
Done. Repeat on whatever cadence you've set. Because it's pull-based, the manager owns the timing entirely — poll uptime once a minute and interface counters every ten seconds if you like.
There's a second, opposite path. An agent can be configured to send a trap — an unsolicited notification — to a manager on UDP 162 when something noteworthy happens, so you're not waiting for the next poll to hear about a crossed threshold. Most server monitoring leans on polling because it's predictable and stateless; traps shine for rare, urgent events. The trade-off gets a full treatment in traps vs polling.
Where does the agent get its numbers, though? It doesn't store them — it reads them live from the operating system or hardware at the moment of the request. Ask for hrProcessorLoad and the agent queries the kernel's own accounting; ask for storage used and it checks the filesystem. The agent is really a thin, standardized translator sitting between your OID request and the platform's native counters. That's why the same MIB object returns a Linux figure on one box and a switch's ASIC figure on another: the object is defined once, but each agent maps it to whatever its host actually measures. One architectural constraint to keep in mind: the agent answers based on its configured access rules, so an OID that isn't in the agent's view simply won't be returned, no matter how correct your request is.
Key components / concepts
Four roles, one model. Here's how they line up:
| Component | What it does | Typical example |
|---|---|---|
| Managed device | Hosts the data being monitored | Linux server, switch, printer |
| SNMP agent | Answers queries, may emit traps | snmpd daemon |
| SNMP manager | Polls agents, stores and alerts | Monitoring station / external checker |
| MIB | Defines which objects exist and their OIDs | Host Resources MIB (RFC 2790) |
The agent is the linchpin. It exposes a tree of objects — CPU, memory, interfaces — each addressable by OID, and it enforces who may read what. The manager is the active party; nothing happens until it polls. The MIB is the contract both sides share: without an agreed definition of, say, 1.3.6.1.2.1.25.3.3.1.2 meaning processor load, the number would be meaningless. That addressing scheme — the OID tree and the MIBs that define it — is its own topic, covered in MIB and OID explained. And the credential that lets a manager through the agent's door, in v1 and v2c, is the community string.
Practical example
Let's make the manager–agent exchange concrete. Acting as the manager, you query the agent on a device for its list of running processes' status — an object in the Host Resources MIB:
snmpwalk -v2c -c public 10.0.0.5 1.3.6.1.2.1.25.4.2.1.7
HOST-RESOURCES-MIB::hrSWRunStatus.1 = INTEGER: running(1)
HOST-RESOURCES-MIB::hrSWRunStatus.2 = INTEGER: running(1)
HOST-RESOURCES-MIB::hrSWRunStatus.412 = INTEGER: runnable(2)
Each line is the agent reporting one row from its process table back to you, the manager. Notice you never logged into the box or ran ps — the agent did the local work and handed you the result. Now confirm which SNMP components are even reachable by asking the agent to identify itself with a system-level OID:
snmpget -v2c -c public 10.0.0.5 1.3.6.1.2.1.25.1.1.0
HOST-RESOURCES-MIB::hrSystemUptime.0 = Timeticks: (12345678) 1 day, 10:17:36.78
That round trip — request out, value back — is the atom the entire architecture is built from. Scale it to thousands of devices and you have a monitoring system.
Common pitfalls / notes
- The manager is the only active side. If you're not getting data, check the poller and its schedule before you blame the agent — a healthy agent stays quiet until asked.
- View scope beats reachability. A device can be pingable and its agent running, yet a walk returns nothing because the OID isn't in the agent's configured view.
- Traps need a listener. Configuring an agent to send traps to UDP 162 does nothing if no manager is listening there. Polling has no such dependency.
- One agent, many managers. Multiple managers can poll the same agent independently — which is exactly what makes external monitoring possible.
- v2c is fine for read-only polling. ostr.io's SNMP health monitoring runs on SNMPv2c with a random community string as the password; move to v3 when traffic crosses untrusted networks.
