Page 1 of 1

SNMP Traps don't work

Posted: Thu Nov 26, 2020 10:31 am
by gpanou
tcpdump port 162 -i any :

Code: Select all

17:09:02.503370 IP ****.51684 > *****.*******.gr.snmptrap:  C=****** Trap(51)  E:cisco.9.220 ******* enterpriseSpecific s=1 745715785 .iso.0.8802.1.1.1.1.2.1.1.1.10035=4
We tried both a wildcard and a regular oid trap definition:
.iso.0.8802.1.1.1.1.2.1.1.*
.iso.0.8802.1.*

The status reported is "waiting for trap...."

The send test trap from the advanced tab does not work either - we have defined the test trap.

The snmptt log:

Code: Select all

Thu Nov 26 16:56:43 2020 .1.3.6.1.6.3.1.1.5.3 Normal "Status Events" UNKNOWN - Link down on interface 10144.  Admin state: GigabitEthernet1/0/44.  Operational state: ethernetCsmacd
Thu Nov 26 16:57:14 2020 .1.3.6.1.6.3.1.1.5.4 Normal "Status Events" UNKNOWN - Link up on interface 10144.  Admin state: GigabitEthernet1/0/44.  Operational state: ethernetCsmacd
Thu Nov 26 17:05:20 2020 .1.3.6.1.6.3.1.1.5.3 Normal "Status Events" UNKNOWN - Link down on interface 10037.  Admin state: FastEthernet0/37.  Operational state: ethernetCsmacd
Thu Nov 26 17:05:25 2020 .1.3.6.1.6.3.1.1.5.4 Normal "Status Events" UNKNOWN - Link up on interface 10037.  Admin state: FastEthernet0/37.  Operational state: ethernetCsmacd
Thu Nov 26 17:05:37 2020 .1.3.6.1.6.3.1.1.5.3 Normal "Status Events" UNKNOWN - Link down on interface 10037.  Admin state: FastEthernet0/37.  Operational state: ethernetCsmacd
Thu Nov 26 17:05:39 2020 .1.3.6.1.6.3.1.1.5.4 Normal "Status Events" UNKNOWN - Link up on interface 10037.  Admin state: FastEthernet0/37.  Operational state: ethernetCsmacd
We have setup the /etc/snmp/snmptrapd.conf with or without authenticaton for v.2c

Any help will be appreciated

Re: SNMP Traps don't work

Posted: Tue Dec 01, 2020 12:15 pm
by cdienger
Is there a snmpttunknown log under /var/log/snmptt ?

Are you able to generate the snmptrap captured in the tcpdump at will? If so, I'd like to take a closer look at it by capturing it in a file:

Code: Select all

tcpdump -s 0 -i any port 162 -w output.pcap
Let the above run just long enough to capture the trap coming in and then use CTRL+C to stop it. Send me the output.pcap file in a private message along with the IP address of the device that sent it. If you used snmptrap to generate the trap, please provide the full command.

Re: SNMP Traps don't work

Posted: Fri Dec 18, 2020 4:06 am
by gpanou
Hello,

I sent the pcap file as requested. The traffic was generated manually by turning up/down a cisco interface on a switch. Could be some other random traffic in there though.

Re: SNMP Traps don't work

Posted: Fri Dec 18, 2020 2:52 pm
by cdienger
The capture didn't make it through. Please try sending it again.

Re: SNMP Traps don't work

Posted: Mon Dec 28, 2020 5:33 pm
by gpanou
I have resent it, is it ok now?

Re: SNMP Traps don't work

Posted: Tue Dec 29, 2020 3:19 pm
by cdienger
I responded via a private message last week. Did you get it? I've pasted it below removing the sending IP.
Is *.*.*.120 the IP of the device you were testing with? I don't see the OIDs you mentioned in the forum thread, but I do see *.*.*.120 sending traps to OID 1.3.6.1.6.3.1.1.5 which is typically used to send up and down notifications for an interface. A definition should be created in XI to direct trap OID 1.3.6.1.6.3.1.1.5 to the XI service.

Re: SNMP Traps don't work

Posted: Wed Dec 30, 2020 5:49 am
by gpanou
Oh did not notice that, there was no unread message alert in my dashboard.

We have setup a "generic" OID definition: at OID 1.3.6

Should we be expecting Nagios to display those? How should we proceed to define trap checks, one for each expected OID?
Because this would be quite counter productive.

Thank you

Re: SNMP Traps don't work

Posted: Wed Dec 30, 2020 3:49 pm
by cdienger
Generally you'll want to create service/trap definition in XI for each OID. For example, one may be a trap for disk space and another can be fore cpu usage. It may take some time to set up depending on the number of traps you want to monitor , but if you set up a generic trap/service to collect all traps(which is possible using a wildcard in the definition - for example 1.3.6.*) and associate that with one service you'll find that the service only shows the last trap that was received. This may not be a concern though if you just care about getting a notification for each non-OK state(see volatility in https://assets.nagios.com/downloads/nag ... ios-XI.pdf).