Manager/Agent Architecture

## The two traditional roles SNMP (the Simple Network Management Protocol) splits network management between two kinds of participant: - The **agent** lives on each **managed device** - a switch, router, server or printer. It has access to the device's **management instrumentation**: interface states, counters, configuration values. It answers questions about them and reports events. - The **manager** (also called a **management station**) is the system the operator runs. It asks agents for values, occasionally changes one with a `SetRequest`, and collects the events agents report. The values themselves are **managed objects**, named by OBJECT IDENTIFIERs and defined in MIB modules. The agent never hands out everything it knows: each request is answered from a **MIB view**, the subset of objects that this particular request may see. ## What RFC 3411 actually defines The SNMPv3 architecture (RFC 3411, part of Internet Standard 62) stops talking about "managers" and "agents" as boxes. It defines an **SNMP entity** as an SNMP engine plus one or more **applications**, and names five application types: | Application | What it does | Traditionally part of | |---|---|---| | `command generator` | monitors and manipulates management data by sending requests | manager | | `command responder` | provides access to management data by answering requests | agent | | `notification originator` | initiates asynchronous messages | agent | | `notification receiver` | processes asynchronous messages | manager | | `proxy forwarder` | forwards messages between entities | proxy agent | In RFC 3411's words, an entity with command generator and/or notification receiver applications "has traditionally been called an SNMP manager", and one with command responder and/or notification originator applications "an SNMP agent". The decomposition matters because real systems mix them. ## Ports, and which way the traffic flows The preferred transport mapping is **SNMP over UDP** (RFC 3417 §3), one message per datagram. Two well-known ports appear: 1. **Requests**: the manager sends `GetRequest`, `GetNextRequest`, `GetBulkRequest` or `SetRequest` from an ephemeral source port to the agent's **UDP 161**. 2. **Responses**: the agent's `Response` returns to that ephemeral port. RFC 1157 §4.1 states the rule for SNMPv1: the response is sent *from* the transport address the request was sent *to* - so it leaves from 161. 3. **Notifications**: when something happens - an interface about to go down, a restart - the agent's notification originator sends a trap or inform to the manager's **UDP 162**. RFC 3417 §3.2 words both as suggestions: it is "suggested" that command responders listen on 161 and notification receivers on 162. They are well-known defaults, not protocol constants; an operator may move either, at the price of reconfiguring every manager or every agent's notification target to match. Other transport mappings use other ports: SNMP over TLS and DTLS (RFC 6353) registers **10161** for requests and **10162** for notifications. RFC 3417 also sets a floor on message size: an entity using the UDP mapping must accept messages up to **484 octets**, and RFC 3417 recommends accepting up to 1472. ## Entities that are both Because roles are applications, one entity can hold several: - A **mid-level manager** (RFC 3411's "dual-role entity") runs command generator and notification receiver applications toward the devices below it, and command responder and notification originator applications toward a manager above it - useful for summarising a region before a central station sees it. - A **proxy forwarder** relays requests and notifications to another engine by context, without interpreting the objects inside them (RFC 3413 §1.5); it is how a modern manager can reach a device speaking an older SNMP version. - An **extensible agent** (AgentX, RFC 2741) splits one agent into a master agent and subagents internally, while still looking like one agent to the manager. ## Mistakes worth avoiding - Swapping the ports: 161 is where the *agent* listens; 162 is where the *manager* listens. - Thinking the agent only answers. The notification originator lets it speak first, which is exactly how a manager hears about an event between polls. - Assuming one box is one role. A monitoring server that forwards events upward, or a gateway translating versions, holds both kinds of application. - Opening only 161 on a firewall between the two and then wondering why no notifications arrive.