Messages in this thread | ![/](/images/icornerl.gif) | | Date | Fri, 5 Apr 2024 14:00:31 +0300 | Subject | Re: [PATCH RFC net-next 00/10] MC Flood disable and snooping | From | Nikolay Aleksandrov <> |
| |
On 4/5/24 13:20, Vladimir Oltean wrote: > On Thu, Apr 04, 2024 at 06:16:12PM -0400, Joseph Huang wrote: >>>> mcast_flood == off: >>>> - mcast_ipv4_ctrl_flood: don't care (maybe can force to "off") >>>> - mcast_ipv4_data_flood: don't care >>>> - mcast_ipv6_ctrl_flood: don't care >>>> - mcast_ipv6_data_flood: don't care >>>> - mcast_l2_flood: don't care >>>> mcast_flood == on: >>>> - Flood 224.0.0.x according to mcast_ipv4_ctrl_flood >>>> - Flood all other IPv4 multicast according to mcast_ipv4_data_flood >>>> - Flood ff02::/16 according to mcast_ipv6_ctrl_flood >>>> - Flood all other IPv6 multicast according to mcast_ipv6_data_flood >>>> - Flood L2 according to mcast_l2_flood >> >> Did you mean >> >> if mcast_flood == on (meaning mcast_flood is ENABLED) >> - mcast_ipv4_ctrl_flood: don't care (since 224.0.0.x will be flooded anyway) >> ... >> >> if mcast_flood == off (meaning mcast_flood is DISABLED) >> - Flood 224.0.0.x according to mcast_ipv4_ctrl_flood >> ... >> >> ? Otherwise the problem is still not solved when mcast_flood is disabled. > > No, I mean exactly as I said. My goal was not to "solve the problem" > when mcast_flood is disabled, but to give you an option to configure the > bridge to achieve what you want, in a way which I think is more acceptable. > > AFAIU, there is not really any "problem" - the bridge behaves exactly as > instructed given the limited language available to instruct it ("mcast_flood" > covers all multicast). So the other knobs have the role of fine-tuning > what gets flooded when mcast_flood is on. Like "yes, but..." > > You can't "solve the problem" when it involves changing an established > behavior that somebody probably depended on to be just like that. > >>> Yep, sounds good to me. I was thinking about something in these lines >>> as well if doing a kernel solution in order to make it simpler and more >>> generic. The ctrl flood bits need to be handled more carefully to make >>> sure they match only control traffic and not link-local data. >> >> Do we consider 224.0.0.251 (mDNS) to be control or data? What qualifies as >> control I guess that's my question. > > Well, as I said, I'm proposing that 224.0.0.x qualifies as control and > the rest of IPv4 multicast as data. Which means that, applied to your > case, "mcast_flood on mcast_ipv4_ctrl_flood on mcast_ipv4_data_flood off" > will "force flood" mDNS just like the IGMP traffic from your patches. > I'm not aware if this could be considered problematic (I don't think so). > > The reason behind this proposal is that, AFAIU, endpoints may choose to > join IGMP groups in the 224.0.0.x range or not, but RFC4541 says that > switches shouldn't prune the destinations towards endpoints that don't > join this range anyway: https://www.rfc-editor.org/rfc/rfc4541#page-6 > > Whereas for IP multicast traffic towards an address outside 224.0.0.x, > pruning will happen as per the IGMP join tracking mechanism.
+1, non-IGMP traffic to 224.0.0.x must be flooded to all anyway so this should allow for a better control over it, but perhaps the naming should be link_local instead because control usually means IGMP, maybe something like mcast_ip_link_local_flood
| ![\](/images/icornerr.gif) |