From owner-freebsd-stable@freebsd.org Mon Sep 4 21:20:13 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 25979E1F04D for ; Mon, 4 Sep 2017 21:20:13 +0000 (UTC) (envelope-from gcr+freebsd-stable@tharned.org) Received: from roadkill.tharned.org (gcrivers-1-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:107f::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E91162FE0 for ; Mon, 4 Sep 2017 21:20:12 +0000 (UTC) (envelope-from gcr+freebsd-stable@tharned.org) Received: from flake.tharned.org ([IPv6:2001:470:1f11:107f:c8de:be:be6f:9cb4]) (authenticated bits=0) by roadkill.tharned.org (8.15.2/8.15.2) with ESMTPSA id v84LK51x084523 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 Sep 2017 16:20:11 -0500 (CDT) (envelope-from gcr+freebsd-stable@tharned.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tharned.org; s=2017; t=1504560011; bh=UO+EeLltu+9KiZQzltBqALtHU7nYfiveXrM6XxbVn4k=; l=3791; h=From:To:Subject:Date:In-Reply-To:References; b=v8ESRNipbrbWxkQ+oKTAOWsLaqH1p3mYLz2R1K+dDtPsjKuFyFHx0rWsDYeo+SWhE pJbt80AUrKPD9B8VnEzuwFG4RCTScfYvUMPmKArF1ZEv3ZoJdj5WKhOb4JPhjLXOfF XPCeaLkoncply0HGw9cPK9QvVoQ8tdu6V4RLMjOOsey9ix/grQG3750VJown9fjMcV eN+pSXEm1uYdV7xsfXcHEbl9YSKLp4xhIK/FPRnlfke3eQMCPNU2bLaFh9KEsrA43k n7YooSPoMUOiJlEGl4Kg4e+72fjNlNs0Ycip/CKyBCMJosYdBxltJG8hkzUkSXTL7C huulwdp0T5Kcg== X-Authentication-Warning: roadkill.tharned.org: Host [IPv6:2001:470:1f11:107f:c8de:be:be6f:9cb4] claimed to be flake.tharned.org From: Greg Rivers To: "Andrey V. Elsukov" , freebsd-stable@freebsd.org Subject: Re: SLAAC not working Date: Mon, 04 Sep 2017 16:20:05 -0500 Message-ID: <16545541.lkKC6IFVDn@flake.tharned.org> User-Agent: KMail/4.14.10 (FreeBSD/11.1-RELEASE-p1; KDE/4.14.30; amd64; ; ) In-Reply-To: References: <1646645.UkMcyRZBVl@flake.tharned.org> <3078071.oYt2PD7K2Q@flake.tharned.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (roadkill.tharned.org [IPv6:2001:470:1f10:107f:0:0:0:2]); Mon, 04 Sep 2017 16:20:11 -0500 (CDT) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Sep 2017 21:20:13 -0000 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