IPv6 and SNMP: Traps arrive, but not processed by snmptrapd

[gormank]

If snmptrapd doesn't process the traps, snmptt never gets anything related to them.
There's nothing related to the v6 traps in any of the snmptt logs.

[gormank]

Madness.
I took the sample from Net::SNMPTrapd and made a script. It also works on IPv4 and not IPv6.

Code: Select all

#!/usr/bin/perl

use strict;
use warnings;

use Net::SNMPTrapd;

my $snmptrapd = Net::SNMPTrapd->new(-Family=>6, -LocalAddr=>'[::1]', -LocalPort=>162)
#my $snmptrapd = Net::SNMPTrapd->new()
	or die "Error creating SNMPTrapd listener: \n", Net::SNMPTrapd->error;

while (1) {
	my $trap = $snmptrapd->get_trap();

	if (!defined($trap)) {
		printf "$0: %s\n", Net::SNMPTrapd->error;
		exit 1
	} 
	elsif ($trap == 0) {
		next
	}

	if (!defined($trap->process_trap())) {
		printf "$0: %s\n", Net::SNMPTrapd->error
	} 
	else {
		printf "%s\t%i\t%i\t%s\n", 
		$trap->remoteaddr, 
		$trap->remoteport, 
		$trap->version, 
		$trap->community
	}
}

[Box293]

It looks like we got the syntax right a while back and its listening, but not processing the traps...

# ps -ef | grep snmptrapd | grep -v grep
root 14576 1 0 20:35 ? 00:00:00 /usr/sbin/snmptrapd -a -A -Lf /var/log/snmtrapd.log -On -p /var/run/snmptrapd.pid udp:162,udp6:[::1]:162

# netstat -an | grep ":162 "
udp 0 0 0.0.0.0:162 0.0.0.0:*
udp 0 0 ::1:162 :::*

# tcpdump -i eth3 -s 0 port 162
tcpdump: WARNING: eth3: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth3, link-type EN10MB (Ethernet), capture size 65535 bytes

20:54:19.444292 IP6 2001:4888:a03c00:190.32861 > txslm2mlnag001v6.snmptrap: C=sp1der Trap(167) E:232 0.0.0.0 enterpriseSpecific s=11003 78131151 system.sysName.0="TXSLM2MCHP7004-OA" E:232.11.2.11.1=1 E:232.11.2.8.1="HP Onboard Administrator Test Trap sent from enclosure: TXSLM2MCHP7004"

# cat /var/log/snmtrapd.log
NET-SNMP version 5.5

This is great.

Now try this:

Code: Select all

service snmptt stop

Now send a test trap.

This should spool the file into /var/spool/snmptt/

Does a file exist there? If so can you post it please.

If not, can you post your /etc/snmp/snmptrapd.conf file please.

When you're finished don't forget to start the snmptt service.

[gormank]

The snmptrapd service sends traps to snmptt, not the other way around so the stop snmptt, etc. test isn't meaningful, but I'll play along...

# grep -v ^# /etc/snmp/snmptrapd.conf
disableAuthorization yes
traphandle default /usr/local/sbin/snmptthandler
ignoreauthfailure 1

# grep -v ^# /etc/sysconfig/snmptrapd
OPTIONS="-a -A -Lf /var/log/snmtrapd.log -On -p /var/run/snmptrapd.pid udp:162,udp6:[::1]:162"

# service snmptt stop
Stopping snmptt: [ OK ]

Trap sent...

# ll /var/spool/snmptt/
total 0

[Box293]

The snmptrapd service sends traps to snmptt, not the other way around so the stop snmptt, etc. test isn't meaningful, but I'll play along...

snmptrapd receives the trap and places it in a file in /var/spool/snmptt/
snmptt watches the directory /var/spool/snmptt/ and processes any traps files

So the purpose of getting you to stop snmptt was to see if snmptrapd was actually creating the trap file.

Because no file was created, snmptrapd is not accepting the trap and is dropping it.

Lets try running snmptrapd so it outputs to the console instead of running as a service.

Code: Select all

service snmptt stop
service snmptrapd stop
snmptrapd -D -f -Lo

Now snmptrap will dump debugging output on the screen.
Go and send the test trap.
Examine the output on the screen and see if you can trace what is going on. Upload it here please.

Press CTRL + C to kill snmptrapd

You might find this handy:
https://support.nagios.com/kb/article.p ... ategory=55

[gormank]

There is no output related to the test trap. See the attachment.
I've already attached tcpdump showing the traps arrive, so I have no trouble creating traps.

[tgriep]

In the Debug file, I saw an entry that was listening on IPv6 UDP but I didn't see anything about receiving a trap.
Try using just IPv6 only for your command, disabling IPv4 and see if that work.
The following says to listening on all IPv6 address UDP 162.

Code: Select all

udp6:162

[Box293]

If there is nothing about the trap you sent appearing in the output, but you are seeing the traffic arrive in a tcpdump, then this sounds like the local Operating System firewall rules preventing the traffic from reaching snmptrapd.

Also it would be good if you could repeat the last procedure as well as having a TCP dump running at the same time and then submit a test trap, it will help correlate what is going on.

Also, because this is tricky to troubleshoot, it might be worthwhile taking a step back from the actual device you're sending test traps from and use the snmptrap commands instead.

[gormank]

In the Debug file, I saw an entry that was listening on IPv6 UDP but I didn't see anything about receiving a trap.
Try using just IPv6 only for your command, disabling IPv4 and see if that work.
The following says to listening on all IPv6 address UDP 162.

Code: Select all

udp6:162

When udp over IPv4 is disabled, nothing gets past snmptrapd.

[gormank]

You may be onto something with the firewall bit... I'll dig into that tomorow.

Thanks!

Code: Select all

# service ip6tables status
Table: filter
Chain INPUT (policy ACCEPT)
num  target     prot opt source               destination
1    ACCEPT     all      ::/0                 ::/0                state RELATED,ESTABLISHED
2    ACCEPT     icmpv6    ::/0                 ::/0
3    ACCEPT     all      ::/0                 ::/0
4    ACCEPT     udp      ::/0                 fe80::/64           state NEW udp dpt:546
5    ACCEPT     tcp      ::/0                 ::/0                state NEW tcp dpt:22
6    REJECT     all      ::/0                 ::/0                reject-with icmp6-adm-prohibited

Chain FORWARD (policy ACCEPT)
num  target     prot opt source               destination
1    REJECT     all      ::/0                 ::/0                reject-with icmp6-adm-prohibited

Chain OUTPUT (policy ACCEPT)
num  target     prot opt source               destination