MIB Viewer

SNMP Agent

An SNMP agent is the software component running on a managed device that actually answers SNMP requests. When a router, switch, server, or printer supports SNMP, it's this agent process doing the work - listening on UDP port 161, receiving requests, looking up the requested value, and sending a response.

On network hardware, the agent is usually built into the device's own operating system (IOS, JunOS, and so on) and can't be separated from it. On general-purpose servers, it's typically a separate installable service - net-snmp's snmpd is the most common implementation on Linux, and Windows has its own built-in SNMP service.

What an agent actually does

At a basic level, an agent maintains (or can compute on demand) values for every OID it supports, as defined by whichever MIBs it implements. When a request comes in:

  • For a GET, it looks up the exact OID requested and returns its current value.
  • For GETNEXT/GETBULK, it returns the next OID(s) in its own tree, in order - this is what makes walking an entire subtree possible without knowing every OID in advance.
  • For a SET, it validates the requested change and, if allowed, applies it - not every object is writable, and the agent is responsible for enforcing that.

Agents can also be configured to send traps or informs on their own initiative - a link going down, a threshold being crossed - without waiting for a manager to ask.

Access control

An agent doesn't just answer any request from anyone. In SNMPv1/v2c, access is controlled by community strings - a shared string that has to match, along with a permission level (read-only or read-write) tied to it. In SNMPv3, access control is considerably more granular: individual users, authentication, encryption, and view-based access control restricting exactly which parts of the OID tree a given user can see or modify. See SNMP versions for the full comparison.

Configuring what an agent exposes

Most agents are configurable in terms of which MIBs are active, which community strings or users are valid, and which OID subtrees are accessible to whom. On net-snmp, for example, this all lives in /etc/snmp/snmpd.conf - defining community strings, access levels, and often overriding specific values like sysLocation or sysContact.

Agent vs. manager

It's easy to mix these terms up early on: the agent is on the device being monitored and answers questions; the manager is the monitoring system asking them. A single device is almost always just an agent. A dedicated monitoring platform is almost always just a manager. Some tools genuinely act as both (a monitoring system that also receives and forwards traps from other systems), but that's the exception, not the rule.