By the SNMP Monitoring team · Reviewed July 2026
Picture one sentence: a manager asks an agent on a managed device for values defined in a MIB and addressed by OIDs—usually over UDP 161—or the agent yells traps toward UDP 162.
If that map is fuzzy, you will misplace firewall rules, install "SNMP" on the wrong box, or expect the NMS to invent metrics the agent never implemented. Architecture is not academic wallpaper. It's why half of "SNMP is broken" tickets are actually "we polled the wrong role."
Parent: What is SNMP. Wire flow detail: how it works.
The four building blocks
Four roles. Mix them up and the diagram lies.
| Role | Runs where | Job |
|---|---|---|
| Managed device | Router, switch, server, UPS, printer… | The thing you care about operationally |
| SNMP agent | Software on that device | Listen, answer OIDs, emit traps |
| SNMP manager / NMS | Monitoring host, appliance, or external service | Poll, store, threshold, receive traps |
| MIB | Schema/docs (+ compiled into agent/manager tooling) | Defines what objects exist and their types |
Examples that stick:
- Linux box = managed device;
snmpd= agent; LibreNMS VM = manager; HOST-RESOURCES-MIB = part of the schema story. - Cisco switch = device + embedded agent; your NMS is still the manager.
- UPS with a network card = same pattern, vendor MIB tree.
OIDs are the addresses into that schema. Types follow SMI (SMIv2 is commonly cited via RFC 2578). You don't freestyle a "CPU field"—you implement or poll a defined object.
SNMP Manager (NMS)
The manager is the polling brain. It decides what to ask, how often, and what to do with the answer. It also often runs the trap receiver on UDP 162.
It does not live on the monitored device (unless you're doing something odd like dual-homing roles). Full write-up: SNMP manager / NMS.
Managers range from snmpget on a laptop to full platforms to external services that only ever talk SNMPv2c into your allowlisted agent. Same architectural role: initiator of Gets, consumer of Responses and traps.
SNMP Agent
The agent is software on the managed device. It listens on UDP 161, resolves OIDs against what it implements, returns typed values, and may send traps/informs to configured receivers.
Master agent vs subagent (AgentX)
Big agents aren't always one process owning every leaf. AgentX (RFC 2741) lets a master agent hand MIB subtrees to subagents. Useful when a database or custom app wants to expose OIDs without rewriting snmpd from scratch.
- Deep agent role: SNMP agent
- Delegation: AgentX
If a walk is empty for a subtree you expected, ask: is the master running, is the subagent registered, is the view allowing it? Architecture again—not "SNMP can't do it."
The MIB and OID data model
Split two ideas people mash together:
- MIB = the schema (modules describing objects, types, semantics)
- OID = the address of an instance (or table cell)
SMI (Structure of Management Information) is the type system behind those definitions—SMIv2, RFC 2578 is the reference fact we stick to here. Managers may load MIBs to print pretty names; agents implement the instrumentation. Pretty names on the CLI don't mean the agent has the object.
More: MIB, OID. Catalog of common leaves: sensors/all.
Without a MIB/OID model, "monitor everything" is a slogan. With it, you know exactly which branch to allowlist.
How a request travels through the architecture
Numbered path for a simple Get:
- Operator or scheduler on the manager picks an OID (from a template or MIB knowledge).
- Manager builds a GetRequest and sends UDP to the device agent on port 161.
- Agent checks community/v3 user and VACM view.
- Agent resolves the OID via its implemented MIB instrumentation (maybe via AgentX subagent).
- Agent returns a Response with type + value (or error-status).
- Manager stores the sample, graphs it, compares thresholds.
- Separately, if something fires, agent may send a trap to the manager's UDP 162.
Prove step 2–5 with:
snmpget -v2c -c <RO_string> <host> 1.3.6.1.2.1.1.3.0
DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (15000000) 1 day, 17:40:00.00
That's manager → agent → Response, end to end. Deeper packet story: how it works. Ports: 161 & 162. PDUs: PDU types.
Mistakes this model prevents
- Opening 161 on the NMS instead of the agent
- Expecting traps without a receiver on 162
- Polling OIDs the agent never implemented
- Forgetting subagents when "half the MIB" is missing
- Confusing MIB files on the manager disk with what's running on the device
Architecture is a checklist, not a poster.
Scaling the diagram without lying
One manager, many agents is the textbook picture—and it's true for small shops. Larger estates grow tiers: regional pollers, dedicated trap receivers, external synthetic checks. Those are still managers (or manager components) in architectural terms. They don't become "agents" because they run in the DC.
What does change at scale:
- Credential sprawl — communities/users per zone
- View design — not every poller should see every OID tree
- Trap storms — one power event, thousands of notifications
- Partial MIB support — templates assume HOST-RESOURCES; half the fleet is a switch
AgentX appears when a single device's software is modular—not when you have many devices. Many devices = many agents, one or more managers. Don't rename roles under pressure from a slide deck.
Also separate management plane from user plane. Agents should listen on management addresses. Managers should poll from management networks. When those networks share fate with production traffic, your monitoring dies in the same incident it's supposed to explain. That's architecture meeting cabling reality.
Ports and PDUs still apply unchanged: ports, PDU. Glossary: glossary. Keep the four-box model taped above the NOC desk if you have to—device, agent, manager, MIB.
Frequently asked questions
What are the components of SNMP?
Managed device, agent, manager/NMS, and MIB (with objects addressed by OIDs). Transport is typically UDP; queries 161, traps 162.
What is a managed device?
Any network element you manage via SNMP—server, switch, firewall, UPS, printer—running (or embedding) an agent that exposes MIB objects.
Difference between manager and agent?
Manager initiates polls and usually receives traps; runs off-box relative to the target. Agent runs on the device, answers queries, may send traps. Details: manager, agent.
What is AgentX?
AgentX (RFC 2741) is a protocol for a master agent to delegate MIB subtrees to subagents. See AgentX.