On Wed, Jul 29, 2026 at 11:03 AM Dumitru Ceara <[email protected]> wrote: > > Hi all, > > Thanks for the feedback everyone! I backported the following to > branch-26.03: > > 17ef4a0d0d4d ("northd: Use MC_UNKNOWN for broadcast ARP requests.") > 19860c669640 ("northd: Restrict ARP/ND_NS L2 lookup flows to broadcast.") > > It turns out we have a downstream request to get this fixed on > older branches too, specifically on branch-25.03. > > I know that officially 25.03 is not supported anymore and we could just > take care of that downstream. But if people are OK with making an > exception I could prepare backport patches for 25.03 and 25.09. That > would simplify our downstream life a bit. > > Would that be acceptable?
Hi Dumitru, As you mentioned, 25.03 is not supported anymore. I think the magnitude of these changes is not so great that it warrants an exception to our upstream policy. Unless there is specifically demand for an upstream backport, I think doing this downstream-only is preferable. Since 25.03 is not receiving upstream changes any longer, there is very little risk to backporting this downstream-only. We (Red Hat) will just need to ensure that CI is run properly on the backported changes since we normally rely on github to do it for us on upstream contributions. > > Regards, > Dumitru > > On 7/28/26 5:52 PM, Mark Michelson wrote: > > I think backporting 1872d61e34aa is fine by me as well. > > > > On Tue, Jun 30, 2026 at 7:42 AM Dumitru Ceara <[email protected]> wrote: > >> > >> Hi Ales, > >> > >> On 6/26/26 3:02 PM, Ales Musil wrote: > >>> On Fri, Jun 26, 2026 at 2:09 PM Dumitru Ceara via dev < > >>> [email protected]> wrote: > >>> > >>>> The flows in ls_in_l2_lkup, generated by > >>>> build_lswitch_rport_arp_req_flow(), matched ARP requests and > >>>> ND_NS for router-owned IPs without restricting eth.dst to > >>>> broadcast/multicast. This caused unicast ARP requests > >>>> (eth.dst == router_MAC) to be intercepted and flooded into the > >>>> L2 domain. > >>>> > >>>> On switches with 200+ ports this flooding can exceed the OVS > >>>> 4096 resubmit limit, dropping the packet. > >>>> > >>>> Fix arp_nd_ns_match() to add "eth.dst == ff:ff:ff:ff:ff:ff" > >>>> for IPv4 ARP and "eth.mcast" for IPv6 ND_NS. This follows > >>>> the precedent set by commit c05c565548 which added the same > >>>> eth.dst restriction to the priority 75 self-originated ARP > >>>> flood flow in the same pipeline stage. > >>>> > >>>> After this fix, unicast ARP and ND requests for router-owned > >>>> IPs fall through to the L2_LKUP stage flows for direct L2 > >>>> delivery. > >>>> > >>>> Reported-at: https://issues.redhat.com/browse/FDP-3885 > >>>> Assisted-by: Claude Opus 4.6, Claude Code > >>>> Signed-off-by: Dumitru Ceara <[email protected]> > >>>> --- > >>>> NOTE: this depends on 1872d61e34aa ("northd: Use MC_UNKNOWN for > >>>> broadcast ARP requests.") which is only present on the main branch. > >>>> For backporting this fix to 26.03 we'd have to backport its dependency > >>>> too. > >>>> --- > >>>> northd/northd.c | 7 +- > >>>> tests/ovn-northd.at | 265 ++++++++++++++++++++++++-------------------- > >>>> tests/ovn.at | 206 ++++++++++++++++++++++++++++++++++ > >>>> 3 files changed, 358 insertions(+), 120 deletions(-) > >>>> > >> > >> ... > >> > >>>> > >>>> > >>> Looks good to me, thanks. > >>> > >>> Acked-by: Ales Musil <[email protected]> > >>> > >> > >> Thanks for the review! Applied to main. > >> > >> As this is a bug fix, I'd like to backport it to 26.03 but in order for > >> it to function properly we'd also need to backport its dependency, > >> 1872d61e34aa ("northd: Use MC_UNKNOWN for broadcast ARP requests."). > >> > >> Are there any objections for me doing that (maintainers in CC)? > >> > >> Regards, > >> Dumitru > >> > > > _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
