Nagios Support Forum

Hello,

I have a Quantum i6000 tape library that I'm trying to configuring NagiosXI to receives TRAPS from it. The traps are getting registered in the /var/log/messages so I know the snmptrapd is receiving them but nagios isn't doing anything with them. Does anyone know how to take output from the /var/log/snmptt/snmpttunknown.log file (seen here) and convert the information into a useable format for the /etc/snmp/snmptt.conf file? I have not been able to find a predefined set of MIB files that "addmib" can import.

Mon Sep 30 16:42:23 2013: Unknown trap (.1.3.6.1.4.1.3764.1.1.200.20.0.103) received from i6000_tapelibrary at:
Value 0: i6000_tapelibrary
Value 1: 10.1.1.140
Value 2: 103:19:33:12.64
Value 3: .1.3.6.1.4.1.3764.1.1.200.20.0.103
Value 4: 10.1.1.140
Value 5: public
Value 6: .1.3.6.1.4.1.3764.1.1.200.20
Value 7:
Value 8:
Value 9:
Value 10:
Ent Value 0: .1.3.6.1.4.1.3764.1.1.30.10.1.1=00 00 00 00 00 05 00 17
Ent Value 1: .1.3.6.1.4.1.3764.1.1.500.10.1.1=104373
Ent Value 2: .1.3.6.1.4.1.3764.1.1.500.10.1.2=5
Ent Value 3: .1.3.6.1.4.1.3764.1.1.500.10.1.3=I/E Door Status
Ent Value 4: .1.3.6.1.4.1.3764.1.1.200.20.80.55.1.1=0
Ent Value 5: .1.3.6.1.4.1.3764.1.1.200.20.80.55.1.2=0
Ent Value 6: .1.3.6.1.4.1.3764.1.1.200.20.80.55.1.3=0
Ent Value 7: .1.3.6.1.4.1.3764.1.1.200.20.80.75.1.1=0
Ent Value 8: .1.3.6.1.4.1.3764.1.1.200.20.80.75.1.2=4

So just to clarify, have you followed the integrating snmptraps with XI documentation? Otherwise, this is something I am working on, as well as being planned for the new release of NSTI, regarding a good way to create snmptt.conf entries for oids that are not defined by the vendor. I can point you towards a few articles, if you would like.

I do have needed option installed in my OS. The traps do come into the /var/log/messages so I know its listening on port 162 and snmptrapd is receiving the traps. The problems is I don't have a compatible MIB file from the vendor that is recognized with the command "addmib". When I run that command and specify the MIB files I do have, nothing gets added to the /etc/snmp/snmptt.conf file.

If you do have some other links or ideas that will help write some entries into my /etc/snmp/snmptt.conf file based on the output from my /var/log/snmptt/snmpttunknown.log that would be great.

This does specifically related to windows oids for various event driven traps it can send. It should give you a pretty good idea at least where to start though. If you want to post a trap or two that you are presently getting also, I will try and help with creating a correct entry for it.

http://www.networkcircus.com/articles/20050715.html

The easiest way to get the right translation is by installing NSTI on the system. It will give you the right information (like the hostname or ip it comes in as). You need the oid that shows up in NSTI. Once you get that oid, you can add it to the /etc/snmp/snmptt.conf file. Even though you think you might have the right OID in the logs, it doesn't always match up what it is expecting, which is why I like NSTI.

Here is an example entry:
EVENT newRoot .1.3.6.1.2.1.17.0.1 "Status Events" Normal <-- You would modify the OID to match the oid you are getting in
FORMAT The newRoot trap indicates that the sending agent has $*
EXEC /usr/local/bin/snmptraphandling.py "$r" "SNMP Traps" "$s" "$@" "$-*" "The newRoot trap indicates that the sending agent has $*" <-- depending on what you're doing, you can either remove this line, or change it out
SDESC
The newRoot trap indicates that the sending agent has
become the new root of the Spanning Tree; the trap is
sent by a bridge soon after its election as the new
root, e.g., upon expiration of the Topology Change Timer,
immediately subsequent to its election. Implementation
of this trap is optional.
Variables:
EDESC
#
#
#

Easiest, would not likely be the term I would use for nsti at this point. The new version however is becoming vastly superior. In a large sense, we are really talking about the same case, of creating\altering the interpretation of the trap and deciding how to display it.

Yeah, I was pointing out the way I've gotten it to work for other companies in a less painful manner. I've found that, because NSTI is GUI based, it gets people up and running quickly, but it still takes time due to the fact it is SNMP (about 3 hours to get it even with NSTI) . I agree with you that there are other articles out there to help and probably better ways as well.

Thanks for stepping in with suggestions niebais!