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
