Introduction
SNMP is an application-layer protocol that provides a message format for communication between SNMP managers and agents. A security model is an authentication strategy that is set up for a user and the group in which the user resides. A security level is the permitted level of security within a security model. A key feature of SNMP is the ability to generate notifications from an SNMP agent. These notifications do not require that requests be sent from the SNMP manager. Notifications can indicate improper user authentication, restarts, the closing of a connection, loss of connection to a neighbor router, or other significant events.
This document identifies common reasons for SNMP traps not being sent or received. The document also suggests recommended practice for SNMP configuration.
Core Issue
The Network Management System (NMS) is not receiving SNMP traps from a device.
Resolution
Following are among the likely causes:
- The device does not send any traps to the destination.
The traps that are supported on a device depend on the platform, software release and feature set. Make sure that the trap that you are looking for has been enabled. The options for the snmp-server enable traps <trap> command do not match the MIB names, so you need to determine what option to look for in the Cisco IOS Software documentation.
For example, to verify if the device is configured to send tcpConnectionClose traps, you need to check if the tty traps have been enabled, as shown:
#sh run
snmp-server enable traps tty
- Something blocks or drops the traps between the device and the NMS.
Investigate if the device is sending any traps, as shown:
# access-list 100 permit udp any host <IP address NMS> eq snmptrap
# debug ip packet 100
This is an example of how to generate a trap:
#conf t
Enter configuration commands, one per line. End with CNTL/Z.
#^Z
Look for messages...
# u all
Investigate if the trap receiver sees these traps using a sniffer trace, as shown:
# snoop <device> port 162
- The NMS server receives the trap, but does not listen to the trap port.
Only one process can listen to the UDP 162 port. Make sure that no other application listens to the trap port instead. To check if your trap receiver is listening to UDP 162, shut down the trap listener. Make sure that no other process is listening to udp162, as shown:
# netstat -a
UDP
Local Address Remote Address State
-------------------- -------------------- -------
*.* Unbound
Start the trap listener. Check if the trap listener has opened the trap port, as shown:
# netstat -a
UDP
Local Address Remote Address State
-------------------- -------------------- -------
*.* Unbound
*.162 Idle
- The NMS server receives the trap, but does not listen to the correct community string.
Your NMS displays traps only if the device uses the correct trap community string in its traps. Some trap listeners require the trap community to be the same as the read-only community string. Others are hard coded to only listen to public, as shown:
#sh run
snmp-server host <IP address NMS> <trap community string>
Recommendation
It is recommended that SNMP Community strings should use access-lists to control SNMP access. This is especially critical if RW string is configured. Create access-lists which contain the addresses or address ranges of servers and workstations which require access to SNMP and configure these access lists onto the community strings. At minimum configure the address range of the internal network to prevent outside access and address spoofing.
SNMP Community String: Example
The following example allows read-only access for all objects to members of the standard named access list snmpuser that specify the comaccess community string. No other SNMP managers have access to any objects.
snmp-server community comaccess ro snmpuser
SNMP Server Group: Example
The following example creates the SNMP server group public, allowing read-only access for all objects to members of the standard named access list snmpuser.
snmp-server group public v2c access snmpuser
SNMP New User: Example
The following example adds the user abcd to the public SNMP server group. In this example, no access list is specified for the user, so the standard named access list applied to the group applies to the user.
snmp-server user abcd public v2c
