On 7/31/26 8:33 AM, enginrect wrote: > From: Jaygue Lee <[email protected]> > > The lr_out_snat flows that consume flags.force_snat_for_lb are only > built for gateway routers (od->is_gw_router). However, the load > balancer DNAT flows in lr_in_dnat and the lr_out_undnat flows set > flags.force_snat_for_lb whenever the option is configured, including on > routers whose gateway is a distributed gateway port. The result is a > flag that is produced but never consumed: the option is silently > ignored and load balanced traffic leaves the router without the forced > SNAT. > > This breaks hairpin scenarios where a load balancer backend reachable > through the gateway port connects to its own VIP: the un-SNATed reply > arrives at the backend with identical source and destination addresses > and is dropped as a martian packet. The logical switch hairpin stages > do not cover this case when the backend resides on a switch with a > localnet port, where attaching the load balancer to that switch is not > viable. > > Build the force SNAT consumer flows for routers with distributed > gateway ports as well, one per gateway port, applying ct_snat on the > chassis where the gateway port is resident with an > is_chassis_resident() match. This is consistent with how dnat_and_snat > and subnet SNAT entries are already centralized on such routers. The > "router_ip" variant and dnat_force_snat_ip remain gateway router only. > > Signed-off-by: Jaygue Lee <[email protected]> > ---
Recheck-request: github-robot-_ovn-kubernetes _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
