On Wed, Feb 26, 2025 at 09:20:58PM +0100, Linus Lüssing wrote:
> [...]
> The main issue seems that the learned or manually set multicast
> router ports in the Linux bridge are not propagated down to the
> actual multicast offloading switches.
Next to this issue I'm also wondering if the following might still
need addressing (which this patchset does not try to address?) to
support multicast offloading switches with kernelspace
IGMP/MLD snooping - or if there are some switch chips which do
not support this and hence won't be able to use kernelspace
IGMP/MLD snooping. A rough first attempt of a guideline/checklist:
Needed switch chip capabilities:
1) adding MDB entries to ports
2) adding multicast router ports
3) -> the switch chip must only apply these to
a) IP packets with a matching protocol family
(ether type 0x0800 || 0x86DD) and:
b.1) snoopable IP multicast address ranges
(224.0.0.0/4 minus 224.0.0.0/24,
ff00::/8 minus ff02::1/128
IP destination addresses)
b.2) alternatively to b.1 (+a), but less
desirably a switch chip might match on layer 2:
01:00:5E:00:00:00, mask ff:ff:ff:f8:00:00
minus 01:00:5e:00:00:00, mask ff:ff:ff:ff:ff:00;
33:33:00:00:00:00, mask ff:ff:00:00:00:00
minus 33:33:00:00:00:01, mask ff:ff:ff:ff:ff:ff
c.1) must *not* apply this to IGMP/MLD reports
(especially IGMPv1/v2/MLDv1 reports), they
must only be forwarded to the registered
multicast router ports *plus*
the CPU port / Linux bridge,
for the latter to be able to learn
c.2) may forward IGMP/MLD packets
only to the CPU port / Linux bridge,
if the Linux bridge (or DSA) can in turn
selectively forward the IGMP/MLD
to multicast router ports,
excluding the incoming port
-> DSA might need to inform the
Linux bridge about the
supported mode of the switch chip?
(d) IGMP/MLD queries need to be flooded to
all ports by default, but they would not
match 3.b or 3.c.1 anyway; 3.c.2 may
match, then the Linux bridge (or DSA)
needs to make sure to reflect it back
to all ports excluding the incoming port
4) Any frame that did not match via 3) within the
switch chip must by default be flooded to all ports
4.1) this should be tunable and propagated from
Linux bridge MCAST_FLOOD port flag to the
switch chip
4.2) if a switch chip cannot comply with 3) and
has bridge port isolation enabled then
the Linux bridge should perform multicast
forwarding and IGMP/MLD snooping fully
in kernelspace and return a warning
about missing hardware support
4.3) if a switch chip cannot adhere to neither 3) nor 4.2)
then a user trying to enable bridge multicast snooping
should be denied and return an error
=> no incomplete hacks allowed, which might break
especially IP in specific scenarios
Would it maybe make sense to add some guideline/checklist like this,
which is more explicit than RFC4541 but should be compatible
to it, to Documentation/networking/dsa/dsa.rst?
(I'm not as familiar with DSA/switchdev/switch chips as
with IP/IGMP/MLD/RFC4541 on layer 2+. So especially feedback
from people more familiar with these lower layes would be
appreciated.)
-----
Why I'm also wondering if a guideline might be useful because:
Saw this merging of multicast routers ports and MDB approach
discussion here:
https://lore.kernel.org/netdev/db38eb8f-9109-b142-6ef4-91df1c1c9de3@xxxxxx/
I have some suspicion what it might try to achieve, but am unsure
if that can work reliably in all scenarios.
Is this intended as a hack where the switch chip or DSA has no
support to configure multicast router ports?
If yes, what would happen if there is:
1) a layer 3 multicast router
2) a multicast sender with a routable destination address
3) no local multicast listener for 3), so no local reports
for it?
Would neither an MDB nor a multicast router port be configured then?
Or with two multicast snooping switches, if one of them never sees
the according IGMP/MLD reports due to RFC4541 forwarding
restrictions?
Regards, Linus
