To fix SNMP misconfiguration, confirm the SNMP agent is running, match the SNMP version (v1, v2c, or v3) between device and poller, verify the community string or v3 credentials, allow UDP 161 through firewalls and ACLs, and test with snmpwalk. Correct the first mismatch that returns a timeout or authentication error.
Symptoms
- Monitoring tool shows the device as unreachable while ICMP ping succeeds.
- snmpwalk returns Timeout: No Response from <host> or Authentication failure.
- Interface counters, CPU, or memory graphs stop updating or show flat lines.
- Traps never arrive at the NMS even though the device logs SNMP notify events.
- Some OIDs return values, others return noSuchObject or noSuchInstance.
Common Causes
Version mismatch between agent and poller
The device runs SNMPv3 while the monitoring tool polls with v2c, or vice versa. The agent silently drops packets it cannot decode, so the NMS reports a timeout rather than a clear protocol error.
Wrong community string or v3 credentials
A typo, case difference, or rotated password stops authentication. SNMPv3 adds authProtocol (MD5/SHA) and privProtocol (DES/AES) values that must match exactly on both sides.
Agent not listening or bound to wrong interface
The snmpd service is stopped, or agentAddress is bound only to 127.0.0.1. UDP 161 is then unreachable from the management VLAN even though the process is technically running.
Firewall, ACL, or view restrictions
Host firewalls, upstream ACLs, or SNMP view/group definitions block the poller subnet. Requests reach the device but are dropped before the agent can respond.
OID or MIB scope problems
The requested OID lives in a MIB the agent does not expose, or the view excludes that subtree. Partial data appears while other polls fail with noSuchObject.
Step-by-Step Fix
- Confirm the SNMP agent is running and listening on UDP 161
On Linux, run systemctl status snmpd and ss -ulnp | grep 161. On Windows, check the SNMP Service in services.msc. On Cisco IOS, use show snmp and show snmp host. If the process is up but nothing is bound to 161, review the agentAddress directive or the snmp-server community configuration. - Match SNMP version between device and monitoring tool
Identify the version configured on the device (grep -E 'v1|v2c|v3' /etc/snmp/snmpd.conf on Linux, show running-config | include snmp-server on Cisco). Then open the credential profile in PRTG, Zabbix, LibreNMS, or SolarWinds and set the same version. Prefer v3 wherever the hardware supports it. - Verify community strings or SNMPv3 user parameters
For v1/v2c, test read access with snmpwalk -v2c -c <community> <host> sysDescr.0. For v3, run snmpwalk -v3 -l authPriv -u <user> -a SHA -A <authpass> -x AES -X <privpass> <host> sysDescr.0. Any authentication error means the username, protocols, or passphrases differ from the device. - Open UDP 161 through firewalls and device ACLs
Check host firewalls (firewalld, ufw, Windows Defender Firewall) and any intermediate ACLs for UDP 161 from the poller subnet. On Cisco, inspect the access-list referenced by snmp-server community <string> RO <acl>. Add the monitoring server's IP and reapply. - Review SNMP views, groups, and access rules
Restrictive views hide subtrees. On net-snmp, examine view, group, and access lines in snmpd.conf; broaden the included OID range if a poll returns nothing. On Cisco, check snmp-server view and snmp-server group entries so the group has read access to the required MIB tree. - Test the specific OID with snmpget before blaming the NMS
Isolate whether the fault is protocol or template. Run snmpget -v2c -c <community> <host> 1.3.6.1.2.1.1.3.0 for sysUpTime. If it returns a value, SNMP is healthy and the monitoring template or MIB import is the real problem. If it fails, keep debugging at the agent. - Fix SNMP trap delivery separately from polling
Traps use UDP 162 outbound from the device. Confirm snmp-server host <nms-ip> version 2c <community> or the v3 equivalent, allow UDP 162 to the NMS, and tail snmptrapd.log on the receiver. Polling can work perfectly while traps are silently discarded. - Restart the agent and capture packets if issues persist
Reload the config (systemctl reload snmpd or write memory on IOS). If the poller still times out, run tcpdump -ni <iface> udp port 161 on the device. No inbound packet means a network path issue; inbound with no reply points at ACLs, views, or credentials.
Common SNMP error responses and the corrective action
| Symptom | Likely cause | Corrective action |
|---|---|---|
| Timeout: No Response from host | Agent down, wrong port, or firewall block | Start snmpd, verify UDP 161, open firewall/ACL |
| Authentication failure | Community string or v3 credentials mismatch | Re-enter credentials; confirm authProtocol and privProtocol |
| noSuchObject / noSuchInstance | OID outside configured view or unsupported MIB | Extend view, load correct MIB, or query a supported OID |
| Partial data, some OIDs empty | Restrictive group or access rule | Adjust snmp-server group or net-snmp access line |
| Polling works, traps missing | Trap host, community, or UDP 162 not configured | Set snmp-server host, open UDP 162 to the NMS |
| Unreachable only from NMS subnet | ACL bound to snmp-server community | Add NMS IP to the referenced access-list |
Prevention
- Standardise on SNMPv3 with SHA/AES and store credentials in a secrets vault, not device configs.
- Document polling subnets and lock SNMP access to those with named ACLs.
- Version-control snmpd.conf and Cisco snmp-server lines so drift is visible.
- Add a synthetic snmpget health check to your monitoring to catch silent breakage.
FAQ
Why does snmpwalk time out even though ping works?
ICMP and SNMP take different paths through the stack. Ping only proves the IP layer is reachable. SNMP additionally needs UDP 161 open on host and network firewalls, the snmpd process listening on a routable interface, and matching credentials. Start with tcpdump on the target to see whether the request arrives at all.
Should I still use SNMPv2c or move everything to v3?
Use v3 wherever the device supports it. v2c sends the community string in plain text and offers no integrity protection, so anyone on the path can read or spoof queries. v3 adds user authentication (SHA) and encryption (AES). Keep v2c only for legacy hardware that cannot run v3, and restrict it with tight ACLs.
How do I know which MIB a monitoring tool needs?
Check the sensor or template documentation for the OIDs it polls, then confirm the device exposes those OIDs with snmpwalk against the relevant subtree. If values appear on the CLI but not in the tool, the MIB file is probably missing from the NMS. Import the vendor MIB and reload the poller.
Need help auditing SNMP across a mixed vendor estate? Contact our network team for a configuration review.