On 7/30/26 4:09 PM, Mark Michelson wrote: > 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, >
Hi Mark, > 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. > Thanks for the feedback, I'll handle 25.03 downstream. I did backport the patches now to 25.09 too as that's still supported. Regards, Dumitru >> >> 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
