* Bridged passthru MACVLAN breaks IPv6 multicast? @ 2021-08-22 18:07 Tom Yan 2021-08-24 4:12 ` Tom Yan 0 siblings, 1 reply; 5+ messages in thread From: Tom Yan @ 2021-08-22 18:07 UTC (permalink / raw) To: netdev 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Bridged passthru MACVLAN breaks IPv6 multicast? 2021-08-22 18:07 Bridged passthru MACVLAN breaks IPv6 multicast? Tom Yan @ 2021-08-24 4:12 ` Tom Yan 2021-08-24 4:57 ` Tom Yan 0 siblings, 1 reply; 5+ messages in thread From: Tom Yan @ 2021-08-24 4:12 UTC (permalink / raw) To: netdev, davem 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 <tom.ty89@gmail.com> 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Bridged passthru MACVLAN breaks IPv6 multicast? 2021-08-24 4:12 ` Tom Yan @ 2021-08-24 4:57 ` Tom Yan 2021-08-24 7:41 ` Tom Yan 0 siblings, 1 reply; 5+ messages in thread From: Tom Yan @ 2021-08-24 4:57 UTC (permalink / raw) To: netdev, davem Never mind. I made a mistake. Turns out only Neighbor Solicitation from a LAN host does not "walk across" the MACVLAN. ping ff02::1%some_dev and Neighbor Solicitation from a bridge tap host actually do. (I forgot to change the ether saddr for them: the underlying link is a wireless NIC) Btw Neighbor Advertisement from a LAN host "walks across" the MACVLAN as well. I can see it on this host. I guess I can workaround the problem by re-enabling IPv6LL on the MACVLAN. Still wonder why that is broken though. On Tue, 24 Aug 2021 at 12:12, Tom Yan <tom.ty89@gmail.com> wrote: > > 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 <tom.ty89@gmail.com> 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Bridged passthru MACVLAN breaks IPv6 multicast? 2021-08-24 4:57 ` Tom Yan @ 2021-08-24 7:41 ` Tom Yan 2021-08-29 13:12 ` Tom Yan 0 siblings, 1 reply; 5+ messages in thread From: Tom Yan @ 2021-08-24 7:41 UTC (permalink / raw) To: netdev, davem To be more precise, when the passthru MACVLAN is not bridged, I can see: # tcpdump -eni any icmp6 tcpdump: data link type LINUX_SLL2 tcpdump: verbose output suppressed, use -v[v]... for full protocol decode listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes 15:30:50.865328 wlan0 M ifindex 5 LAN_HOST_MAC ethertype IPv6 (0x86dd), length 92: LAN_HOST_LL > ff02::1:MEH:MEH: ICMP6, neighbor solicitation, who has THIS_HOST_LL, length 32 15:30:50.865547 macvl0 M ifindex 6 LAN_HOST_MAC ethertype IPv6 (0x86dd), length 92: LAN_HOST_LL > ff02::1:MEH:MEH: ICMP6, neighbor solicitation, who has THIS_HOST_LL, length 32 followed by unicast neighbor advertisement "OUTs" from this host to the LAN host. But when the MACVLAN is bridged, I cannot see a similar capture at all (i.e. it doesn't just "stop" before "walking across" the MACVLAN, rather they appear to be blocked at "the outside" or so.) On Tue, 24 Aug 2021 at 12:57, Tom Yan <tom.ty89@gmail.com> wrote: > > Never mind. I made a mistake. Turns out only Neighbor Solicitation > from a LAN host does not "walk across" the MACVLAN. ping > ff02::1%some_dev and Neighbor Solicitation from a bridge tap host > actually do. (I forgot to change the ether saddr for them: the > underlying link is a wireless NIC) > > Btw Neighbor Advertisement from a LAN host "walks across" the MACVLAN > as well. I can see it on this host. > > I guess I can workaround the problem by re-enabling IPv6LL on the > MACVLAN. Still wonder why that is broken though. > > On Tue, 24 Aug 2021 at 12:12, Tom Yan <tom.ty89@gmail.com> wrote: > > > > 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 <tom.ty89@gmail.com> 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Bridged passthru MACVLAN breaks IPv6 multicast? 2021-08-24 7:41 ` Tom Yan @ 2021-08-29 13:12 ` Tom Yan 0 siblings, 0 replies; 5+ messages in thread From: Tom Yan @ 2021-08-29 13:12 UTC (permalink / raw) To: netdev, davem Hmm, interestingly, the problem occurs only when I am using the permanent MAC address of the wireless NIC. If I change/randomize the address (and of course, make the bridge use the result as its own address as well), Neighbor Solicitations can come in without needing the NIC and the MACVLAN to have IPv6LL. On Tue, 24 Aug 2021 at 15:41, Tom Yan <tom.ty89@gmail.com> wrote: > > To be more precise, when the passthru MACVLAN is not bridged, I can see: > > # tcpdump -eni any icmp6 > tcpdump: data link type LINUX_SLL2 > tcpdump: verbose output suppressed, use -v[v]... for full protocol decode > listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot > length 262144 bytes > 15:30:50.865328 wlan0 M ifindex 5 LAN_HOST_MAC ethertype IPv6 > (0x86dd), length 92: LAN_HOST_LL > ff02::1:MEH:MEH: ICMP6, neighbor > solicitation, who has THIS_HOST_LL, length 32 > 15:30:50.865547 macvl0 M ifindex 6 LAN_HOST_MAC ethertype IPv6 > (0x86dd), length 92: LAN_HOST_LL > ff02::1:MEH:MEH: ICMP6, neighbor > solicitation, who has THIS_HOST_LL, length 32 > > followed by unicast neighbor advertisement "OUTs" from this host to > the LAN host. > > But when the MACVLAN is bridged, I cannot see a similar capture at all > (i.e. it doesn't just "stop" before "walking across" the MACVLAN, > rather they appear to be blocked at "the outside" or so.) > > On Tue, 24 Aug 2021 at 12:57, Tom Yan <tom.ty89@gmail.com> wrote: > > > > Never mind. I made a mistake. Turns out only Neighbor Solicitation > > from a LAN host does not "walk across" the MACVLAN. ping > > ff02::1%some_dev and Neighbor Solicitation from a bridge tap host > > actually do. (I forgot to change the ether saddr for them: the > > underlying link is a wireless NIC) > > > > Btw Neighbor Advertisement from a LAN host "walks across" the MACVLAN > > as well. I can see it on this host. > > > > I guess I can workaround the problem by re-enabling IPv6LL on the > > MACVLAN. Still wonder why that is broken though. > > > > On Tue, 24 Aug 2021 at 12:12, Tom Yan <tom.ty89@gmail.com> wrote: > > > > > > 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 <tom.ty89@gmail.com> 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2021-08-29 13:12 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-08-22 18:07 Bridged passthru MACVLAN breaks IPv6 multicast? Tom Yan 2021-08-24 4:12 ` Tom Yan 2021-08-24 4:57 ` Tom Yan 2021-08-24 7:41 ` Tom Yan 2021-08-29 13:12 ` Tom Yan
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.