Section 9.1. Understanding Traps


9.1. Understanding Traps

Before discussing the tools for receiving and generating traps, it's worth reviewing what a trap is. Traps were introduced in Chapter 2. 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 Chapter 2 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 she considers worth monitoring. An enterprise-specific trap is identified by two pieces of information: the enterprise ID of the organization that defined the trap and the 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 .1.3.6.1.4.1.2789. But you can further subdivide this, defining traps with enterprise IDs such as .1.3.6.1.4.1.2789.5000, .1.3.6.1.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.

9.1.1. SNMPv2 Traps

SNMPv2 defines traps in a slightly different way. In a MIB, SNMPv1 traps are defined as trAP-TYPE, SNMPv2 traps are defined as NOTIFICATION-TYPE. SNMPv2 also does away with the notion of generic trapsinstead, it defines many specific traps (properly speaking, notifications) in public MIBs. SNMPv3 traps, which are discussed briefly in Chapter 3, are simply SNMPv2 traps with added authentication and privacy capabilities. Most SNMP implementations support only Version 1.




Essential SNMP
Essential SNMP, Second Edition
ISBN: 0596008406
EAN: 2147483647
Year: 2003
Pages: 165

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net