Re: Bridged passthru MACVLAN breaks IPv6 multicast?
From: Tom Yan <hidden>
Date: 2021-08-24 04:12:59
Hi, I've further investigated the problem: What "walk across": ping ff02::1%bridge and Neighbor Solicitation from this host (tcpdump multicast on a LAN host can see them) ping ff02::1%some_dev from a LAN host (tcpdump multicast on this host or a bridge tap host can see them) What do not "walk across": Neighbor Solicitation from a LAN host (both tcpdump multicast on this host and on a bridge tap host cannot see them) ping ff02::1%some_dev and Neighbor Solicitation from a bridge tap host (tcpdump multicast on this host can see them, but that on a LAN host cannot) There is no problem with ARP (or IPv4 multicast, apparently). P.S. I've filed a bug report on: https://bugzilla.kernel.org/show_bug.cgi?id=214153 Regards, Tom On Mon, 23 Aug 2021 at 02:07, Tom Yan [off-list ref] wrote:
Hi, Normally when a NIC is (directly) enslaved as a bridge port, the NIC itself does not need to have a IPv6 link-local address configured on it for IPv6 multicast / NDP to work properly (instead the address can simply be configured on the bridge like IPv4 addresses). Yet it appears that if the bridge port is instead a passthru mode MACVLAN, IPv6 multicast traffics from (the link/"side" of) it cannot reach the host (as in, cannot even be captured with tcpdump) unless either the MACVLAN or its underlying link has a/the[1] IPv6 link-local address configured. Is it an expected behavior? Or is it a bug? [1]: In my configuration, the bridge, the bridged passthru MACVLAN and its underlying link have the same MAC address and hence (at least by default) their IPv6 link-local addresses are identical. Regards, Tom