I would like to get our hackspace more multicast ready. Especially to do some multicast routing between our hackspace and our Freifunk wireless mesh network, which thanks to batman-adv and the Linux bridge is now multicast aware. We do have several donated, older switches that others outsourced. But I don't trust them to do IGMP/MLD snooping correctly.
Therefore I'm looking for something that does the multicast forwarding in hardware but uses the IGMP/MLD snooping from the Linux bridge in kernelspace and runs on OpenWrt. So I guess I'm looking for something DSA + switchdev capable, but I guess not all of them support using IGMP/MLD snooping in kernelspace? I see some drivers which use DSA's port_mdb_add (b53, bcm_sf2, lan9303, microchip ksz, mt7530, mv88e6xxx, ocelot felix, qca8k-8xxx, sja1105) and/or switchdev's switchdev_obj_port_mdb (same as for DSA plus ksz9477, freescale dpaa2, marvell prestera, mellanox mlx5/mlxsw, lan966x, sparx5, ti am65-cpsw/icssg).
Does anyone know of specific devices/products which should work for us and might have some recommendations?
Regards, T_X
PS: Minimum spec would be 8 ports, managed, 1Gbit, ideally with at least 4 PoE ports. (The hackspace in total also has 46x RJ45 network sockets distributed over three rooms. But I don't think we need full multicast capabilities on all of them to start with. Especially as that would probably considerably bump the price.)
But I don't see it add a .port_mdb_add to dsa_switch_ops in linux/drivers/net/dsa/realtek/. So I don't think it uses the Linux bridge IGMP/MLD snooping?
However, currently multicast snooping is somewhat broken for all DSA switches. Multicast snooping requires that all multicast is flooded to multicast router ports (such as the port which has the multicast querier behind it). The bridge implementation in the kernel does that properly, but it is not implemented in DSA.
@janh oh, many thanks, that sounds like overall great news! Do you know if for now one can at least work around this by manually using and setting the Linux bridge multicast router port setting? Or does DSA neither forward to manually configured multicast router ports nor ones that were automatically detected by the Linux bridge code via MLD queries / MRD / PIM?
Urgh, I missed that discussion, even though I was CC'd... The discussion seems a bit messy... Will need to read up on it.
Yaiy, the second-hand ZyXEL GS1900-24HP v1 arrived and it's awesome to see so many ports in OpenWrt LuCI :-).
@janh one more issue I noticed on OpenWrt 24.10 with this Realtek chip that if there is no listener for an IP multicast group (I tried ff02::123 for instance) on any port that the packet gets flooded to all ports. Instead of being dropped. This works fine in a fully virtual bridge + veth environment, so I guess it's another issue with the rtl83xx DSA driver?
My current guess is this has to do with UNKNOWN_MC_PMASK. When IGMP/MLD snooping is active then this should probably not be set up for the full ethernet multicast range. And instead should be all multicast addresses minus the snoopable multicast addresses (and minus some reserved addresses like for LLDP? see br_handle_frame()). The snoopable multicast addresses would be 224.0.0.0/4 excluding the link-local range 224.0.0.0/24 (or if only l2 were possible the mapped 01:00:5e:00:00:xx) and ff00::/8 excluding ff02::1 (or if only l2 were possible the mapped 33:33:00:00:00:01). As specified in RFC4541, section 2.1.2 "Data Forwarding Rules" and section 3, IPv6 Considerations.
(Edit: I'm also wondering if I should open a new topic for fixing the rtl83xx DSA driver.)
Ok, I think I'm getting more familiar with the rtl83xx code, including the reference one from the Realtek SDK. And had some success with tuning the multicast flooding behaviour.
Another issue the current code in OpenWrt seems to have is that it does not always flood the unsnoopable addresses, as RFC4541 requires. If no one sends reports to for instance 224.0.0.251 thinks will work ok, then the bridge will flood it. However if one host sends reports and another one on another port doesn't then the latter won't get the packets anymore. So that can be annoying to debug, if things sometimes work and sometimes don't. Same if some (broken) IPv6 implementation were to send an MLD report for ff02::1 then this might break IPv6 for everyone else on another port, I think.
What I've been thinking about and been toying with to work around this is always adding an L2_MULTICAST entry for 33:33:00:00:00:01 as well as 01:00:5e:00:00:01 to 01:00:5e:00:00:ff to every port and configured VLAN. However there I'm now running into the issue that with VID 0 and 1, so 2x these 257 entries, I'd hit the current limit of 512 entries. I tried to fix that, too, as if I understand correctly it's actually, in theory the MC_PMSK table which is limited to 512 entries. For all the FDB and MDB entries however it should be possible to use 8k up to 32k, depending on which chip exactly and as long as FDB/MDB entries share some MC_PMSK entries. I got increasing that half working, still have the issue that the hashing function still seems to always map between 0 to 511, even though it's AND-ing with 0x7FF, so I would expect 2k of bucket inndexes. Will check more closely soon.
And another issue I still need to address in my patching attempts for multicast flooding disabled for snoopable addresses by default is to only do that when a querier is present on the link. But I don't think DSA has an API for that yet.
Edit: And for the unsnoopables IP multicast workaround I would like to use IP4_MULTICAST instead of L2_MULTICAST entries later, to reduce the number of potential collisions. However seems that's not really used and not yet fully implemented in the OpenWrt rtl83xx. For IP6_MULTICAST instead of L2_MULTICAST, I think that also wouldn't make much of a difference, as for IP6_MULTICAST the Realtek chip can still only track via four bytes in an IPv6 multicast destination addess, there is this weird mapping...
Edit2: I would also love to have an alternative workaround to adding 256 entries for IPv4 link-local multicast per VLAN... As that really seems to limit the amount of VLANs one could use overall... Maybe an option to disable multicast snooping selectively only for IPv4 might be one idea to save many workaround entries (as I personally also have no interest in IPv4 multicast, it lacks so many useful features of IPv6 multicast anyway.)