Documentation

2 - Create a Trap definition file

On the page

Need some help?

Pre-requisites

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

Purpose of this document

This document is intended for any person (customer or consultant) wishing to add a trap definition file to define the actions to be carried out in case of reception.

Configuration files

  • /etc/snmp/snmptt.ini -> snmptt configuration, will be used to indicate the traps 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 the traps received by the box are located.
  • /var/log/snmptt/snmpttunknown.log -> file where unknown traps, traps not filled in a definition file, will be found.

Principles

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

  • If yes, 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 trap file (/var/log/snmptt/snmpttunknown.log).

Create a trap definition file

Manual creation

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

cd /etc/snmp/trapConf

Create a definition file :

vim myTrapDef.conf

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

EVENT linkDown .1.3.6.1.6.3.1.1.5.3 "Status Events" INFORMATION
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 changed. The rest is to be written as is.
The first line "EVENT" will describe the type of event. You will have to put the name of the event in one word and
the trap's nest.
The second line "EXEC" will describe the action to be carried out when the trap is received. Here the trap will be written in a file.
It will be formatted in a precise manner. The fields of the message written to 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 represents the first variable of the trap. To know the variables contained in the traps of an equipment, it is necessary to 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 the UP and DOWN traps of a network link and a Fan Fail trap:

EVENT linkDown .1.3.6.1.6.3.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.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.5.3 |-| Link down on interface 535
11 10 09:05:04 |-| .1.3.6.1.6.3.1.5.4 |-| Link up on interface 535
12 10 08:05:29 |-| .1.3.6.1.6.3.1.5.3 |-| Link down on interface 535
12 10 08:06:31 |-| .1.3.6.1.6.3.1.5.4 |-| Link up on interface 535
12 10 09:37:50 |-| .1.3.6.1.6.3.1.5.3 |-| Link down on interface 535
12 10 11:25:52 |-| .1.3.6.1.6.3.1.5.4 |-| Link up on interface 535
13 10 03:27:40 |-| .1.3.6.1.6.3.1.5.3 |-| Link down on interface 535
13 10 03:27:41 |-| .1.3.6.1.6.3.1.5.4 |-| Link up on interface 535
13 10 17:05:27 |-| .1.3.6.1.6.3.1.5.3 |-| Link down on interface 535
13 10 17:05:51 |-| .1.3.6.1.6.3.1.5.4 |-| Link up on interface 535
14 10 01:06:46 |-| .1.3.6.1.6.3.1.5.3 |-| Link down on interface 535
14 10 01:06:51 |-| .1.3.6.1.6.3.1.5.4 |-| Link up on interface 535
14 10 09:07:38 |-| .1.3.6.1.6.3.1.5.3 |-| Link down on interface 535
14 10 09:07:52 |-| .1.3.6.1.6.3.1.5.4 |-| Link up on interface 535
14 10 17:08:40 |-| .1.3.6.1.6.3.1.5.3 |-| Link down on interface 535
14 10 17:08:54 |-| .1.3.6.1.6.3.1.5.4 |-| Link up on interface 535
15 10 01:09:42 |-| .1.3.6.1.6.3.1.5.3 |-| Link down on interface 535
15 10 01:09:55 |-| .1.3.6.1.6.3.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.
Command:

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

For 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

Testing trap reception :
Generate a trap from the SNB itself:
Retrieve an existing OID from the previously generated definition file. To be put in place of "OID" in the
order below.

snmptrap -c  -v 2c 127.0.0.1 "" 

For example:
snmptrap -c coservit -v 2c 127.0.0.1 "" .1.3.6.1.6.3.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 :

Caution :

Be careful to keep the format of the lines below.
The <

snmptt_conf_files = <

Restart the snmptt service:

systemctl restart snmptt

Configure a ServiceNav check

Creating a check using the template TRAP-Handle

Every minute, the plugin will read the *.trap file concerning the monitored host.
For each new line that has appeared since the previous check, the plugin will look for matching patterns set in the configuration of the check
and return the status accordingly. The most recent pattern matching trap is the one reported.

This may also be of interest to you

word image 10

Using the Global-Plugin-Execution service template

ps 1

Using generic PowerShell - GLOBAL-PS-Values models

Configuring a ServiceNav Box to receive traps

en_US
fr_FR en_US

Welcome to ServiceNav!

Need help? More information about our products? Write to us!
You have taken note of our privacy policy.

[COVID - 19 ] - TELEWORKING, TARGET AVAILABILITY 100% !

While the epidemic lasts, ensure the availability and performance of your IT services for teleworking, with ServiceNav!

Following the government's call to mobilize to help businesses overcome the current health and economic context, we help you, free of charge, to ensure the complete monitoring of your teleworking environments: VPN, VDI, Teams, Skype Enterprise, Citrix... Objectives: collection, availability and usage indicators, dashboards to support your communication.
We use cookies to ensure that you have the best possible experience on our site, and if you continue to use this site, we will assume that you are satisfied with it.

Reserve your place

You have taken note of our privacy policy.