Troubleshooting SNMP misconfigurations: Check if the SNMP service is running on the device. Connect SNMP (v1, v2, v3) protocols between your device and the poller. Make sure that your community string or credentials for v3 are consistent. Check to make sure that the AC LS firewall port 161 is open. Run snmpwalk for testing. Clear up your initial timeout/auth failure.
Symptoms
- The monitoring tool indicates that device is down, while it can be pinged via ICMP.
- snmpwalk: Timeout: No Response from <host> or Authentication failure.
- Screen of interface counters, CPU, or memory graphs lags.
- Traps are not received at the NMS even as the device generates SNMP notify events.
- Some OIDs get a value others get noSuchObject or noSuchInstance.
Common Causes
Version mismatch of agent and poller:
The agent using SNMPv3, the poller using v2c or vice versa. Unrecognized packets are ignored by the agent, so the NMS simply times out because there is no specific protocol problem.
Wrong community string or v3 credentials:
Transposed, case mismatch or swung password prevents authentication. V3 keys bring with them their authProtocol (MD5/SHA) and privProtocol (DES/AES) values which need to align identically.
Agent not listening / limited to wrong interface:
snmpd service is stopped OR agentAddress is only bound to 127.0.0.1. UDP 161 cannot be accessed from the management VLAN even though the process is still running.
Firewall, ACL or view restrictions:
Device is protected from the poller subnet by hostfirewall, upstream ACLs or SNMP view/group configuration. The request was received at the device but dropped before a reply is sent back to the poller.
MIB or OID scope issues:
A requested OID is in a MIB that's not shared by the agent or that view. Incomplete information is seen while other polls are returning noSuchObject.
Step-by-Step Fix
- If the snmpd process is running, but there is no entry listening on UDP port 161
The problem may be with the directive agentAddress (Linux / Windows) or with the snmp-server community (Cisco IOS) - Ensure the same SNMP version is configured on device and monitoring application:
Check your device (cat /etc/snmp/snmpd.conf on Linux or show running-config on Cisco) and ensure that your monitoring application (PRTG, Zabbix, LibreNMS, SolarWinds) is configured for the same version in the credential profile. Please use v3 if possible. - Ensure community strings or SNMPv3 user settings:
For v1/v2c, do a read test: snmpwalk -v2c -c <community> <host> sysDescr.0 For v3: snmpwalk -v3 -l authPriv -u <user> -a SHA -A <authpass> -x AES -X <privpass> <host> sysDescr.0. An auth failure means that the username, protocols or passphrase do not match the one in the device. - Ensure that UDP 161 is open on firewalls and intermediate ACLs from the poller subnet:
Check host firewalls and intermediate ACLs (firewalld, ufw, Windows Defender Firewall) to ensure that UDP 161 is open from the poller subnet. On Cisco, use the show access-list all command to find the access list named by the snmp-server community <string> RO <acl> command, add the IP address of the monitoring server, and reapply. - Check views, groups and access control of SNMP:
Tighter views cover subtrees. On net-snmp, check your snmpd.conf view, group, and access lines and expand the scope of OIDs if the poll doesn't produce any results. On Cisco, check the SNMP-server view and SNMP-server group settings to ensure that the group can read the portion of the MIB that you require. - Check the OID of the problem -
Don't assume responsibility for the NMS (protocol or template): Run snmpget -v2c -c <community> <host> 1.3.6.1.2.1.1.3.0 (sysUpTime). If you get an answer, then all's well with SNMP; check the monitoring template and/or the import of the MIB. If not, get back to debugging with the agent. - Polling is independent of the delivery of SNMP traps:
Outgoing packet format for traps is UDP 162 from the device. Check snmp-server host <nms-ip> version 2c <community> (or v3 equivalent), UDP 162 to NMS and tail snmptrapd.log on receiver. Polling and silent discarding of traps are possible. - Reload the agent and take packets if still failing:
Reload the config, run systemctl reload snmpd, or write memory on IOS. Again, if the poller times out, run the following command on the device: tcpdump -ni <iface> udp port 161. No inbound packets indicates a network-path problem; inbound but no reply indicates ACLs/views/credentials.
The common SNMP error responses and corrective action
| Symptom | Likely cause | Corrective action |
|---|---|---|
| Timeout: No Response from host | Agent down, wrong port, or firewall/ACL block | Check snmpd, check 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 / 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 |
| When the server is unreachable 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 keep passwords in secrets vault not device configs.
- Record subnets used for polling and only permit SNMP access from users that are associated to named ACLs.
- Version-control snmpd.conf and Cisco snmp-server lines so drift is visible.
- Introduce a synthetic snmpget health check into your monitoring to reveal silent breakage.
FAQ
Q: Why does snmpwalk time out while ping is successful?
A: ICMP and SNMP run in opposite directions in the stack. Ping only tests the availability of the IP layer. SNMP also requires that UDP 161 be enabled on host and network firewalls, the snmpd process accept a connection on a routable interface, and the community string match. First of all, try to find out whether the request is received with tcpdump on the destination.
Q: Is it possible to continue using SNMPv2c or should I upgrade to v3?
Wherever possible, use v3. V2c sends the community string in plain text and offers no integrity protection, meaning that the community string and any queries sent inside are subject to any changes or reading along the way. V3 offers user authentication (SHA) and encryption (AES). Only use v2c if you have older equipment that does not support v3, and if that is the case, ensure that it is tightly protected with strict ACLs.
Which MIB Does the Monitoring Tool Need?
A: Check the OIDs it pollinates on the sensor/template docs and check the device returns those OIDs snmpwalk against the subtree. If there are entries in the CLI that are not found in the tool, it means that the MIB file is probably not loaded in the NMS. Import the vendor MIB and reload the poller.