Date: Sat, 13 Jan 2018 23:06:36 +0100 From: Stefan Bethke <stb@lassitu.de> To: freebsd-net@freebsd.org Cc: Thomas Wieske <thw@hh.de>, Andreas Sons <sons@indusi.net> Subject: IPv6 NDP triggering QuaggaLinux problem? Message-ID: <2D00C83A-5A25-4A69-9D31-BD1E9F61BD49@lassitu.de>
next in thread | raw e-mail | index | archive | help
--Apple-Mail=_3A8344FF-B41D-49B3-A27D-71D615AC6953 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hey guys, I=E2=80=99m a bit stumped and are hoping for some helpful pointers. 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. 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. 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. 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. 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). I=E2=80=99ve tried switching off NUD, but that doesn=E2=80=99t change = the behaviour of the Quagga system. Here=E2=80=99s some output of the current configuration: # ifconfig igb0; ifconfig bridge0 igb0: flags=3D8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> = metric 0 mtu 1500 = options=3D6403bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCS= UM,TSO4,TSO6,VLAN_HWTSO,RXCSUM_IPV6,TXCSUM_IPV6> 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<IFDISABLED> media: Ethernet autoselect (1000baseT <full-duplex>) status: active bridge0: flags=3D8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> 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<AUTO_LINKLOCAL,DEFAULTIF> 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<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP> 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 Stefan -- Stefan Bethke <stb@lassitu.de> Fon +49 151 14070811 --Apple-Mail=_3A8344FF-B41D-49B3-A27D-71D615AC6953 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/HiPD885WK4W4sEFAlpaguwACgkQD885WK4W 4sGhEQf/aSTQYoGrh0vD2vY8ThhvcJNHmKLezgH/MUhPjAzCWs7R7dSEBlkvdznG mXAPdwHIfPkNe+vNfazIIb1rKPjw5I5cm6zt7N9igFmDcJPytj5AVMSQEOELukzM 4Fk9K0Go6OgWAKISPBxSi9RfVitFLpgNBTOFMWnGLOeB6uhz1624TCZ8KWnaVbv5 Knphs3jU4OTYc7/EbE1fe//67fej9HzMAGPgN+hKAg6UA6utEQuWUoYPDkSiE/xv L4Y0o60pzc8rsi5BWaNL6doAUNcdGSjcxrq0DVwZz/WpGnZMbouqY8c+D01dvePR fJNT79BcOOiffnkwTdC0XueDHVkWDg== =8VC3 -----END PGP SIGNATURE----- --Apple-Mail=_3A8344FF-B41D-49B3-A27D-71D615AC6953--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2D00C83A-5A25-4A69-9D31-BD1E9F61BD49>