Fault management systems are becoming widely available for download from the internet, but not all of them are capable of deciphering even the basic information from the trap, as they do not all support the SNMPv2c and SNMPv3 protocols. The way the data is stored in the PDU differs by version. In order to understand the data stored in an SNMP Traps PDU, one must understand the underlying ASN.1 syntax notation that provides the structure for the network packet itself. To do this, we will explore the PDU structure and the components of the data therein.



SNMP Traps can come in several formats. First, they may be sent using different version protocols over the wire (SNMPv1, SNMPv2c, and SNMPv3). Depending on the version used to send the trap, the packet structure is different. The manager must be able to decode the packet appropriately.

The SNMPv1 protocol uses a specific Trap PDU format. This format includes the following fields: version, enterprise OID, Trap Agent address, generic type, specific type, and varbinds. The version field tells the decrypting manager that it is a version 1 PDU. The Trap Agent Address tells the manager the ?true? source of the event. This field is important because the trap may have been forwarded by a third party agent and the IP packet will contain the IP address of the forwarder, not the true source of the event. Generic Type tells the manager what type of generic trap (GT) it is. The values of GT range from 1 to 6. GT 1 means ?coldstart? (the agent has just booted up cold). GT 2 means ?warmstart? (the agent has rebooted). GT 3 means ?linkup? (a port has been plugged into a switch, or a machine was turned on). GT 4 means ?linkdown? (a port has been disconnected or something has gone down). GT 5 means ?authfail? (there was an authentication failure and the agent is trying to report a possible attempt by a user of getting access to restricted resources). GT6 means that this trap is not generic at all, but specific, and the next field specific type (ST) will specify the actual type of trap this corresponds to. In all the previous cases save the last, ST will be set to 0. But in the last case, ST will have a number ranging from 1 to 2147483647. The manager then needs access to the SNMP MIB to be able to decode and understand the type of type this actually represents. Finally, the varbinds contain information about the event itself that the manager can use to determine whether or not to take a specific action.

SNMP Traps that are sent using the SNMPv2 protocol have a slightly different format. They are actually called SNMP Notifications, not SNMP Traps. The PDU contains a version flag, a timestamp, a Notification OID, and varbinds. The version contains an identifier for SNMPv2c, and the timestamp contains a tick count of the specific time that the event was sent. The Notification OID describes what type of event is being sent. Instead of like SNMPv1, where the generic type and specific type were separate fields, the SNMPv2c format only specifies a single OID, but the GT and ST values are included inside of it. The OID has the format enterprise.GT.ST. For example, if the OID was 1.3.6.1.4.1.7013.1.1.2.0.1, the GT and ST are the last two parts of the entire OID (GT= 0, and ST=1). Like the SNMPv1 trap, the last section of the PDU, the varbinds, contains information about the event itself.

Not to be forgotten, there is also the Inform type of SNMP Traps (only found in the SNMPv2c version), which requires the management station to acknowledge receipt of the message. If a receipt is not sent back, the originator will continue to send messages until the package is acknowledged. Though this is an option, not many systems or agents actually send these.

The SNMPv3 format is same as SNMPv2c , yet the entire mechanism includes encryption between the sending agent and the receiving manager. So in essence, it is exactly the same but is stored inside an encrypted envelope. The manager and agent must have agreed upon a set of keys and the manager must be able to decrypt the envelope which arrives from the agent, using these keys. If the keys do not match, the envelope cannot be decrypted and the SNMP Traps cannot be read.

So, it is critical to ensure that your SNMP Trap Manager is capable of receiving not only SNMPv1 but also SNMPv2c and SNMPv3 traps, notifications, and informs. The ability of the manager to decode these packets and PDU messages is not trivial, especially in the case of SNMPv3, so choose wisely when building out your fault management solution.