Hello,
first of all thank you in advance for the time you spend to read this long
question, then excuse me for my bad exposition, I don't speak English very well
:)
I want to tell you a problem that I can't resolve, hope you can help me.
I have a Nagios station configured for active and passive monitoring checks
installed on Vmware Virtual Machine with Ubuntu 12.04.1 LTS.
I need to receive trap with Nagios so I installed and configured Net-SNMP /
UCD-SNMP packages and snmptrapd.
Started snmptrapd: sudo snmptrapd -A -n -d -On -f -d -Lf
"/var/log/snmptt/snmptrapd.log"
After converted MIB with SNMPTTCONVERTMIB I started to receive traps from my
network devices.
All works fine, and Nagios handles traps!!!!
But...
There are traps that SNMPTT can't resolve :(
I have several network devices like DELL Switch Powerconnect 5448 (but I
suppose the problem is for all the DELL Powerconnect54xx switches and maybe
alse other devices)
configured for sending snmp trap to the monitoring station.
Most of the traps are correctly handled (as linkUp or linkDown port status,
etc.) but there are traps that snmptt can't handle.
For example this trap, defined in the RADLAN-MIB:
================================================================================
...
rldot1dStpPortStateForwarding TRAP-TYPE
ENTERPRISE rnd
VARIABLES { rndErrorDesc, rndErrorSeverity,
rldot1dStpTrapVrblifIndex, rldot1dStpTrapVrblVID }
DESCRIPTION
"The trap is sent by a bridge when any of its configured ports
transitions from the Learning state to the Forwarding state."
::= 151
...
================================================================================
This is the definition inside configuration file created by snmpttconvertmib:
================================================================================
...
#
EVENT rldot1dStpPortStateForwarding .1.3.6.1.4.1.89.0.151 "Status Events" Normal
FORMAT The trap is sent by a bridge when any of its configured ports $*
EXEC /usr/local/nagios/libexec/eventhandlers/submit_check_result $r Trap 1 "The
trap is sent by a bridge when any of its configured ports $*"
SDESC
The trap is sent by a bridge when any of its configured ports
transitions from the Learning state to the Forwarding state.
Variables:
1: rndErrorDesc
2: rndErrorSeverity
3: rldot1dStpTrapVrblifIndex
4: rldot1dStpTrapVrblVID
EDESC
#
...
================================================================================
And this is what happen when the trap is received by SNMPTT (snmptt.debug):
================================================================================
********** SNMPTT v1.3 started: Tue May 28 02:59:20 2013 **********
********** Net-SNMP version 5.0403 Perl module enabled **********
********** MIBS: ALL **********
Reading trap. Current time: Tue May 28 02:59:20 2013
Multi-line value detected - merging onto one line...
Raw trap passed from snmptrapd:
UDP: [172.16.254.29]:161->[172.16.20.65]:162
UDP: [172.16.254.29]:161->[172.16.20.65]:162
.1.3.6.1.2.1.1.3.0 0:4:57:47.50
.1.3.6.1.6.3.1.1.4.1.0 .1.3.6.1.4.1.89.0.151
.1.3.6.1.4.1.89.2.3.1.0 "%STP-W-PORTSTATUS: g9: STP status Forwarding
"
.1.3.6.1.4.1.89.2.3.2.0 1
.1.3.6.1.4.1.89.57.2.8.1.0 9
.1.3.6.1.4.1.89.57.2.8.2.0 0
.1.3.6.1.6.3.18.1.3.0 172.16.254.29
.1.3.6.1.6.3.18.1.4.0 "public"
.1.3.6.1.6.3.1.1.4.3.0 .1.3.6.1.4.1.89
Items passed from snmptrapd:
value 0: UDP: [172.16.254.29]:161->[172.16.20.65]:162
value 1: 172.16.254.29
value 2: .1.3.6.1.2.1.1.3.0
value 3: 0:4:57:47.50
value 4: .1.3.6.1.6.3.1.1.4.1.0
value 5: .1.3.6.1.4.1.89.0.151
value 6: .1.3.6.1.4.1.89.2.3.1.0
value 7: %STP-W-PORTSTATUS: g9: STP status Forwarding
" .1.3.6.1.4.1.89.2.3.2.0 1 .1.3.6.1.4.1.89.57.2.8.1.0 9
.1.3.6.1.4.1.89.57.2.8.2.0 0 .1.3.6.1.6.3.18.1.3.0 172.16.254.29
.1.3.6.1.6.3.18.1.4.0 "public
value 8: .1.3.6.1.6.3.1.1.4.3.0
value 9: .1.3.6.1.4.1.89
Agent IP address was blank, so setting to the same as the host IP address of
172.16.254.29
Agent IP address (172.16.254.29) is the same as the host IP, so copying the
host name: UDP: [172.16.254.29]:161->[172.16.20.65]:162
Trap received from UDP: [172.16.254.29]:161->[172.16.20.65]:162:
.1.3.6.1.4.1.89.0.151
0: hostname
1: ip address
2: uptime
3: trapname / OID
4: ip address from trap agent
5: trap community string
6: enterprise
7: securityEngineID (snmptthandler-embedded
required)
8: securityName (snmptthandler-embedded
required)
9: contextEngineID (snmptthandler-embedded
required)
10: contextName (snmptthandler-embedded
required)
0+: passed variables
Value 0: UDP: [172.16.254.29]:161->[172.16.20.65]:162
Value 1: 172.16.254.29
Value 2: 0:4:57:47.50
Value 3: .1.3.6.1.4.1.89.0.151
Value 4: 172.16.254.29
Value 5:
Value 6: .1.3.6.1.4.1.89
Value 7:
Value 8:
Value 9:
Value 10:
Agent dns name: UDP: [172.16.254.29]:161->[172.16.20.65]:162
Ent Value 0 ($1): .1.3.6.1.4.1.89.2.3.1.0=%STP-W-PORTSTATUS: g9: STP status
Forwarding
" .1.3.6.1.4.1.89.2.3.2.0 1 .1.3.6.1.4.1.89.57.2.8.1.0 9
.1.3.6.1.4.1.89.57.2.8.2.0 0 .1.3.6.1.6.3.18.1.3.0 172.16.254.29
.1.3.6.1.6.3.18.1.4.0 "public
********************************************************************************
================================================================================
As you can see the 4 expected variables are not recognized by SNMPTT.
SNMPTT put all variables and values inside the first variable ($1)
The problem I think is the carriage return/line feed inside the packet sent by
the DELL Switch:
This is the packet dump from snmptrapd logfile:
================================================================================
Received 160 byte packet from UDP: [172.16.254.29]:161->[172.16.20.65]:162
0000: 30 81 9D 02 01 00 04 06 70 75 62 6C 69 63 A4 81 0.......public..
0016: 8F 06 06 2B 06 01 04 01 59 40 04 AC 10 FE 1D 02
...+....Y@<mailto:...+....Y@>......
0032: 01 06 02 02 00 97 43 03 45 40 BA 30 73 30 3C 06
......C.E@.0s0<<mailto:......C.E@.0s0%3c>.
0048: 0A 2B 06 01 04 01 59 02 03 01 00 04 2E 25 53 54 .+....Y......%ST
0064: 50 2D 57 2D 50 4F 52 54 53 54 41 54 55 53 3A 20 P-W-PORTSTATUS:
0080: 67 39 3A 20 53 54 50 20 73 74 61 74 75 73 20 46 g9: STP status F
0096: 6F 72 77 61 72 64 69 6E 67 0D 0A 30 0F 06 0A 2B orwarding..0...+
0112: 06 01 04 01 59 02 03 02 00 02 01 01 30 10 06 0B ....Y.......0...
0128: 2B 06 01 04 01 59 39 02 08 01 00 02 01 09 30 10 +....Y9.......0.
0144: 06 0B 2B 06 01 04 01 59 39 02 08 02 00 02 01 00 ..+....Y9.......
2013-05-28 10:37:47 172.16.254.29(via UDP:
[172.16.254.29]:161->[172.16.20.65]:162) TRAP, SNMP v1, community public
.1.3.6.1.4.1.89 Enterprise Specific Trap (151) Uptime:
12:36:25.54
.1.3.6.1.4.1.89.2.3.1.0 = STRING: "%STP-W-PORTSTATUS: g9: STP
status Forwarding
" .1.3.6.1.4.1.89.2.3.2.0 = INTEGER: 1
.1.3.6.1.4.1.89.57.2.8.1.0 = INTEGER: 9 .1.3.6.1.4.1.89.57.2.8.2.0 = INTEGER: 0
================================================================================
You can see the special characters 0D 0A (Carriage Return / Line Feed) at the
end of the string: "%STP-W-PORTSTATUS: g9: STP status Forwarding"
I suppose there is the problem.
Why DELL network devices put carriage returns and a line feed inside a trap?
This is a question like "Does the Tathagata (Buddha) exist after death?" and I
do not want investigate it now >:-(
I also configured snmptrapd to Display string values as Hex strings (snmptrapd
-Onx) and this works for SNMPTT,
but I tried only for diagnostic reasons, it can't be a solution because is
intelligible for human beings that cannot read hexadecimal notations :)
================================================================================
********** SNMPTT v1.3 started: Tue May 28 10:56:28 2013 **********
********** Net-SNMP version 5.0403 Perl module enabled **********
********** MIBS: ALL **********
Reading trap. Current time: Tue May 28 10:56:29 2013
Multi-line value detected - merging onto one line...
Raw trap passed from snmptrapd:
UDP: [172.16.254.29]:161->[172.16.20.65]:162
UDP: [172.16.254.29]:161->[172.16.20.65]:162
.1.3.6.1.2.1.1.3.0 0:12:55:06.02
.1.3.6.1.6.3.1.1.4.1.0 .1.3.6.1.4.1.89.0.151
.1.3.6.1.4.1.89.2.3.1.0 "25 53 54 50 2D 57 2D 50 4F 52 54 53 54 41 54 55
53 3A 20 67 39 3A 20 53 54 50 20 73 74 61 74 75
73 20 46 6F 72 77 61 72 64 69 6E 67 0D 0A "
.1.3.6.1.4.1.89.2.3.2.0 1
.1.3.6.1.4.1.89.57.2.8.1.0 9
.1.3.6.1.4.1.89.57.2.8.2.0 0
.1.3.6.1.6.3.18.1.3.0 172.16.254.29
.1.3.6.1.6.3.18.1.4.0 "70 75 62 6C 69 63 "
.1.3.6.1.6.3.1.1.4.3.0 .1.3.6.1.4.1.89
Items passed from snmptrapd:
value 0: UDP: [172.16.254.29]:161->[172.16.20.65]:162
value 1: 172.16.254.29
value 2: .1.3.6.1.2.1.1.3.0
value 3: 0:12:55:06.02
value 4: .1.3.6.1.6.3.1.1.4.1.0
value 5: .1.3.6.1.4.1.89.0.151
value 6: .1.3.6.1.4.1.89.2.3.1.0
value 7: 25 53 54 50 2D 57 2D 50 4F 52 54 53 54 41 54 55 53 3A 20 67 39 3A 20
53 54 50 20 73 74 61 74 75 73 20 46 6F 72 77 61 72 64 69 6E 67 0D 0A
value 8: .1.3.6.1.4.1.89.2.3.2.0
value 9: 1
value 10: .1.3.6.1.4.1.89.57.2.8.1.0
value 11: 9
value 12: .1.3.6.1.4.1.89.57.2.8.2.0
value 13: 0
value 14: .1.3.6.1.6.3.18.1.3.0
value 15: 172.16.254.29
value 16: .1.3.6.1.6.3.18.1.4.0
value 17: 70 75 62 6C 69 63
value 18: .1.3.6.1.6.3.1.1.4.3.0
value 19: .1.3.6.1.4.1.89
Agent IP address (172.16.254.29) is the same as the host IP, so copying the
host name: UDP: [172.16.254.29]:161->[172.16.20.65]:162
Trap received from UDP: [172.16.254.29]:161->[172.16.20.65]:162:
.1.3.6.1.4.1.89.0.151
0: hostname
1: ip address
2: uptime
3: trapname / OID
4: ip address from trap agent
5: trap community string
6: enterprise
7: securityEngineID (snmptthandler-embedded
required)
8: securityName (snmptthandler-embedded
required)
9: contextEngineID (snmptthandler-embedded
required)
10: contextName (snmptthandler-embedded
required)
0+: passed variables
Value 0: UDP: [172.16.254.29]:161->[172.16.20.65]:162
Value 1: 172.16.254.29
Value 2: 0:12:55:06.02
Value 3: .1.3.6.1.4.1.89.0.151
Value 4: 172.16.254.29
Value 5: 70 75 62 6C 69 63
Value 6: .1.3.6.1.4.1.89
Value 7:
Value 8:
Value 9:
Value 10:
Agent dns name: UDP: [172.16.254.29]:161->[172.16.20.65]:162
Ent Value 0 ($1): .1.3.6.1.4.1.89.2.3.1.0=25 53 54 50 2D 57 2D 50 4F 52 54 53
54 41 54 55 53 3A 20 67 39 3A 20 53 54 50 20 73 74 61 74 75 73 20 46 6F 72 77
61 72 64 69 6E 67 0D 0A
Ent Value 1 ($2): .1.3.6.1.4.1.89.2.3.2.0=1
Ent Value 2 ($3): .1.3.6.1.4.1.89.57.2.8.1.0=9
Ent Value 3 ($4): .1.3.6.1.4.1.89.57.2.8.2.0=0
================================================================================
So as you can see Hex strings variables are correctly handled.
I don't know if the problem is snmptrapd output (maybe it should remove cr/lf
special characters from strings, or smptt interpreter)
Thank you for your time, I wait you for a feedback :)
Best regards
Diego
------------------------------------------------------------------------------
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with <2% overhead
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap1
_______________________________________________
Net-snmp-users mailing list
Net-snmp-users@lists.sourceforge.net
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users
