Date: Tue, 05 Sep 2017 10:25:12 -0500 From: Greg Rivers <gcr+freebsd-stable@tharned.org> To: "Andrey V. Elsukov" <bu7cher@yandex.ru>, freebsd-stable@freebsd.org Subject: Re: SLAAC not working Message-ID: <1762879.zBQMMkUt4K@flake.tharned.org> In-Reply-To: <37bf1f27-0cdd-b5a9-7345-d16eb228c4cb@yandex.ru> References: <1646645.UkMcyRZBVl@flake.tharned.org> <16545541.lkKC6IFVDn@flake.tharned.org> <37bf1f27-0cdd-b5a9-7345-d16eb228c4cb@yandex.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tuesday, September 05, 2017 13:51:32 Andrey V. Elsukov wrote:
> You can try to use dtrace to detect that RA is received by IPv6 stack.
> # kldload dtraceall
> # dtrace -n 'fbt::nd6_ra_input:entry {m = (struct mbuf *)arg0; ip6 =
> (struct ip6_hdr *)m->m_data; printf("RA from %s received on %s",
> inet_ntoa6(&ip6->ip6_src), stringof(m->m_pkthdr.rcvif->if_xname));}'
>
> It should produce the output like this:
> dtrace: description 'fbt::nd6_ra_input:entry ' matched 1 probe
> CPU ID FUNCTION:NAME
> 2 37912 nd6_ra_input:entry RA from
> fe80:1::92e2:baff:fe6a:c7c received on ix0
> 2 37912 nd6_ra_input:entry RA from
> fe80:1::92e2:baff:fe6a:c7c received on ix0
>
Thank you Andrey! I started both dtrace and tcpdump, and then ran rtsol; here's the result:
# rtsol -dD lagg0
checking if lagg0 is ready...
lagg0 is ready
set timer for lagg0 to 0s
New timer is 0s
timer expiration on lagg0, state = 1
send RS on lagg0, whose state is 2
set timer for lagg0 to 4s
New timer is 4s
timer expiration on lagg0, state = 2
send RS on lagg0, whose state is 2
set timer for lagg0 to 4s
New timer is 4s
timer expiration on lagg0, state = 2
send RS on lagg0, whose state is 2
set timer for lagg0 to 1s
New timer is 1s
timer expiration on lagg0, state = 2
No answer after sending 3 RSs
stop timer for lagg0
there is no timer
# tcpdump -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-05 09:30:24.195501 IP6 fe80::ae16:2dff:fe1e:b880 > ff02::2: ICMP6, router solicitation, length 16
2017-09-05 09:30:24.195573 IP6 fe80::ae16:2dff:fe1e:b880 > ff02::2: ICMP6, router solicitation, length 16
2017-09-05 09:30:28.199198 IP6 fe80::ae16:2dff:fe1e:b880 > ff02::2: ICMP6, router solicitation, length 16
2017-09-05 09:30:28.199395 IP6 fe80::ae16:2dff:fe1e:b880 > ff02::2: ICMP6, router solicitation, length 16
2017-09-05 09:30:28.199724 IP6 fe80:XXXX:XXXX:4013:23::2 > fe80::ae16:2dff:fe1e:b880: ICMP6, router advertisement, length 64
2017-09-05 09:30:28.199729 IP6 fe80:XXXX:XXXX:4013:23::3 > fe80::ae16:2dff:fe1e:b880: ICMP6, router advertisement, length 64
2017-09-05 09:30:29.196133 IP6 fe80:XXXX:XXXX:4013:23::2 > fe80::ae16:2dff:fe1e:b880: ICMP6, neighbor solicitation, who has fe80::ae16:2dff:fe1e:b880, length 32
2017-09-05 09:30:29.196369 IP6 fe80:XXXX:XXXX:4013:23::3 > fe80::ae16:2dff:fe1e:b880: ICMP6, neighbor solicitation, who has fe80::ae16:2dff:fe1e:b880, length 32
2017-09-05 09:30:30.196234 IP6 fe80:XXXX:XXXX:4013:23::2 > fe80::ae16:2dff:fe1e:b880: ICMP6, neighbor solicitation, who has fe80::ae16:2dff:fe1e:b880, length 32
2017-09-05 09:30:30.196649 IP6 fe80:XXXX:XXXX:4013:23::3 > fe80::ae16:2dff:fe1e:b880: ICMP6, neighbor solicitation, who has fe80::ae16:2dff:fe1e:b880, length 32
2017-09-05 09:30:31.196341 IP6 fe80:XXXX:XXXX:4013:23::2 > fe80::ae16:2dff:fe1e:b880: ICMP6, neighbor solicitation, who has fe80::ae16:2dff:fe1e:b880, length 32
2017-09-05 09:30:31.196915 IP6 fe80:XXXX:XXXX:4013:23::3 > fe80::ae16:2dff:fe1e:b880: ICMP6, neighbor solicitation, who has fe80::ae16:2dff:fe1e:b880, length 32
2017-09-05 09:30:32.199683 IP6 fe80::ae16:2dff:fe1e:b880 > ff02::2: ICMP6, router solicitation, length 16
2017-09-05 09:30:32.199746 IP6 fe80::ae16:2dff:fe1e:b880 > ff02::2: ICMP6, router solicitation, length 16
2017-09-05 09:30:32.200289 IP6 fe80:XXXX:XXXX:4013:23::3 > fe80::ae16:2dff:fe1e:b880: ICMP6, router advertisement, length 64
2017-09-05 09:30:32.200597 IP6 fe80:XXXX:XXXX:4013:23::2 > fe80::ae16:2dff:fe1e:b880: ICMP6, router advertisement, length 64
2017-09-05 09:30:37.200331 IP6 fe80:XXXX:XXXX:4013:23::2 > fe80::ae16:2dff:fe1e:b880: ICMP6, neighbor solicitation, who has fe80::ae16:2dff:fe1e:b880, length 32
2017-09-05 09:30:37.212444 IP6 fe80:XXXX:XXXX:4013:23::3 > fe80::ae16:2dff:fe1e:b880: ICMP6, neighbor solicitation, who has fe80::ae16:2dff:fe1e:b880, length 32
2017-09-05 09:30:38.200407 IP6 fe80:XXXX:XXXX:4013:23::2 > fe80::ae16:2dff:fe1e:b880: ICMP6, neighbor solicitation, who has fe80::ae16:2dff:fe1e:b880, length 32
2017-09-05 09:30:38.212714 IP6 fe80:XXXX:XXXX:4013:23::3 > fe80::ae16:2dff:fe1e:b880: ICMP6, neighbor solicitation, who has fe80::ae16:2dff:fe1e:b880, length 32
2017-09-05 09:30:39.200517 IP6 fe80:XXXX:XXXX:4013:23::2 > fe80::ae16:2dff:fe1e:b880: ICMP6, neighbor solicitation, who has fe80::ae16:2dff:fe1e:b880, length 32
2017-09-05 09:30:39.213490 IP6 fe80:XXXX:XXXX:4013:23::3 > fe80::ae16:2dff:fe1e:b880: ICMP6, neighbor solicitation, who has fe80::ae16:2dff:fe1e:b880, length 32
^C
22 packets captured
38215 packets received by filter
0 packets dropped by kernel
# dtrace -n 'fbt::nd6_ra_input:entry {m = (struct mbuf *)arg0; ip6 = (struct ip6_hdr *)m->m_data; printf("RA from %s received on %s", inet_ntoa6(&ip6->ip6_src), stringof(m->m_pkthdr.rcvif->if_xname));}'
dtrace: description 'fbt::nd6_ra_input:entry ' matched 1 probe
^C
dtrace saw nothing, yet tcpdump recorded what one would expect. Apparently the inbound RAs and NSs are not making it through to the IPv6 stack. At this point I suspect a bug in the Emulex oce(4) driver, or a bad interaction between oce(4) and lagg(4). I have not seen this issue on hosts with lagg and other NICs. As soon as I can, I'm going to eliminate lagg and repeat the experiment while running on just one oce interface. I'll report back with results.
> > $ ping6 fe80:XXXX:XXXX:4013:23::2%lagg0
> > ping6: UDP connect: Network is unreachable
>
> Hmm. Can you show the second word of address in this example?
> Is it not zero? I.e. fe80:XXXX: is correct or you missed '::' part?
>
Correct, neither of the XXXX parts are zero; the :: part is at the end of the address: ...::2%lagg0. Sorry for the obfuscation, but policy at $WORK about company information on public lists is very strict.
--
Greg Rivers
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1762879.zBQMMkUt4K>