Chapter 10. TrapsTraps provide a way for an agent to send a monitoring station asynchronous notification about conditions that the monitor should know about. The traps that an agent can generate are defined by the MIBs it supports; the number of traps can range from zero to hundreds. To see what traps are defined in any MIB file, search for the term "TRAP-TYPE" (SMIv1) or "NOTIFICATION-TYPE" (SMIv2) in the MIB file. This search will quickly get you a list of possible traps.
Of course, just having asynchronous traps arrive at your NMS isn't terribly useful. You can configure the NMS's response to different traps; the response can be anything from discarding the trap to running a script that sends a message to your pager (or even takes some drastic action, such as shutting down your power supplies). In this chapter, we'll show you how to handle incoming traps using OpenView and other tools such as Perl. Then we'll discuss how to read and configure different aspects of trap events. Finally, we'll show you how to define your own traps that report special conditions of particular interest to your network.
Before discussing the tools for receiving and generating traps, it's worth reviewing what a trap is. Traps were introduced in Chapter 2, "A Closer Look at SNMP". A trap is basically an asynchronous notification sent from an SNMP agent to a network-management station. Like everything else in SNMP, traps are sent using UDP (port 162) and are therefore unreliable. This means that the sender cannot assume that the trap actually arrives, nor can the destination assume that it's getting all the traps being sent its way. Of course, on a healthy network most traps should reach their destinations. But if networks were always healthy, we wouldn't need SNMP.
In somewhat more detail, a trap is a bundle of data that's defined by a MIB. Traps fall into two categories, generic and enterprise-specific. There are seven generic trap numbers (0-6), defined in Table 2-8, for conditions ranging from system reboots (coldStart) and interface state changes (linkUp and linkDown) to generic trap 6 (enterpriseSpecific). Enterprise-specific traps are the loophole that makes the trap mechanism so powerful. Anyone with an enterprise number can define enterprise-specific traps for whatever conditions they consider worth monitoring. An enterprise-specific trap is identified by two pieces of information: the enterprise ID of the organization that defined the trap and a specific trap number assigned by that organization. The notion of an enterprise-specific trap is extremely flexible, because organizations are allowed to subdivide their enterprises as much as they like. For example, if your enterprise number is 2789, your enterprise ID is .188.8.131.52.4.1.2789. But you can further subdivide this, defining traps with enterprise IDs such as .184.108.40.206.4.1.2789.5000, .220.127.116.11.4.1.2789.5001, and so on.
The fact that you've received a trap and therefore know its generic trap number, enterprise ID, and specific trap number is often all you need to diagnose a problem. But traps also carry additional information. In the case of generic traps 0-5, the specific information is predefined and hardwired into the NMS. When you receive a generic trap, the NMS knows how to interpret the information it contains and will be able to display it appropriately, whether it's the time of the reboot or the identity of the interface that just changed state. In contrast, the information carried by an enterprise-specific trap is entirely up to the person who defined the trap. An enterprise-specific trap can contain any number of variable bindings, or MIB object-value pairs. When you define your own traps, you can decide what information is appropriate for them to carry. The objects contained in a trap can be standard MIB objects, vendor-specific objects, or objects of your own devising. It's common to define objects purely for the purpose of including them within a trap.
10.1.1. SNMPv2 TrapsSNMPv2 defines traps in a slightly different way. In a MIB, Version 1 traps are defined as TRAP-TYPE, while Version 2 traps are defined as NOTIFICATION-TYPE. SNMPv2 also does away with the notion of generic traps -- instead, it defines many specific traps (properly speaking, notifications) in public MIBs. SNMPv3 traps, which are discussed briefly in Appendix F, "SNMPv3", are simply SNMPv2 traps with added authentication and privacy capabilities.Most SNMP implementations support only Version 1.
Copyright © 2002 O'Reilly & Associates. All rights reserved.