NET-SNMP发Trap

摘自O'Relly《Essential SNMP》

10.3 Sending Traps

By now you should have a mechanism in place for receiving traps. In this section, we'll look at some different utilities that send traps and allow you to develop traps that are appropriate for your own environment. You'll notice that almost all trap utilities are command-line based. This allows you to execute the command from within a script, which is almost always what you want to do. For example, you can write a shell script that checks disk space every five minutes and sends a trap to the NMS if you're running low. You can also use these trap generators within existing programs and scripts. If you have a Perl script that accesses a database, you can use the Perl SNMP module to send a trap from within the script if a database insert fails. The possibilities are almost endless.

Although there are many different snmptrap programs, they are all fundamentally similar. In particular, though their command-line syntax may vary, they all expect roughly the same arguments:

Port

The UDP port to which to send the trap. The default port is 162.

SNMP version

The SNMP version appropriate to the trap you want to send. Many traps are defined only for Version 2. Note that many SNMP tools support only Version 1.

Hostname or IP address of NMS

The hostname or IP address of your NMS -- i.e., the trap's destination. It is better to use an IP address than a hostname in case you are sending traps during a Domain Name System (DNS) outage. Remember that SNMP is most valuable when your network is failing; therefore, try to avoid assuming that you have a fully functional network when you design traps.

Community name

The community name to be sent with the trap. Most management stations can be configured to ignore traps that don't have an appropriate community string.

Enterprise OID

The full enterprise OID for the trap you want to send: everything in the trap's OID from the initial .1 up to the enterprise number, including any subtrees within the enterprise but not the specific trap number. For example, if your enterprise number is 2789, you've further subdivided your enterprise to include a group of traps numbered 5000, and you want to send specific trap 1234, the enterprise OID would be .1.3.6.1.4.1.2789.5000.

If you have some reason to send a generic trap, you can set the enterprise ID to anything you want -- but it's

probably best to set the enterprise ID to your own enterprise number, if you have one.

Now for the most confusing case. There are a few specific traps defined in various public MIBs. How do you send them? Basically, you construct something that looks like an enterprise OID. It's best to look at an example. One such trap is rdbmsOutOfSpace, which is defined in the RDBMS MIB. Its complete OID is .1.3.6.1.2.1.39.2.2 (.iso.org.dod.internet.mgmt.mib-2.rdbmsMIB.rdbmsTraps.rdbmsOutOfSpace). To send this trap, which is really an SNMPv2 notification, you would use everything up to rdbmsTraps as the enterprise OID, and the entire object ID as the specific trap number.

Hostname or IP address of sender

The IP address of the agent that is sending the trap. Although this may appear to be superfluous, it can be important if there is a proxy server between the agent and the NMS. This parameter allows you to record the actual address of the agent within the SNMP packet; in turn, the NMS will read the agent's address from the trap and ignore the packet's sender address. If you don't specify this parameter, it will almost always default to the address of the machine sending the trap.

Generic trap number

A number in the range 0-6. The true generic traps have numbers 0-5; if you're sending an enterprise-specific trap, set this number to 6. Table 2-8 lists the generic traps.

Specific trap number

A number indicating the specific trap you want to send. If you're sending a generic trap, this parameter is ignored -- you're probably better off setting it to zero. If you're sending a specific trap, the trap number is up to you. For example, if you send a trap with the OID .1.3.6.1.4.1.2500.3003.0, 3003 is the specific trap number.

Timestamp

The time elapsed between the last initialization of the network entity and the generation of the trap.

OID_1, type_1, value_1

Data bindings to be included in the trap. Each data binding consists of an OID together with a datatype, followed by the value you want to send. Most programs let you include any number of data bindings in a trap. Note that the OIDs for these variable bindings are often specific to the trap and therefore "underneath" the specific OID for the trap. But this isn't a requirement, and it's often useful to send bindings that aren't defined as part of the trap.

Before we start to tackle this section, let's take a moment to review what we learned in Chapter 2 about the various datatypes:

• Each variable that we send has a particular datatype.

• Different datatypes are supported by different versions of SNMP.

• Some common datatypes are INTEGER, OctetString, Null, Counter, Gauge, and TimeTicks.

10.3.4 Sending Traps with Net-SNMP

This snmptrap program looks very similar to OpenView's snmptrap. This program uses a single letter to refer to datatypes, as seen by doing "snmptrap -h"

Here's how the Net-SNMP snmptrap program is invoked:

snmptrap hostname community enterprise-oid agent /

generic-trap specific-trap uptime [OID type value]...

If you use two single quotes ('') in place of the time, snmptrap inserts the current time into the trap. The following command generates a trap with a single value. The object ID is 2005.1, within our private enterprise; the value is a string that tells us that the web server has been restarted:

$ snmptrap nms public .1.3.6.1.4.1.2789.2005 ntserver1 6 2476317 '' /

.1.3.6.1.4.1.2789.2005.1 s "WWW Server Has Been Restarted"

Here's how to send a Version 2 notification with Net-SNMP:[10]

[10] For information about sending Version 3 notifications with Net-SNMP, see Appendix F.

$ snmptrap -v2c nms public '' .1.3.6.1.6.3.1.1.5.3 /

ifIndex i 2 ifAdminStatus i 1 ifOperStatus i 1

The command is actually simpler than its Version 1 equivalent. There are no generic numbers, specific numbers, or vendor IDs. The "" argument defaults to the current system uptime. The OID specifies the linkDown notification, with three data bindings specifying the link's status. The definition of linkDown in the IF-MIB states that the linkDown notification must include the ifIndex, ifAdminStatus, and ifOperStatus objects, which report the index of the interface that went down, its administrative status, and its operational status, respectively. For ifAdminStatus and ifOperStatus, a value of 1 indicates that the link is up. So this notification reports that interface 2 has changed its state from "down" to "up."

Again, the snmptrap command-line tool lets you integrate SNMP monitoring into shell scripts and other programs.

C.3.6 snmptrap

To send a trap, use the snmptrap command. The syntax for this command is:

snmptrap options hostname community trap parameters...

For Version 1, the following trap parameters are required:

enterprise-oid agent trap-type specific-type uptime objectID type value...

This command is discussed in detail in Chapter 10. Each object ID/type/value triplet specifies a variable binding to be

included with the trap; you may include any number of variable bindings. Note that the agent and the uptime are not optional; however, if you provide an empty string ("") as a placeholder they default to the IP address of the system sending the trap and the system's current uptime.

The parameters are simpler for Version 2 traps, largely because traps (now called notifications) are full-fledged MIB objects in their own right. The following parameters are required:

snmptrap -v 2c options hostname community uptime trapoid objectID type value...