Polling ConfigurationTopEvent ConfigurationSNMP Traps

SNMP Traps

SNMP stands for Simple Network Management Protocol. The funnny thing about the name is that SNMP is most definitely not simple! At pretty much any stage of understanding SNMP; from the concepts, through to the data layout, right down to the coding; it is not simple. Fortunately you can often ignore all the gritty complex detail and make vast simplifications.

One part of SNMP is a trap. A trap is a one-way message from a network element; such as a router, switch or server; to the NMS. The messages are sent via UDP, which means they are not guaranteed to arrive.

The most common messages are the 6 generic messages. The main ones being link up, link down and agent reset (which usually means the device was rebooted). There are also whats called "enterprise specific" traps, these are the ones the vendors create and can give a rich set of traps, if they will tell you what they mean.

How JFFNMS processes traps

SNMP trap consolidation process

snmptrap

By itself, JFFNMS cannot receive traps. It requires an external program called snmptrapd to receive and decode the trap from the network. Figure * gives an overview of how SNMP traps are handled in JFFNMS.

snmptrapd is configured to call a script within JFFNMS which inserts the trap and its variables (call varbinds) into the JFFNMS database. All that JFFNMS knows at this point is the source IP of the trap, the trap id (OID) and a set of varbinds identifed by order.

The snmp consolidator then processes the new traps my comparing the trap OID to the ones in the Trap Receivers table. If there is a match, the varbinds are passed to the Receiver Command and the results of the command are then passed to the backend.

The backend may do whatever it wants with the trap information, but a very common thing is to use the event backend plugin which will put a new row into the event database table. This new event will then show on the operator screens.

SNMP Trap Receivers Table

SNMP Trap Receviers

Field

Description
ID The internal ID of this rule, only needed for debugging
Position Releative position of this rule to the others in the table. JFFNMS processes the rules from lowest position to highest.
Description Description of the trap of what this rule does.
Interface Type The Interface Type that this trap should apply to.
OID Match SNMP traps are identified by OID, traps that have this OID will be processed by this rule.
Receiver Command Which script in the directory engine/trap_recievers will be used to process the varbinds into event fields.
Parameters Parameters passed to the Receiver Command script.
Backend What backend to process the output of the Receiver Command. They are identical as the poller backends, see Backend Items for details about them.
Stop If Matches Do no more checks for this trap if the OID matches.

This table is used to tell JFFNMS which traps you are interested in and if it finds traps matching the OID, what it should do with them. You can access it via the Administration menu item Event Analyzer => SNMP Trap Receivers. It has the following fields:

Configuring New Traps

To configure a new SNMP trap, you first need to do some homework about the trap and gather the following information:

Trap Setup Example

You're worried the fan on your router might be broken, so you want to know if the fan is broken trap is sent, 1.3.6.1.4.1.9.9.13.3.0.4 This trap has 5 variable bindings:

  1. the enterprise of the trap, for this trap it is enterprises.9.9.13.3
  2. Name of the fan that has the problem, eg ps2
  3. The IP address of the source of the trap
  4. The SNMP community of the trap
  5. The state of the trap (its a number 1-5)

Most of this is pretty useless, we only really need to know something has happened and then to what fan is it.

So we setup the event to fill in varbind 2 into the info field and then setup a new event which prints

Problem with fan at <info>.

So the result on the status screen is something like

Problem with fan at ps2.

The idea with the SNMP traps is to plan forward but implement it backwards. A lot of the other objects should be done this way too.

So start with the event first. Create a new event type, you can see this in the Event Types section. Note down the event ID.

Create a new Backend. The Backend Command will be "event" and the Paramter will be the id of the new Event Type you created in the previous step.

You now need to create a Receiver Command. As it is infinitely easier for me to code one than explain it ill just assume I wrote it for now. As we are mapping varbinds to variables, well assume it is called mapping.

Finally create the new SNMP Trap Receiver. The OID is the OID of the trap. The Receiver Command is mapping, while the parameters are info=2 (which means the event field called info will get the contents of the second varbind). Backend is the backend you created previously.


JFFNMS Manual, last changed March 29, 2008


Polling ConfigurationTopEvent ConfigurationSNMP Traps