SNMP trap config

[gormank]

The service was restarted Oct 5 17:36:59, so searching for 17:36:59 and noting the date will take you right to it.

One thing that makes me nervous about SNMP is messages like this:
Health Status Array Change occurred (11020): A change in the health status of the server has occurred, the status is now 02 02 02 02 02 02 02 02 02 02 00 02 00 00 01 02 02 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 / sysName.0 (OCTETSTR):txslm2mltbc00

It tells me nothing about the actual problem. Is the message an indication that a MIB file is missing? I have numerous HP MIBs installed and regenerated the snmptt.conf last week with no change.

thanks

[gormank]

Hmm, I stumbled upon this: https://support.nagios.com/forum/viewto ... =16&t=9295
Seems to mirror my issue with snmptt. It seems running reconfig stalls snmptt. Has this been fixed?

Is there a way to filter traps? It seems HP devices send a certain trap that's bogus and the fix is to tell SIM to ignore it. I also see tons of authentication failure traps. For alerting, a new trap takes the place of the previous trap, so traps are getting lost. This is a very bad thing. I have to monitor one of the log files to see if our 3pars are getting full.

[tgriep]

I think this is the fix you are looking for.
Make a backup of this file

Code: Select all

/usr/local/bin/snmptraphandling.py

Replace it with the copy that is attached to this post and let us know if it works for you.

[jdalrymple]

gormank,

I dug into the ticket referenced in the forum thread you mentioned. The user ended up adding an smptt restart command to the nagios start portion of the /etc/init.d/nagios file:

Here is an easier way.

Edit
/etc/init.d/nagios

line 147-148 should be

echo " done."
exit 0

CHANGE TO

echo " done."
/etc/init.d/snmptt restart
exit 0


Save

This will restart snmptt every time nagios starts (including restarts)

[gormank]

Yes, I read the post as well and see what was done. Why is this still an issue after being discovered years ago? I checked the file on my machines and the one attached above is the same:

# grep snmptt /usr/local/bin/snmptraphandling.py
# diff /tmp/snmptraphandling.py /usr/local/bin/snmptraphandling.py
#

I'll update the init script...

Still hoping for answers/comments about the trap in my post with the log file attached, and the one after about filtering traps.

[ssax]

From reading this post:

http://h30507.www3.hp.com/t5/Coffee-Coa ... 29007#M431

I don't believe it will get converted, you may however be able to use the MATCH or REGEX statement to create a new trap that would tell you what it is.

For filtering you can use MATCH or REGEX to filter out what you don't want for each trap:

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

[gormank]

The link to the info on the health status trap was great. I'm still trying to grok what the 2nd 16 element array is.

I commented the EXEC line for the 2 login failure traps I was getting and that seems to have stopped them. That was so simple it took me a while to figure out.

I thought that 1.3.6.1.4.1.232.0.11020 in the following trap was the OID and that I should be able to do an snmpget on it to pull the same data, but I get an error.

Oct 9 15:50:42 cocsm2mlnag001 snmptt[502]: .1.3.6.1.4.1.232.0.11020 INFORMATIONAL "Status Events" 10.136.243.149 - Health Status Array Change occurred (11020): A change in the health status of the server has occurred, the status is now 02 02 02 02 02 02 01 02 02 02 02 02 02 02 02 02 02 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00

]# snmpget -Os -t 1 -v1 -c read 10.136.243.149 1.3.6.1.4.1.232.0.11020
Error in packet
Reason: (noSuchName) There is no such variable name in this MIB.
Failed object: enterprises.232.0.11020

[tgriep]

If the system you are trying to run the snmpget configured for SNMP version 1?
You may want to change that to version 2 in this option and also remove the 1 second timeout.
Try running this to see if it works for you.

Code: Select all

snmpget -Os -v 2c -c read 10.136.243.149 1.3.6.1.4.1.232.0.11020

[gormank]

Sorry, I was experimenting and pasted the wrong thing. Version 2 is in use.

# snmpget -v 2c -c read 10.136.243.149 1.3.6.1.4.1.232.0.11020
SNMPv2-SMI::enterprises.232.0.11020 = No Such Object available on this agent at this OID

[root@cocsm2mlnag001 hosts]# snmpwalk -c read -v 2c 10.136.243.149 | grep 11020 | wc -l
0
[root@cocsm2mlnag001 hosts]# snmpwalk -c read -v 2c 10.136.243.149 | grep SNMPv2-SMI | wc -l
170

[tgriep]

It looks like that OID "1.3.6.1.4.1.232.0.11020" isn't valid and I couldn't find it online anywhere.
Do you have the MIB file for that OID and can you post it here so we can review it?