XI Traps ending up in snmpttunknown.log

[lapperb]

We have installed and configured the Nagios XI trial to see if it will meet our needs and have run into a road block. I am attempting to capture SNMP traps from our Cisco UCS 200 machines, but Nagios does not seem to be able to translate them. I uploaded the Cisco UCS 200 MIB files. I am also seeing the SNMP traps on the Nagios XI server in the /var/log/snmptt/snmpttunknown.log. Can you suggest what we might be doing wrong?

Just for your reference, we are sending a test power supply failure trap from the UCS machine. (OID: .1.3.6.1.4.1.3183.1.1.0.527105).

Thanks,
Brian

[scottwilkerson]

If they are in the /var/log/snmptt/snmpttunknown.log it is likely that the MIBs for the device haven't been uploaded or you did not run

Code: Select all

addmib /path/to/MIB

See Installing MIBs section Page 2
http://assets.nagios.com/downloads/nagi ... ith_XI.pdf

[lapperb]

The OID I am receiving does not appear in the Cisco UCS MIBs for our machine. However, I did find the OID in a PET-EVENTS_MIB.txt MIB file which describes exactly the event I am generating, a power supply insert. I installed uploaded this MIB to Nagios and ran "addmib ./PET-EVENTS_MIB.txt". Still, my SNMP trap ends up in the snmpttunknown.log file.

[lapperb]

I found the OID I am receiving in a PET-EVENTS_MIB.txt file which describes the event I am generating, a power supply insertion. I uploaded the MIB file and ran the "addmib PET-EVENTS_MIB.txt" command, but the trap is still ending up in the snmpttunknown.log file.

[scottwilkerson]

you should use the full path

Code: Select all

addmib /usr/share/snmp/mibs/PET-EVENTS_MIB.txt

[lapperb]

I executed addmib with the full path to the MIB files this time. Same result. The trap gets logged in the snmpttunknown.log file.

[scottwilkerson]

You will also need to restart snmptt

Code: Select all

service snmptt restart

If you still have the same results can you send the info logged in snmpttunknown.log

[lapperb]

Ok, now we're getting somewhere. My trap now shows up in the snmptt.log. I initially thought the service status screen was not reflecting the trap, but I notice the trap status says "OK: trap reset". Does that mean the event was brief and was immediately reset?

[scottwilkerson]

Does that mean the event was brief and was immediately reset?

yes. the last trap received is shown.

You should be able to see the changes in the state history report

[lapperb]

Thanks! You've been very helpful.