Create a Trap definition file

Prerequisites

Before using this document, the reception of traps must be configured on the SNB. See procedure : 1 - Configure the box to receive traps

Purpose of this document

This document is intended for anyone (customer or consultant) who wants to add a trap definition file to define the actions to be taken in case of reception.

Configuration files

• /etc/snmp/snmptt.ini -> snmptt configuration, will be used to indicate the trap definition files to be taken into account.
• /etc/snmp/trapConf/* -> trap definition files. For each trap an action is configured.
• /var/log/snmptt/*.trap -> one file per server generating traps; file where traps received by the box are stored.
• /var/log/snmptt/snmpttunknown.log -> file where the unknown traps will be located, traps not specified in a definition file.

Principles

When a trap is received, the box will check in the definition files in snmptt.ini if an action is defined when the event is received.

• If so, the action specified in the definition file will be executed. This action will be to write the trap
  received in a *.trap file where * will be replaced by the IP address of the machine that sent the trap.
• If not, the trap will be written to the unknown traps file (/var/log/snmptt/snmpttunknown.log)

Create a trap definition file

Manual creation

Connect to the box that collects the traps.
Go to the /etc/snmp/trapConf folder:

cd /etc/snmp/trapConf

Create a definition file :

vim myTrapDef.conf

After analysis of the MIB of the equipment.
For each trap you want to process you have to add 2 lines:

EVENT linkDown .1.3.6.1.6.3.1.1.5.3 "Status Events" INFORMATIONAL
EXEC echo "$x$X |-| $o |-| Link down on interface $1">> /var/log/snmptt/"$aA".trap
#

The parts in red are the only things that can be modified. The rest is to be written as is.
The first line "EVENT" will describe the type of event. The name of the event should be put in one word and
the oid of the trap.
The second line "EXEC" will describe the action to be taken when the trap is received. Here the trap will be written to a file.
It will be formatted in a specific way. The fields of the message written in the file must be separated by the |-| separator.
The sentence written in the 3rd field will be the one displayed in the plugin output on the web interface.
In the example, the variable $1 is the first variable of the trap. To know the variables contained in the traps of a device, we must analyze its MIB.
If we want to display all the variables of the trap, we will use $*.

Example

A definition file for a Juniper SRX device that will capture UP and DOWN traps from a network link and a Fan Fail trap:

EVENT linkDown .1.3.6.1.6.3.1.1.5.3 "Status Events" INFORMATIONAL
EXEC echo "$x$X |-| $o |-| Link down on interface $1" >> /var/log/snmptt/"$aA".trap
#
EVENT linkUp .1.3.6.1.6.3.1.1.5.4 "Status Events" INFORMATIONAL
EXEC echo "$x$X |-| $o |-| Link up on interface $1" >> /var/log/snmptt/"$aA".trap
#
EVENT fanDown .1.3.6.1.4.1.2636.4.1.2 "Status Events" INFORMATIONAL
EXEC echo "$x$X |-| $o |-| Fan down" >> /var/log/snmptt/"$aA".trap

Here is the file where the received traps are written:

10 10 16:09:32 |-| .1.3.6.1.4.1.2636.4.1.2 |-| Fan down
11 10 09:05:03 |-| .1.3.6.1.6.3.1.1.5.3 |-| Link down on interface 535
11 10 09:05:04 |-| .1.3.6.1.6.3.1.1.5.4 |-| Link up on interface 535
12 10 08:05:29 |-| .1.3.6.1.6.3.1.1.5.3 |-| Link down on interface 535
12 10 08:06:31 |-| .1.3.6.1.6.3.1.1.5.4 |-| Link up on interface 535
12 10 09:37:50 |-| .1.3.6.1.6.3.1.1.5.3 |-| Link down on interface 535
12 10 11:25:52 |-| .1.3.6.1.6.3.1.1.5.4 |-| Link up on interface 535
13 10 03:27:40 |-| .1.3.6.1.6.3.1.1.5.3 |-| Link down on interface 535
13 10 03:27:41 |-| .1.3.6.1.6.3.1.1.5.4 |-| Link up on interface 535
13 10 17:05:27 |-| .1.3.6.1.6.3.1.1.5.3 |-| Link down on interface 535
13 10 17:05:51 |-| .1.3.6.1.6.3.1.1.5.4 |-| Link up on interface 535
14 10 01:06:46 |-| .1.3.6.1.6.3.1.1.5.3 |-| Link down on interface 535
14 10 01:06:51 |-| .1.3.6.1.6.3.1.1.5.4 |-| Link up on interface 535
14 10 09:07:38 |-| .1.3.6.1.6.3.1.1.5.3 |-| Link down on interface 535
14 10 09:07:52 |-| .1.3.6.1.6.3.1.1.5.4 |-| Link up on interface 535
14 10 17:08:40 |-| .1.3.6.1.6.3.1.1.5.3 |-| Link down on interface 535
14 10 17:08:54 |-| .1.3.6.1.6.3.1.1.5.4 |-| Link up on interface 535
15 10 01:09:42 |-| .1.3.6.1.6.3.1.1.5.3 |-| Link down on interface 535
15 10 01:09:55 |-| .1.3.6.1.6.3.1.1.5.4 |-| Link up on interface 535

Automatic creation with snmpttconvertmib

It is possible to generate the definition file automatically, from a MIB file.
Ordering :

snmpttconvertmib --in=path_to_mib --out=file_to_create --exec='echo "$x$X |-| $o |-|" >> /var/log/snmptt/"$aA".trap

Example:

snmpttconvertmib --in=/usr/share/snmp/mibs/STORMSHIELD-ALARM-MIB.mib --out=stormshield.conf --exec='echo "$x$X |-| $o |-|" >> /var/log/snmptt/"$aA".trap

Place the generated file in /etc/snmp/trapConf
Restart the snmptt service:

systemctl restart snmptt

Test trap reception:
Generate a trap from the box for itself:
Retrieve an existing OID from the previously generated definition file. Put in place of "OID" in the
order below.

snmptrap -c  -v 2c 127.0.0.1 "" 

Example:

snmptrap -c coservit -v 2c 127.0.0.1 "" .1.3.6.1.6.3.1.1.5.3

A file /var/log/snmptt/127.0.0.1.trap must be created and must contain the trap.

Using the definition file

Edit the file /etc/snmp/snmptt.ini

vim /etc/snmp/snmptt.ini

At the end of the file, in the [TrapFiles].
Add the path to the definition file :

Note :

Be careful to keep the structure of the lines below.
The <<END and END must be positioned as in the example:

snmptt_conf_files = <<END
/etc/snmp/trapConf/linkState.conf
/etc/snmp/trapConf/myTrapDef.conf
/etc/snmp/trapConf/anOtherDef.conf
END

Restart the snmptt service:

systemctl restart snmptt

Instantiate a checkpoint in ServiceNav

Create a checkpoint with the TRAP-Handle model

Every minute, the plugins will read in the *.trap file of the monitored machine.
For each new line that appears since the previous check, the plugin will look to see if it finds one of the patterns set
as a parameter and will return the status according to it. It is the pattern of the last trap received that will be taken into account.