By the SNMP Monitoring team · Reviewed July 2026
When SNMP won't respond, the temptation is to guess — re-type the community, poke the firewall, restart the daemon — and hope one of them lands. That wastes time and often changes the wrong thing. The reliable approach is to isolate the failure by layer, working from the outside in: is the host even reachable, is UDP 161 getting through, is the agent listening, are the credentials right, and is the OID inside the agent's view? Each check rules out a whole class of causes, so by the time you've walked the ladder you know exactly where it breaks — and therefore exactly what to fix. This is the systematic isolation flow; the troubleshooting page covers config-side fixes and common errors decodes specific messages.
Parent: FAQ & reference. Related: troubleshooting, firewall setup, ports.
The diagnostic ladder
Work these in order — each rung assumes the ones below it passed:
| Test | Tool | Expected result |
|---|---|---|
| Host reachable | ping / traceroute | Replies / a route to the host |
| UDP 161 reaches agent | tcpdump on the agent | Request packets arrive |
| Agent listening | ss -lnup / systemctl | snmpd bound to 161, service active |
| Credentials valid | snmpget sysDescr | A value, not authError |
| OID in view | snmpget the target OID | A value, not noSuchObject |
The single most useful distinction on this whole page: a timeout means your request got no reply at all — the problem is network, agent, or ACL, somewhere in the lower rungs. An error reply like noSuchName or authorizationError means the agent did answer — so it's reachable and listening, and the problem is credentials or the OID view, the upper rungs. That one fork tells you which half of the ladder to work.
Step 1: Reachability
Start at the bottom. If you can't reach the host at all, nothing above matters:
ping -c 3 10.0.0.20
64 bytes from 10.0.0.20: icmp_seq=1 ttl=64 time=0.42 ms
64 bytes from 10.0.0.20: icmp_seq=2 ttl=64 time=0.39 ms
Replies mean basic IP connectivity and routing are fine. No replies could mean the host is down, a routing problem, or ICMP being filtered — check the route and whether the host is up by another means before blaming SNMP. Note that some networks block ICMP while permitting UDP 161, so a failed ping isn't conclusive on its own; it's a first signal, not a verdict.
Step 2: Is 161 open?
Reachable host, still no SNMP? Confirm the query packets actually arrive at the agent. Run tcpdump on the agent host and poll from your manager:
tcpdump -i any udp port 161
14:07:22.418 IP 10.0.0.5.51204 > 10.0.0.20.161: UDP, length 43
If you see the inbound request, the network and firewall are letting it through — move up the ladder. If you see nothing when you poll, a firewall or ACL is dropping it before it reaches the agent: check the host firewall, any cloud security group, and upstream ACLs (firewall setup). Seeing the request arrive but no response leave points at the agent or its own ACL, the next rungs.
Step 3: Is the agent listening?
Packets arriving but no answer? Confirm the agent is actually up and bound to the port. On the agent host:
ss -lnup | grep 161
UNCONN 0 0 0.0.0.0:161 0.0.0.0:* users:(("snmpd",pid=812,fd=8))
That line means snmpd is listening on UDP 161 on all interfaces. If it's missing, the daemon isn't running or is bound only to localhost — check systemctl status snmpd and the agentAddress in snmpd.conf. A common gotcha: an agent configured to listen only on 127.0.0.1 answers local queries but ignores everything from the network, which looks exactly like a firewall drop from the manager's side.
Step 4: Credentials
Agent listening but you get an authentication error (or a v3 handshake failure)? Now it's credentials. Test with a known-simple query:
snmpget -v2c -c S3cr3tR0str1ng 10.0.0.20 sysDescr.0
An authorizationError or timeout-after-listening on v2c usually means a wrong community string or a source-IP ACL rejecting your manager. On v3 it's a mismatched username, auth/privacy protocol, or key. Verify the community against community-string setup, or the USM parameters against SNMPv3 setup. Remember the earlier fork: if this returns an error, the agent is answering, so don't go back down to firewalls — stay up here in credentials and view.
Step 5: Is the OID in view?
Credentials good, sysDescr works, but your specific OID returns noSuchObject? The OID is outside the agent's VACM view — the allowlist that restricts which subtrees the credential can read. The agent is deliberately hiding it, not failing. Widen the view to include the subtree you need, or point at an OID you know is in scope, following OID allowlist. This is easy to misread as "the OID doesn't exist," but on a correctly restricted agent it usually means "you're not allowed to see this one" — a configuration choice, not a fault.
Decision summary
Map the symptom to the next move:
- No ping, no SNMP → network/routing or host down (Step 1).
- Ping OK, timeout, no packet in tcpdump → firewall/ACL dropping it (Step 2).
- Packet arrives, no reply → agent not listening or bound to localhost (Step 3).
- Reply is an auth error → wrong community/v3 credentials or source ACL (Step 4).
- sysDescr works, target OID is noSuchObject → OID outside the VACM view (Step 5).
Follow the numbers and you convert "SNMP is broken" into one specific, fixable cause.
Frequently asked questions
Why is SNMP not responding?
Isolate the failure by layer instead of guessing. Check, in order: is the host reachable (ping), is UDP 161 arriving at the agent (tcpdump on the host), is the agent listening (ss/netstat), are the credentials valid (snmpget sysDescr), and is your OID inside the agent's view. A timeout points to the lower layers (network, firewall, agent); an error reply points to the upper layers (credentials, view).
How do I check if the SNMP agent is listening?
On the agent host, run ss -lnup | grep 161 (or netstat -lnup). You should see snmpd bound to UDP 161 — ideally on 0.0.0.0 (all interfaces), not just 127.0.0.1. If nothing shows, the daemon isn't running (systemctl status snmpd) or is misconfigured. An agent bound only to localhost answers local queries but ignores network requests, which mimics a firewall drop.
How do I confirm SNMP packets are actually arriving?
Run tcpdump -i any udp port 161 on the agent host while polling from your manager. If you see the inbound UDP request, the network and firewall are passing it and the problem is at the agent or its ACL. If you see nothing, something between the manager and host — a host firewall, cloud security group, or upstream ACL — is dropping the packet before it arrives.
What's the difference between a timeout and an error reply?
A timeout means your request got no answer at all, so the problem is somewhere it couldn't even reach the agent: network, firewall/ACL, or the agent not listening. An error reply — noSuchName, noSuchObject, authorizationError — means the agent received the request and responded, so it's reachable and listening, and the issue is credentials or the OID view. That fork tells you which half of the ladder to investigate.
Key takeaways
- Isolate by layer, outside in: reachable → UDP 161 arriving → agent listening → credentials → OID in view.
- The key fork: a timeout = no reply (lower layers); an error reply = the agent answered (upper layers).
- Confirm packets with
tcpdump -i any udp port 161; confirm listening withss -lnup | grep 161. - An agent bound to localhost only looks exactly like a firewall drop from the manager.
noSuchObjecton a working agent usually means the OID is outside the VACM view, not that it's missing.- For message lookups see common errors; for config-side fixes see troubleshooting.