From owner-freebsd-net@freebsd.org Sat Jan 13 22:49:34 2018 Return-Path: Delivered-To: freebsd-net@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 75B20EB424F for ; Sat, 13 Jan 2018 22:49:34 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from gilb.zs64.net (gilb.zs64.net [IPv6:2a00:14b0:4200:32e0::1ea]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gilb.zs64.net", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 299AE7C1EC for ; Sat, 13 Jan 2018 22:49:34 +0000 (UTC) (envelope-from stb@lassitu.de) Received: by gilb.zs64.net (Postfix, from stb@lassitu.de) id B738A1974CB; Sat, 13 Jan 2018 22:49:32 +0000 (UTC) From: Stefan Bethke Message-Id: <8AD8F511-9BA7-4A51-9F30-483432F605AA@lassitu.de> Content-Type: multipart/signed; boundary="Apple-Mail=_9F391E84-9692-4450-ABAC-E3BD74BAF297"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Subject: Re: IPv6 NDP triggering QuaggaLinux problem? Date: Sat, 13 Jan 2018 23:49:31 +0100 In-Reply-To: <2D00C83A-5A25-4A69-9D31-BD1E9F61BD49@lassitu.de> Cc: Thomas Wieske , Andreas Sons To: freebsd-net@freebsd.org References: <2D00C83A-5A25-4A69-9D31-BD1E9F61BD49@lassitu.de> X-Mailer: Apple Mail (2.3445.5.20) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jan 2018 22:49:34 -0000 --Apple-Mail=_9F391E84-9692-4450-ABAC-E3BD74BAF297 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Am 13.01.2018 um 23:06 schrieb Stefan Bethke : >=20 > Hey guys, >=20 > I=E2=80=99m a bit stumped and are hoping for some helpful pointers. >=20 > I have two machines both running a recent 11-stable (SuperMicro = X11SSH-F with a E3-1240v6); each one is connected to one Ethernet switch = through igb0, and back-to-back connected to the other box through igb1. = igb1 only has IPv4 RFC 1918 addresses configured. >=20 > To make it easier to give bhyve VMs a public IP, igb0 is added as a = member to brigde0, and all addresses are configured on bridge0. The = hosts run a small number of jails with addresses on bridge0 as well. >=20 > Whenever IPv6 is active on bridge0, my ISPs router (which is some = version of Quagga running on Linux) keeps filling up it=E2=80=99s = routing table within minutes; then traffic stops, the routing table is = cleared and the normal set of entries is installed, and traffic resumes. = This pattern then repeats. The router apparent has has full table with = ~46000 routes normally, but within minutes, the Linux kernel routing = table gets filled up with multiple copies of that. I believe that is is = likely a problem with Quagga on Linux, and ultimately has to be resolved = there, but the question lingers what my two systems could be sending = that could trigger this. >=20 > The ISP and I have looked at NDP config, tcpdumps of NDP, and general = IPv6 config, but we cannot identify why Quagga or the Linux kernel would = behave that way. Other FreeBSD boxes connected to the same router (but = different IPv6 /64s) do not trigger this behaviour. >=20 > My systems are not really loaded, and traffic is light. One box gets = about 50 packet/s, the other about 400 (this one is in the NTP pool, and = running a DNS server). >=20 > I=E2=80=99ve tried switching off NUD, but that doesn=E2=80=99t change = the behaviour of the Quagga system. >=20 > Here=E2=80=99s some output of the current configuration: > # ifconfig igb0; ifconfig bridge0 > igb0: flags=3D8943 = metric 0 mtu 1500 > = options=3D6403bb > ether ac:1f:6b:18:xx:6e > hwaddr ac:1f:6b:18:xx:6e > inet6 fe80::ae1f:6bff:fexx:66e%igb0 prefixlen 64 tentative = scopeid 0x1 > nd6 options=3D8 > media: Ethernet autoselect (1000baseT ) > status: active > bridge0: flags=3D8843 metric 0 = mtu 1500 > description: vm-bridge0 > ether 02:3c:9f:37:xx:00 > inet 212.12.xx.225 netmask 0xffffffe0 broadcast 212.12.xx.255 > inet 212.12.xx.226 netmask 0xffffffff broadcast 212.12.xx.226 > inet 212.12.xx.253 netmask 0xffffffff broadcast 212.12.xx.253 > inet 212.12.xx.229 netmask 0xffffffff broadcast 212.12.xx.229 > inet6 fe80::3c:9fff:fe37:xx00%bridge0 prefixlen 64 scopeid 0x7 > inet6 2a00:14b0:4200:32xx::1e1 prefixlen 64 > inet6 2a00:14b0:4200:32xx::1e2 prefixlen 128 > inet6 2a00:14b0:4200:32xx::1fd prefixlen 128 > inet6 2a00:14b0:4200:32xx::1e5 prefixlen 128 > nd6 options=3D8020 > groups: bridge > id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 > maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200 > root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 > member: igb0 flags=3D143 > ifmaxaddr 0 port 1 priority 128 path cost 2000000 > # ndp -an > Neighbor Linklayer Address Netif Expire = S Flags > 2a00:14b0:4200:32xx::1e1 02:3c:9f:37:xx:00 bridge0 = permanent R > 2a00:14b0:4200:32xx::1 00:50:56:a1:xx:b5 bridge0 = 23h59m58s S R > 2a00:14b0:4200:32xx::1e2 02:3c:9f:37:xx:00 bridge0 = permanent R > 2a00:14b0:4200:32xx::1e5 02:3c:9f:37:xx:00 bridge0 = permanent R > 2a00:14b0:4200:32xx::1e7 02:5a:1d:92:xx:00 bridge0 = 23h59m16s S > 2a00:14b0:4200:32xx::1e8 02:5a:1d:92:xx:00 bridge0 = 23h59m2s S > 2a00:14b0:4200:32xx::1eb 02:5a:1d:92:xx:00 bridge0 = 23h55m7s S > 2a00:14b0:4200:32xx::1ea 02:5a:1d:92:xx:00 bridge0 = 23h2m24s S > fe80::3c:9fff:fe37:2500%bridge0 02:3c:9f:37:xx:00 bridge0 = permanent R > fe80::250:56ff:fea1:dfb5%bridge0 00:50:56:a1:xx:b5 bridge0 = 23h59m57s S R > 2a00:14b0:4200:32e0::1fd 02:3c:9f:37:xx:00 bridge0 = permanent R > fe80::ae1f:6bff:fe18:xx6f%igb1 ac:1f:6b:18:xx:6f igb1 = permanent R > fe80::ae1f:6bff:fe18:xx6e%igb0 ac:1f:6b:18:xx:6e igb0 = permanent R > # ndp -i bridge0 > linkmtu=3D0, maxmtu=3D0, curhlim=3D64, basereachable=3D30s0ms, = reachable=3D32s, retrans=3D1s0ms > Flags: auto_linklocal One more data point: on the Quagga machine, my ISP is seeing this: # ip -6 route show | grep 2a00:14b0:4200:32xx 2a00:14b0:4200:32xx::/64 dev vlan503 proto kernel metric 256 2a00:14b0:4200:32xx::/64 dev vlan503 proto kernel metric 256 2a00:14b0:4200:32xx::/64 dev vlan503 proto kernel metric 256 2a00:14b0:4200:32xx::/64 dev vlan503 proto kernel metric 256 2a00:14b0:4200:32xx::/64 dev vlan503 proto kernel metric 256 2a00:14b0:4200:32xx::/64 dev vlan503 proto kernel metric 256 2a00:14b0:4200:32xx::/64 dev vlan503 proto kernel metric 256 2a00:14b0:4200:32xx::/64 dev vlan503 proto kernel metric 256 2a00:14b0:4200:32xx::/64 dev vlan503 proto kernel metric 256 2a00:14b0:4200:32xx::/64 dev vlan503 proto kernel metric 256 2a00:14b0:4200:32xx::/64 dev vlan503 proto kernel metric 256 2a00:14b0:4200:32xx::/64 dev vlan503 proto kernel metric 256 2a00:14b0:4200:32xx::/64 dev vlan503 proto kernel metric 256 2a00:14b0:4200:32xx::/64 dev vlan503 proto kernel metric 256 2a00:14b0:4200:32xx::/64 dev vlan503 proto kernel metric 256 2a00:14b0:4200:32xx::/64 dev vlan503 proto kernel metric 256 2a00:14b0:4200:32xx::/64 dev vlan503 proto kernel metric 256 2a00:14b0:4200:32xx::/64 dev vlan503 proto kernel metric 256 2a00:14b0:4200:32xx::/64 dev vlan503 proto kernel metric 256 2a00:14b0:4200:32xx::/64 dev vlan503 proto kernel metric 256 2a00:14b0:4200:32xx::/64 dev vlan503 proto kernel metric 256 ^C This make no sense, does it? My machines don=E2=80=99t run rtadvd; I = believe the bridge is not actively using (R)STP, nor is there any active = routing protocol. Why Quagga would try to (and succeed) install tens of = copies of seemingly identical routes is beyond me. Stefan -- Stefan Bethke Fon +49 151 14070811 --Apple-Mail=_9F391E84-9692-4450-ABAC-E3BD74BAF297 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEzBAEBCgAdFiEEJ+hF98o4r3eU/HiPD885WK4W4sEFAlpajPsACgkQD885WK4W 4sFkUQgArfHiuX/Zh/RO4m5Nh01T3BGaGqzS4qMrx51hFdrzkbg5w0aQBZxz3y+a F62py++6tpbqgk1Bs3Pz1i4JXxemcobS5PhRZVrvCpkq4ZbGG/5xywgIiVhwpZ8f 1bt51RibekQIhRz4zEh9hapn1EWy+EYyhtKamc8UawBFPRN7B1q7mQVnznOgKE+r 6yS8RJtvjTu0wuuto5ntSi58/ugpa92ACUSxNh0qLNKFi0viLmfdhDBC5eKCeOYJ /+NvtkzpTuFw7mE+XH2zq7Z+It8WgXliOXylXFXGJqllMJqU/lKmC6TQYUNfJsZN UuyEKiVz1lsa06z+Kxz3BGJVbUVS7g== =pRaW -----END PGP SIGNATURE----- --Apple-Mail=_9F391E84-9692-4450-ABAC-E3BD74BAF297--