On Monday, September 04, 2017 13:22:16 Andrey V. Elsukov
wrote:> On 03.09.2017 09:20, Greg Rivers wrote:
> > Aside from ruling out the MTU option in the RAs as the cause, I've
> > made little progress on finding the problem.
> >
> > Can anyone explain the use of net.inet6.icmp6.nd6_debug=1 for NDP
> > debugging? I get no log output at all.
>
> I just tried:
> # sysctl net.inet6.icmp6.nd6_debug=1
> net.inet6.icmp6.nd6_debug: 0 -> 1
> # ifconfig lagg0 inet6 fe80::1/64
> # dmesg | tail
> lagg0: got interface identifier from itself
> lagg0: ifid: e6:a7:a0:ff:fe:8e:16:bf
> lagg0: starting DAD for fe80:4::e6a7:a0ff:fe8e:16bf
> lagg0: DAD complete for fe80:4::e6a7:a0ff:fe8e:16bf - no duplicates found
> lagg0: starting DAD for fe80:4::1
> lagg0: DAD detected duplicate IPv6 address fe80:4::1: NS
in/out/loopback=0/1/0, NA in=1
> lagg0: DAD complete for fe80:4::1 - duplicate found
> lagg0: manual intervention required
>
> As you can see, it works.
>
Thanks. Trying your same experiment, I do get output for duplicate detection,
though it doesn't include the interface identifier or a check for the auto
generated link-local address (maybe you're running -CURRENT?):
# ifconfig lagg0 inet6 fe80::8/64
# ifconfig lagg0 inet6 fe80::8/64 delete
# dmesg | tail -2
lagg0: starting DAD for fe80:c::8
lagg0: DAD complete for fe80:c::8 - no duplicates found
What puzzles me is that there are two Cisco routers on this network that each
send RAs every ~10 minutes, yet nothing is ever logged on the host, and the RAs,
which should trigger address auto-configuration, are completely ignored.
tcpdump on the host sees the RAs arriving on the lagg0 interface, yet nothing
ever happens. How can one troubleshoot an issue like this when the receipt
and/or disposition of RAs are not logged? Also strange is the fact that pinging
the source IP in the RAs (i.e. the router's link-local IP) fails without
ever placing a packet on the wire:
# tcpdump -e -tttt -i lagg0 ip6
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on lagg0, link-type EN10MB (Ethernet), capture size 262144 bytes
2017-09-04 13:48:10.663913 64:a0:e7:45:63:43 (oui Unknown) >
33:33:00:00:00:01 (oui Unknown), ethertype IPv6 (0x86dd), length 118:
fe80:XXXX:XXXX:4013:23::2 > ff02::1: ICMP6, router advertisement, length 64
$ ping6 fe80:XXXX:XXXX:4013:23::2%lagg0
ping6: UDP connect: Network is unreachable
How can it be that the host can receive a RA from a router's link-local
address, but otherwise thinks it's unreachable? No entries that contain
either the router's source IP or MAC address ever appear in the NDP table:
$ ndp -a
Neighbor Linklayer Address Netif Expire S Flags
fe80::ae16:2dff:fe1e:b880%lagg0 ac:16:2d:1e:b8:80 lagg0 permanent R
SLAAC works fine on my home network, which naturally has a FreeBSD router
running rtadvd(8). The only appreciable difference between the RAs sent by
FreeBSD and the RAs sent by Cisco are the "Traffic Class" and
"Differentiated Services Codepoint" in the IPv6 headers:
Cisco -Internet Protocol Version 6, Src: fe80:XXXX:XXXX:4013:23::2, Dst:
ff02::1
FreeBSD +Internet Protocol Version 6, Src: fe80::91:f7ff:fe8b:e900, Dst: ff02::1
@@ -27,2 +27,2 @@
- .... 1110 0000 .... .... .... .... .... = Traffic Class: 0xe0
(DSCP: CS7, ECN: Not-ECT)
- .... 1110 00.. .... .... .... .... .... = Differentiated
Services Codepoint: Class Selector 7 (56)
+ .... 0000 0000 .... .... .... .... .... = Traffic Class: 0x00
(DSCP: CS0, ECN: Not-ECT)
+ .... 0000 00.. .... .... .... .... .... = Differentiated
Services Codepoint: Default (0)
Could this be causing a problem?
--
Greg Rivers