Configuring SNMP traps

[jonathan kax]

Hi all,

I've setup a Nagios XI 2012R2.2 trial on a newly installed CentOS 6.4 box. Now I'm trying to configure SNMP and SNMP Traps monitoring.

I've followed the instructions found here: http://assets.nagios.com/downloads/nagi ... ith_XI.pdf.

Everytime I send a trap from my device, the message "Cannot find TrapOID in TRAP2 PDU" is logged in /var/log/messages.

There's also a lot of messages saying:

localhost snmptt[0]: .1.3.6.1.6.3.1.1.5.5 Normal "Status Events" <ip address of device> - An authenticationFailure trap signifies that the SNMP

Have I missed something in the configuration?

Best regards,

Jonathan

[sreinhardt]

What sort of device are you sending traps from? Have you added the mibs from the manufacturer of that device onto the nagios box? It sounds like you've got them comming in great, but it doesn't understand the traps as it doesn't have mibs to work with.

[jonathan kax]

It's a Crestron processor (a programmable processor for automation).

Yes, I've added the mibs through the "Admin->Manage MIBs" page.

[sreinhardt]

OK a couple other things you will need to do and be sure of.

1) once added via the webui, you need to run "addmib /path/to/mib-file" on each one. The trick is if there are multiple you need to do the primary ones first so that ones that have them listed as dependencies will correctly see the deps already listed. After all are added restart all snmp services (snmpd, snmptt, snmptrapd)

2) Look in /var/log/snmpttunknown.log if you have traps correctly comming into the nagios server, but they are not being recognised they will show here. If you see the /var/log/snmptt.log file filling up then your system is recognizing them correctly, this is good!

3) If you are seeing them correctly in snmptt.log and are not seeing them show in nagios alerts, you need to verify that the hostname sent by snmptt handler is using the same hostname as the associated nagios config. Look in the snmptt.log file for lines starting with EXEC, directly after the .py file should be the hostname or IP. This must exactly, case and everything, match the hostname listed for the host that has the trap service in nagios.

Let me know which step you are currently stuck on and we can work from there!

[jonathan kax]

I ran addmib on each file in the correct order.

After this I got an error message when restarting the snmptt service stating:

"Bad parse of OBJECT IDENTIFIER: At line 37 in /usr/share/snmp/mibs/CRESTRON-SYSMON-MIB.my".

Line 37 in this mib file contains "iso OBJECT IDENTIFIER ::= { 1 }".

No traps are logged in snmpttunkown.log.

I connected a second unit, and from this one I actually receive traps. So I looked closer at the message details and found that the working unit is sending messages that contains sysUpTime.0 and snmpTrapOID.0 while the non-working unit's messages contains sysUpTime.0 and snmpTrapOID.1. Can this be the reason why it's not working? If so, is there any configuration I can do in order to get both units working?

Best regards,

Jonathan

[sreinhardt]

If you look at the mibs added, or post them here, is snmpTrapOID.1 included, or just .0? That would likely be our big difference. Otherwise are you seeing the .1 traps coming into the standard snmptt.log file? If so we should look at either the names that the trap is sending vs how it is set in nagios as they must be the same.

[rodpayne]

This must exactly, case and everything, match the hostname listed for the host that has the trap service in nagios.

I had this same problem. Nothing was posting to the Nagios service because I had entered the host names in uppercase. For Windows at least, it seems like it always gets processed as lowercase (as seen in the snmptt.log).

Is there any way to tell it to match using the IP address, rather than the name? Or, could /usr/local/nagios/var/rw/nagios.cmd be enhanced to be case insensitive? Does everyone else who uses this use host names in lowercase?

In any case, this would be good information to have in the Integrating_SNMP_Traps_With_Nagios_XI document after troubleshooting to the point where entries are appearing in /var/log/snmptt/snmptt.log rather than /var/log/snmptt/snmpttunknown.log.

[sreinhardt]

There is a way to not resolve dns, however what it gets matched to is actually more dependent on what the trap sends in its contents than where it comes from on the network. That cmd file is simply a pipe into the nagios process to feed information, it is not similar to a windows batch script. At this point we do not wish to make host names case independent, but you could submit as a bug\feature request.

I can see the point of adding in that correctly configured traps will send there, although I thought there was something about that. You might also find the unconfigured objects list in XI to be a useful tool to find issues like this.

[rodpayne]

I have come up with a solution for resolving this problem (host name definitions must exactly match the case that comes from SNMP traps). Rather than asking for an enhancement (to Nagios Core) that would make the external command processing of a host name be case-insentive, I have updated the snmptraphandling.py script to correct the case before posting to nagios.cmd. It does this by looking up the host name in the ndoutils database and using the correctly-cased host name that is returned. Works every time.

I have seen this case-matching problem posted several times, so if anyone else is interested:

Code: Select all

--- snmptraphandling.py-orig	2012-11-01 17:02:44.000000000 -0400
+++ snmptraphandling.py	2014-01-02 22:01:04.293053708 -0500
@@ -5,6 +5,8 @@
 First release 2004/09/15
 Modified by Nagios Enterprises, LLC.
 
+Modified by Rod Payne - Kaleida Health - 11Nov2013 - 27Dec2013
+
 This script receives input from sec.pl concerning translated snmptraps
 
 *** Important note: sec must send DATA within quotes
@@ -15,6 +17,10 @@
 
 import sys
 
+#--------------------------------------------------------------------------------
+import MySQLdb			# yum install MySQL-python
+dbpwd = "xxxxxx"		# see html/config.inc.php
+#--------------------------------------------------------------------------------
 
 def printusage():
     print "usage: services.py <HOST> <SERVICE> <SEVERITY> <TIME> <PERFDATA> <DATA>"
@@ -68,6 +74,24 @@
 
 def post_results(host, service, mytime, mondata_res, return_code):
     output = open('/usr/local/nagios/var/rw/nagios.cmd', 'w')
+#------------post-iLo-traps-to-server-name---------------------------------------
+#   if host[-3:].upper() == "RIB":	# Direct RIB...
+#       host = host[:-3]		#   to its server.
+#------------change-server-name-to-correct-case----------------------------------
+    sql = "SELECT display_name FROM nagios_hosts WHERE display_name='%s'" % host
+    try:
+        db = MySQLdb.connect("localhost","ndoutils",dbpwd,"nagios")
+        cursor = db.cursor()
+        cursor.execute(sql)
+        result = cursor.fetchone()
+        if cursor.rowcount != 1:
+            print "Warning: unable to retrieve host name %s from nagios database" % host
+        else:
+            host = result[0]
+        db.close()
+    except:
+        print "Error: unable to retrieve host name %s from nagios database" % host
+#--------------------------------------------------------------------------------
     results = "[" + mytime + "] " + "PROCESS_SERVICE_CHECK_RESULT;" \
         + host + ";" + service + ";" \
         + return_code + ";" + mondata_res + "\n"

[tmcdonald]

I usually don't like seeing 6 month old threads brought back, but this is very much an exception! Thanks for the patch.