SNMP TRAP state issue

[larp]

We are monitoring a switch using SNMP.
We have configured the switch using Nagios configuration wizard for SNMP traps.
We have setup the snmptrap.conf, snmptt.conf, and imported the MIB.
We can see the trap in the Nagios host detail, and we have verified that the trap text is OK.

But in the snmptt.log we see:
Tue Jun 2 15:45:30 2015 .1.3.6.1.4.1.41316.0.1 Normal "Status Events" localhost - Trap generated by VMX Server AggregatorValueTrafficLightAlertConfiguration-1853204476 alert-1433200935432 FX.UC5:H2 to FX.UC5:H7A RET Pricing RTT mAv Latency (ms) Latency is now 590.627 and the status is now RED RED EVENT 02/06/2015 15:45:30.303 (CEST)

and in the Nagios event log we see:
2015-06-02 15:45:33SERVICE ALERT: n25100;SNMP Traps;OK;HARD;1;Trap generated by VMX Server AggregatorValueTrafficLightAlertConfiguration-1853204476 alert-1433200935432 FX.UC5:H2 to FX.UC5:H7A RET Pricing RTT mAv Latency (ms) Latency is now 590.627 and the status is now RED

and from the switch we see:
15:45:30.306031 IP n25100.danskenet.net.34807 > w80432.dk2.danskenet.net.snmptrap: V2Trap(407) system.sysUpTime.0=5180817 S:1.1.4.1.0=E:41316.0.1 S:18.1.3.0=127.0.0.1 E:41316.1.1="AggregatorValueTrafficLightAlertConfiguration-1853204476" E:41316.1.2="alert-1433200935432" E:41316.1.3="FX.UC5:H2 to FX.UC5:H7A RET Pricing RTT mAv Latency (ms)" E:41316.1.4="Latency is now 590.627 and the status is now RED" E:41316.1.5="RED" E:41316.1.6="EVENT" E:41316.1.7="02/06/2015 15:45:30.303 (CEST)"

So some how the red status is translated into a OK state and the status of the switch isn't turning red which is should.

[ssax]

Please post the appropriate trap that is being fired from your /etc/snmp/snmptt.conf file so that we can take a look.

Most likely you need to change the trap from Normal to Critical, or you need to duplicate it and use a MATCH statement in your snmptt.conf so that it is set at critical if it matches RED.

[larp]

This is the trap in snmptt.conf and if I understand you correctly the highlighted part has to be changed from normal to critical.

So the trap translation can only assign a single severity to a single OID, it is not posible to filter on the content of the trap to influence the severity ?

EVENT vmxTrap .1.3.6.1.4.1.41316.0.1 "Status Events" Normal
FORMAT Trap generated by VMX Server $*
EXEC /usr/local/bin/snmptraphandling.py "$r" "SNMP Traps" "$s" "$@" "$-*" "Trap generated by VMX Server $*"
SDESC
Trap generated by VMX Server
-- 1.3.6.1.4.1.41316.0.1
Variables:
1: alertDefinitionId
2: alertId
3: description
4: message
5: status
6: type
7: date
EDESC

[ssax]

You would use a MATCH statement in your /etc/snmp/snmptt.conf and then restart snmptt service.

*** You may need to adjust the match statement for you variables.

Code: Select all

EVENT vmxTrap .1.3.6.1.4.1.41316.0.1 "Status Events" Critical
FORMAT Trap generated by VMX Server $*
MATCH $4: RED
EXEC /usr/local/bin/snmptraphandling.py "$r" "SNMP Traps" "$s" "$@" "$-*" "Trap generated by VMX Server $*"
SDESC
Trap generated by VMX Server
-- 1.3.6.1.4.1.41316.0.1
Variables:
1: alertDefinitionId
2: alertId
3: description
4: message
5: status
6: type
7: date
EDESC


EVENT vmxTrap .1.3.6.1.4.1.41316.0.1 "Status Events" Normal
FORMAT Trap generated by VMX Server $*
MATCH $4: GREEN
EXEC /usr/local/bin/snmptraphandling.py "$r" "SNMP Traps" "$s" "$@" "$-*" "Trap generated by VMX Server $*"
SDESC
Trap generated by VMX Server
-- 1.3.6.1.4.1.41316.0.1
Variables:
1: alertDefinitionId
2: alertId
3: description
4: message
5: status
6: type
7: date
EDESC

[Box293]

snmptt documentation is quite detailed:

http://snmptt.sourceforge.net/docs/snmp ... CONF-MATCH