skip to content

In SNMP's AgentX protocol, what do the master agent and its subagents each do, and why does the manager never see the split?

level: middleimportance: nice to knowfreq 7%

answer

  1. one agent, many processes
  2. who speaks SNMP, who knows the data
  3. registering MIB regions
  4. a local session, not SNMP
  5. what RFC 2741 calls fundamental

basics

~20 s

An AgentX master agent speaks SNMP on the agent's address and enforces access control and MIB views; subagents register MIB regions with it and hold the actual instrumentation. RFC 2741 makes the split invisible: managers see one ordinary agent.

solid answer

~50 s

AgentX (RFC 2741, Standards Track) lets several processes on one device serve a single SNMP agent. The **master agent** sends and receives SNMP messages on the agent's transport addresses, runs the administrative framework - security, access control, MIB views - and dispatches each request to whichever subagent registered that part of the tree. **Subagents** open an AgentX session with the master (TCP port 705, or a local UNIX-domain socket), register **MIB regions**, instantiate the objects and perform the actual reads and writes; they also originate notifications, which the master forwards. RFC 2741 sums it up: the master is "MIB ignorant and SNMP omniscient", a subagent "SNMP ignorant and MIB omniscient". The split is invisible by requirement: an extensible agent must behave exactly like a monolithic one, which is what the RFC says differentiates AgentX subagents from SNMP proxy agents.

go deeper

for a junior

Recall that one device's agent can be several processes: a master agent that speaks SNMP and subagents that hold the data, all looking like one agent.

for a middle

Explain the lifecycle - open, register MIB regions, dispatch, notify, close - and who applies MIB views, citing RFC 2741's master and subagent split.

for a senior

Diagnose a vanished subtree as a subagent failure: genErr on timeouts, the forced close after three consecutive timeouts, and objects that then look unimplemented.

for a principal

Weigh extensible agents against monolithic ones for a platform: independent component releases versus a local protocol, timeouts and a master that is a single point of failure.

## Why split an agent at all A single **SNMP agent** answers for every managed object on a device. On a modern switch or server those objects come from many places: the interface driver, a routing process, a power-supply controller, an application. Compiling all of that into one monolithic agent couples every component's release to the agent's. **AgentX** (the Agent Extensibility Protocol, RFC 2741, Standards Track) solves this by splitting the agent into one **master agent** and any number of **subagents** that talk to it over a dedicated protocol. RFC 2741 is explicit that "AgentX is not SNMP": its messages, such as `agentx-Open-PDU` and `agentx-Register-PDU`, only resemble SNMP's. ## The two roles | | Master agent | Subagent | |---|---|---| | Speaks SNMP to managers | yes, on the agent's transport addresses | no - shielded from SNMP messages | | Access control and MIB views | applies them for the whole node | none | | Knows the managed objects | little or nothing directly | instantiates the objects in its regions | | Performs Get and Set work | dispatches it | carries it out | | Notifications | forwards them on the subagent's behalf | initiates them | The master is not entirely without objects of its own: RFC 2741 §4.1 has it provide the instrumentation for the SNMPv2 MIB objects (RFC 1907 when AgentX was written, since obsoleted by RFC 3418) and for the objects of any administrative framework it supports - the parts of the agent that describe the agent itself. RFC 2741 §4.3 compresses this into one line: the master agent is "MIB ignorant and SNMP omniscient", the subagent "SNMP ignorant and MIB omniscient" for the variables it instantiates. ## A session's lifecycle 1. **Open.** The subagent connects to the master - over TCP to the well-known **port 705** (RFC 2741 §8.1.1) or through a well-known UNIX-domain socket (§8.2.1) - and sends `agentx-Open-PDU`. 2. **Register.** It sends `agentx-Register-PDU` for each **MIB region** it serves: a subtree, optionally a range, optionally in a non-default context. The master builds a registry mapping regions to sessions. 3. **Dispatch.** A manager's request arrives at the master on the agent's SNMP address (UDP 161 by convention). The master authenticates it, applies the MIB view, splits the varbinds by region and sends AgentX requests to the subagents that own them. 4. **Respond.** Subagents answer; the master assembles one SNMP response and returns it. 5. **Notify.** A subagent that detects an event sends it to the master, which sends the SNMP notification to the configured managers. 6. **Close.** When the session ends, every region it registered is unregistered (§7.1.8). ## What the manager sees Nothing of the above. RFC 2741 §4 states that the internal operations of AgentX are invisible to a manager, that an extensible agent behaves exactly as a non-extensible one with the same instrumentation would, and that this transparency "is a fundamental requirement". The manager uses one address, one set of credentials and one view; it cannot tell which process answered. Concretely: - **One address.** Only the master sends and receives SNMP messages on the agent's transport address; subagents never see SNMP traffic. - **One security configuration.** Communities, SNMPv3 users and views are set up once, on the master, and cover every subagent's objects. - **One tree.** A walk crosses subagent boundaries without the manager noticing, because the master stitches each region's answers into a single lexicographic order. ## When a subagent fails Transparency also hides failures, so it helps to know the rules: - A dispatch that gets no answer within the timeout is treated as if the subagent had returned `genErr` (§7.2.5.1), so the manager's request can fail with `genErr`. - A session that times out on **three consecutive** AgentX requests must be closed by the master, and closing unregisters all of its regions. - After that, the subagent's objects are simply no longer accessible: a `GetRequest` gets an exception value instead of data and a walk skips the subtree, exactly as if the module were not implemented. So "the agent stopped returning the routing table" is often a subagent problem, invisible from the manager except through these symptoms. ## AgentX is not a proxy Both put something between the manager and the instrumentation, but they differ: - A **proxy forwarder** (RFC 3413) is a separate SNMP entity that forwards whole SNMP messages to another SNMP engine by context, and is visible as an intermediary. - An **AgentX master agent** is the agent: it terminates SNMP itself and talks a different, local protocol to its subagents. RFC 2741 names exactly this transparency as what differentiates AgentX subagents from SNMP proxy agents.

  • What does an SNMP manager observe when an AgentX subagent stops responding?
    Each timed-out dispatch is treated as `genErr` (RFC 2741 §7.2.5.1), so requests touching that region can fail with `genErr`. After three consecutive timeouts the master must close the session, unregistering its regions; from then on those objects are no longer accessible, so Gets return exception values and walks skip them, as if the module were absent.
  • Why does an AgentX subagent not need its own SNMP credentials or view configuration?
    The master agent implements the agent role's elements of procedure, including MIB views and the node's access control policy (RFC 2741 §4.1). A subagent only sees AgentX requests the master has already authorised, so security is configured once, on the master.

An AgentX master agent is like an office switchboard: callers dial one published number and the receptionist routes each call to the department that registered that extension. Callers never learn the extensions, and when a department stops picking up, the receptionist eventually strikes its extension from the list.

saying these in an interview costs you the question

  • Each AgentX subagent listens on its own UDP port for managers.
  • A manager must address subagents individually to reach their objects.
  • AgentX subagents enforce their own access control and MIB views.
  • AgentX is just SNMP spoken between local processes.
  • An AgentX subagent is the same thing as an SNMP proxy agent.