Trap Messages

The Purpose of Trap Messages

Early on in this tutorial, I pointed out that SNMP actually has two client-server applications. So far, all the messages that I've discussed are part of the SNMP query/response protocol, which is used by NMSs to query managed devices or to set parameters on those devices. The other application is the SNMP trap application, which is used for managed devices to send unsolicited messages to management stations (remember, to port 162) that were defined to the agent in its configuration. Traps were originally intended to be sent in the case of an extraordinary circumstance. They are triggered by the occurrence of some preset parameter in the agent. For example, if an interface link goes up or down, or if a parameter has a threshold defined, such as if disk space reaches 95% capacity, the device would send a trap. As the protocol was revised, attitudes about when to send traps have become more moderate. In the earlier RFC 1905 we are told that a trap is sent "when an exceptional situation occurs." But in the most current RFC 3416 it states that a trap "is often used to notify ... that an event has occurred or that a condition is present." That's a lot vaguer, isn't it? The traps have to be defined to the agent. They are also defined to the NMSs, so that the NMSs understand the content of the trap messages received. Traps are defined using ASN.1 in a NOTIFICATION-TYPE macro.

Example of NOTIFICATION-TYPE Macro

Just as with MIBs this tutorial did not attempt to teach how to write ASN.1 but rather allowed you to understand how it works by looking at examples, you'll take a look at the following examples of NOTIFICATION-TYPE definitions to understand how traps are defined with ASN.1: 

linkDown NOTIFICATION-TYPE
    OBJECTS { ifIndex, ifAdminStatus, ifOperStatus }
    STATUS  current
    DESCRIPTION
            "A linkDown trap signifies that the SNMP entity, acting in
            an agent role, has detected that the ifOperStatus object for
            one of its communication links is about to enter the down
            state from some other state (but not from the notPresent
            state).  This other state is indicated by the included value
            of ifOperStatus."
    ::= { snmpTraps 3 }

linkUp NOTIFICATION-TYPE
    OBJECTS { ifIndex, ifAdminStatus, ifOperStatus }
    STATUS  current
    DESCRIPTION
            "A linkUp trap signifies that the SNMP entity, acting in an
            agent role, has detected that the ifOperStatus object for
            one of its communication links left the down state and
            transitioned into some other state (but not into the
            notPresent state).  This other state is indicated by the
            included value of ifOperStatus."
    ::= { snmpTraps 4 }

These two traps are defined in the Interfaces MIB, which we have looked at before. I'm sure it is quite obvious to you that the DESCRIPTION definition is a description of what triggers the sending of a trap message. linkdown and linkup are the names of each of the traps defined above. Each trap has an OID that places it in the MIB tree, under the node snmpTraps. The one definition in the above example that needs more explanation is the defition of OBJECTS. If a NOTIFICATION-TYPE macro contains an OBJECTS clause, then the values of these objects (remember: these are definitions in the ifTable) will be provided in the defined trap message, if it is sent, in the variable bindings list in the order defined in the OBJECTS clause. So, let's review the SNMPv2 message format, in particular for a trap message.

Trap Message Format

Figure 63 depicts the format of an SNMPv2 trap message.

Figure 63: SNMPv2 Trap Format

The first variable in the variable bindings list is always the sysUpTime. The OID of sysUpTime is followed by its value. It is useful to the management application to know, for example, whether the system just rebooted or how much time passed since the last such trap. The second variable binding is always the snmpTrapOID. That is the object identifier of the trap. Using this OID, the definition of the trap can be located. This permits enterprise traps to be defined (and sent) in the same manner as standard traps, by using a NOTIFICATION-TYPE macro in an enterprie MIB just as standard traps are defined in standard MIBs. Following those two variable bindings are any other variable bindings that would be present due to an OBJECTS clause. For the examples shown above, there would be three more variable binding pairs.

Packet Capture of Trap Messages

Unfortunately, though you can generate traps from a computer with an SNMP agent running (and capture them with Wireshark) by disconnecting the network connection - generating a link down trap, the agent might only support the old SNMPv1 format (such as is the case with Windows XP). However, you might be able to have some other device send you traps. Of course, if you disconnect its only network connection to generate such a trap and your method of capturing the message is on your computer, then the message won't reach your computer to capture! However, don't despair. I've got a couple of options that you can try, besides the ones just mentioned.

If you want to generate and capture your own traps, but the above options will not do it for you, you can use trap generation software. Though I try to avoid promoting any commercial software, the primary open source option, Net-SNMP, which is an excellent software package, is more complicated than we need for the purpose of generating traps. So, I'll suggest that you download the free trial of Trap Console 2.1 from CSCare, Inc., an application with a web-based interface that suits our purpose. From my experience with it, even though you can run it and try some stuff without registering, the free registration allowed me to do more of what I wanted, so you might need to register to do what I did below. After installing it, you'll want to run the Console Client (if you don't want to install it as a Windows service, it will only run after you run it in console mode - you'll see various choices in your start menu). You can take a look at their online demo to see what you should get, but the online demo doesn't show how to send a trap (and, of course, you wouldn't be able to capture it, even if it did). After logging in (to your own client), select the "Traps" tab from the top menu and your browser window should look like this:

