Older versions of SNMP relied on a single unencrypted 'community string' for both get requests and traps, which made it very insecure on the network (anyone with network experience could 'snoop' on the network and detect the unencrypted community strings).

If the sender doesn't get the acknowledgement back, then it knows there is an existing problem and can log it for sysadmins to find when they interrogate the device. Upon receipt of an INFORM, the receiver must send an acknowledgement back. The SNMP v2c specification introduced the idea of splitting traps into two types the original 'hope it gets there' trap and the newer 'INFORM' traps.

This means if the configuration on the sending device is wrong (using the wrong receiver IP address or port) or the receiver isn't listening for traps or rejecting them out of hand due to misconfiguration, the sender will never know. Since SNMP is primarily a UDP based system, traps may be 'lost' when sending between devices the sending device does not wait to see if the receiver got the trap. This blog covers SNMPv3 traps, as polling and version 2c traps are covered elsewhere in our documentation. The latter includes instances such as someone logging on, the device powering up or down, or a wide variety of other problems that would need this type of investigation. There are two modes of operation with SNMP - get requests (or polling) where one device requests information from an SNMP enabled device on a regular basis (normally using UDP port 161), and traps where the SNMP enabled device sends a message to another device when an event occurs (normally using UDP port 162). By default, it is a UDP based protocol where communication is based on a 'fire and forget' methodology in which network packets are sent to another device, but there is no check for receipt of that packet (versus TCP when a network packet must be acknowledged by the other end of the communication link). SNMP has gone through several revisions to improve performance and security (version 1, 2c and 3). They can be quite confusing and complicated to set up the first time you go through the process, but when you understand what is going on, everything should make more sense. We have various articles already in our documentation for setting up SNMPv2 trap handling in Opsview, but SNMPv3 traps are a whole new ballgame.

Configure snmp trap receiver centos