What Is an SNMP Agent? Role, snmpd & How It Works

By the SNMP Monitoring team · Reviewed July 2026

The SNMP agent is the software that lives on the managed device and does the answering. Manager asks; agent replies—or the agent shouts a trap when something breaks. If you install monitoring tools only on the NMS and never enable an agent on the target, you don't have SNMP monitoring. You have hope.

Contrast: the manager/NMS runs off-box and initiates polls. Architecture map: SNMP architecture.

Definition: the SNMP agent

Agent = process or embedded stack that:

• Implements some set of MIB objects
• Listens for SNMP messages (typically UDP 161)
• Enforces communities or SNMPv3 users / views
• Returns typed values for Gets
• Optionally sends traps/informs to receivers on UDP 162

On a Linux server that often means net-snmp snmpd. On a switch it's firmware. On a UPS it might be a management card. Same role, different packaging.

The agent is not the NMS database. It doesn't store your year of graphs. It exposes current (or near-current) instrumentation.

What the agent does

Numbered list of the job:

1. Binds and listens — usually UDP 161 (or a custom port you configured).
2. Authenticates — community (v1/v2c) or USM user (v3).
3. Authorizes — VACM views / allowlists: which OIDs this principal may see.
4. Resolves OIDs — maps request to local instrumentation (kernel stats, IF-MIB, vendor code, subagent).
5. Replies — Response PDU with values or error-status.
6. Notifies — may emit traps/informs toward configured managers.

If any step fails, the manager sees timeouts, empty walks, or auth errors. "Agent is up" means more than ps aux | grep snmpd—it means the right address, port, credentials, and MIB support.

Quick proof from a manager host:

snmpget -v2c -c <RO_string> <host> 1.3.6.1.2.1.1.1.0

SNMPv2-MIB::sysDescr.0 = STRING: Linux web-03 6.1.0-generic #1 SMP PREEMPT_DYNAMIC ...

No response? Agent down, filtered, wrong community, or wrong IP. Don't start rewriting dashboards yet.

snmpd: the common Linux agent

On Linux, net-snmp ships snmpd, configured mainly through snmpd.conf: communities or v3 users, views, listen addresses, trap destinations, extend directives, and more.

Typical ops loop:

• Install package → enable service → edit snmpd.conf → restart → test with snmpget from the poller IP
• Lock down: non-default RO community or v3, source restrictions, OID views

Config deep-dive: snmpd.conf. Distro notes: Ubuntu/Debian, also CentOS/RHEL when you get there.

Minimal smell-test after install (on the box, then from remote):

snmpwalk -v2c -c <RO_string> <host> system

SNMPv2-MIB::sysDescr.0 = STRING: Linux web-03 6.1.0-generic ...
SNMPv2-MIB::sysUpTime.0 = Timeticks: (120000) 0:20:00.00

If localhost works and remote doesn't, it's network/ACL—not "snmpd broken."

Agent vs manager

Sibling page: manager.

Extending the agent

Stock MIBs aren't always enough. Ways to grow what the agent exposes:

• AgentX subagents — master snmpd delegates subtrees (RFC 2741). See AgentX.
• net-snmp extend / pass — run a script or pass handler to serve custom values.
• Vendor modules — loadable bits for hardware sensors, etc.

Custom OID patterns: custom OID. Keep security in mind: every extend is another way to leak data or execute something dumb if misconfigured.

When a subtree is "sometimes there," check subagent registration before blaming the NMS template.

Enabling an agent

High-level checklist:

1. Install/enable the agent package or feature (OS or device UI).
2. Configure credentials (RO community or v3 user)—never leave public on a real network.
3. Restrict sources and views.
4. Open UDP 161 from pollers only.
5. Test with snmpget/snmpwalk from the real poller.
6. Point trap destinations if you use traps.

OS-focused guides: Ubuntu/Debian setup, Windows Server. Community hardening: community string. Full setup hub: setup.

Embedded agents on network gear follow the same ideas with different clickpaths—still: credential, ACL, test walk.

Terms: glossary.

Failure modes I actually see

• Agent running, view empty — credentials work, every interesting OID is not-in-view.
• Listening on 127.0.0.1 only — great for local tests, useless for the NMS.
• Trap destination wrong — polls fine, "we never get traps."
• Subagent died — half the enterprise tree vanishes after deploy.
• SELinux/AppArmor surprise — process up, scripts in extend blocked.

Architecture troubleshooting is process + config + path. Not vibes.

What "healthy agent" means in ops language

A green service status is necessary and insufficient. I call an agent healthy when:

1. It listens on the intended address/port (not only localhost).
2. The intended poller IPs are allowed.
3. Credentials work for a known-good scalar (sysUpTime / sysDescr).
4. The OIDs you bill monitoring on actually return data—not just system.
5. Trap targets (if any) are reachable and tested.
6. Resource use is boring—snmpd shouldn't peg a core walking huge tables every minute because the NMS is rude.

Write those six into the runbook. Junior on-call stops guessing.

Embedded agents add vendor UI quirks (SNMP "on," but only v2c, but only certain VRFs). Same checklist. Different clicks. The architecture role never changes: software on the device that speaks SNMP to managers.

Related security: don't run RW communities; prefer v3 where you can—versions, community string.

Windows and appliance agents follow the same six health checks even when the binary isn't called snmpd. Name differs. Role doesn't. If a vendor "enables SNMP" with a default community and wide open views, treat that as day-zero hardening work, not a finished install. Change it before the first production poll hits the box. Walk system, then walk what you actually graph, then lock the rest down.

Frequently asked questions

What is snmpd?

snmpd is the common net-snmp SNMP agent daemon on Linux/Unix. It listens for queries and is configured via snmpd.conf.

Where does the SNMP agent run?

On the managed device—the server, switch, or appliance you are monitoring—not on the NMS (that's the manager).

What port does the agent use?

Typically UDP 161 for queries. Traps/informs are sent to the manager on UDP 162.

How do I enable the SNMP agent?

Install/enable the agent, configure RO credentials and views, allow pollers to UDP 161, then verify with snmpget. See setup and OS guides linked above.

Key takeaways

• Agent = on-device software; answers on 161, may trap to 162.
• Linux default story: net-snmp snmpd + snmpd.conf.
• Extend via AgentX, extend/pass, vendor modules.
• Manager is the other half—manager page.
• Enable → lock down → test from the real poller.