Figure 64: Trap Console 2.1 Traps Tab

On the same web page from which you downloaded Trap Console, you can download a manual, so you can try all sorts of things with this software (but the evaluation version is limited). (You can also find some assistance by clickint the "Description" button in the top right of the screen - I cut it off my screen capture to keep the size under control.) Among the things you can do with this software is select a trap and send it. For example, I selected the IF-MIB, the linkUp trap, with the snmpTraps enterprise (that just makes it the SNMPv2 version of the trap, consistent with the NOTIFICATION-TYPE we saw above. Notice (Figure 65) the trap information in the bottom pane of the window (and if you do this yourself, you can scroll to see it all) - the trap is snmpTraps.4, just as we saw above.

Figure 65: Trap Console - Selecting linkUp Trap

Now, you can go ahead and click on "Send the Trap" - you don't yet have to start Wireshark, as you will first have some information to fill in before finally clicking "Send Trap" at the bottom of the Send SNMP Trap page. But before you click at the bottom of that page, DO start Wireshark, and you'll be able to capture the packet. You can change the recipient IP address so that the message will actually go somewhere, and you can make the sender's IP address your own IP address. The recipient IP address need not exist, but it can't be a non-existent neighbor address because then your computer won't get an ARP response and the trap will not be sent! With the linkUp trap, there are several objects whose values are sent (see above), and you can fill in your choice of values for those in the form. After doing that, you can send the trap (but remember to first start Wireshark!).

And, as the old standby, in case you didn't do any of the above methods to capture any trap messages (but why not? It was so much fun!), you can download my capture file and view it with Wireshark. As you can see in Figure 66 (in case you didn't even download the file to view in Wireshark), I captured the linkUp trap as defined in the IF-MIB - look at the snmpTrapOID, which is highlighted in blue. The first OID that you see on that line is the OID of the object snmpTrapOID.0, while the second OID that you see is the OID of the actual NOTIFICATION-TYPE for the linkUp trap defined in the IF-MIB. That is the value assigned to the variable snmpTrapOID. Be sure you are not confused by this!

Figure 66: Packet Capture linkUp Trap

The ifIndex for this trap is 7. Compare what you see to the trap message format we saw above and to the NOTIFICATION-TYPE. You'll see that everything expected is present, and more. In addition to the expected variable bindings, there are two objects from the SNMP-COMMUNITY-MIB. Since the trap was generated using the Trap Console software, and I don't know the inner workings of this software, I can only guess why these additional objects are included in the variable bindings list. RFC 3584, in particular, section 3.1 (4), explains that these objects and also the snmpTrapEnterprise.0 variable that is the last object in our variable bindings list are to be included when translating an SNMPv1 trap to an SNMPv2 trap. The Trap Console software appears to act as a proxy that translates the SNMPv1 to the SNMPv2 format - I don't know why it doesn't just send the SNMPv2 trap as a native SNMPv2 agent would. Perhaps it has something to do with the fact that the software can also serve as an proxy that forwards traps. In any event, the result is that we get to see implementation of RFC 3584 and use of the SNMP-COMMUNITY-MIB defined there. And, by the way, note that the trap was sent to port 162 (you need to look at the UDP information), while the other SNMP messages we saw that were sent from the manager to the agent were sent to port 161.

Inform and Report Messages

Though we don't see much use of the InformRequest message, it is defined in RFC 3416 as a message sent in the same circumstances that a trap might be sent, but there is "a confirmed notification delivery mechanism," though "there is, of course, no guarantee of delivery". A Response-PDU would be sent as the confirmation by the receiving entity. Just as the conditions under which a trap is sent changed (and became more liberal) as new RFCs were issued, it seems that the definition of an InformRequest has been liberalized. If in RFC 1905 we can deduce (what is commonly stated in various literature) that an InformRequest is meant to be sent from one manager to another, perhaps forwarding a trap message received by the first manager, and under the assumption that an agent was never intended to have to deal with acknowledgments to traps (see my discussion of the management architecture). However, in the latest RFC to define the InformRequest PDU, we find that the definition is vague enough to mean that managed entities (agents) can also send these notifications.

The format of an InformRequest is almost identical to that of a trap and considering that they are not commonly used, I will not elaborate, but will provide a captured packet for you to examine yourselves. Like the trap message capture, I used Trap Console to generate this file (so you can try it, too), and therefore you will again see the additional variable bindings as discussed in the previous section. There is another packet that I left this time in the capture file - the ICMP message informing us that the recipient host, 10.0.0.138 (my router) does accept messages to port 162, the port to which both traps and InformRequest messages are sent.

There is one more type of message that sounds a bit like a trap, which is why I am mentioning it in this chapter. It is called a Report-PDU. It is defined in ASN.1 in RFC 3416 and preceded by the comment: 

   --   Usage and precise semantics of Report-PDU are not defined
   --   in this document.  Any SNMP administrative framework making
   --   use of this PDU must define its usage and semantics.

That doesn't seem very helpful, but there is use of the Report-PDU in SNMPv3, as specified in RFCs 3411, 3412, and 3413. SNMPv3 and the SNMP security model (SNMPv3 brings security to SNMP) are the topics covered in the last chapter in this SNMP tutorial.

Previous Next

www.rad.com