Following apw's excellent advice pointing to https://www.v13.gr/blog/?p=378 and abusing another ipv6 address on the afflicted host:
tcpdump -npi br0 ip6 and not port 22 | grep -i neigh tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on br0, link-type EN10MB (Ethernet), capture size 262144 bytes [ fire up ping6 2601:282:8100:3500:641d:9dd0:5b50:46e6 on the gateway.] [ no traffic shows up on the bridge ] [ echo 0 > /sys/devices/virtual/net/br0/bridge/multicast_snooping ] 09:40:49.260756 IP6 fe80::1 > ff02::1:ff50:46e6: ICMP6, neighbor solicitation, who has 2601:282:8100:3500:641d:9dd0:5b50:46e6, length 32 09:40:49.260813 IP6 2601:282:8100:3500:641d:9dd0:5b50:46e6 > fe80::1: ICMP6, neighbor advertisement, tgt is 2601:282:8100:3500:641d:9dd0:5b50:46e6, length 32 Looks like bridge multicast_snooping causes ipv6 neighbor discovery to break. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1597806 Title: ipv6 neighbor discovery broken (on a bridge) Status in linux package in Ubuntu: Confirmed Bug description: I have a xenial (4.4.0-24-generic) machine that loses ipv6 connectivity every time I reboot the gateway it uses. br0 is a bridge which has eth0.2 as its only member, with (currently) 6 "scope global temporary deprecated dynamic" (privacy) addresses, and: inet6 2601:282:8100:3500:24c:40ff:fe1a:c570/64 scope global mngtmpaddr dynamic valid_lft 300sec preferred_lft 120sec The tcpdump trace on against eth0.2 of the broken machine: http://paste.ubuntu.com/18170606/ (fe80::1 is the gateway) http://paste.ubuntu.com/18173670/ is the output of lspci -vvn on one of the (quad) interfaces on the machine. Setting the bridge to promisc and turning it back off works around the issue. Tcpdump on the underlying eth0.2 does not. On another (yakkety) box, running 4-4-0.14-generic, I also see the problem: that interface is also br0, with eth0 (untagged) as its only member. All of the above leads me to believe that the kernel is not managing to correctly set up (at least some?) of the multicast addresses it needs to listen to on the bridge. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1597806/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp