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>