Thread (5 messages) flat view 5 messages, 1 author, 2021-08-29

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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help