On Thu, Mar 09, 2023 at 07:16:04AM +0100, Ales Musil wrote:
> There are essentially three problems with the current
> combination of DGP + SNAT + LB:
> 
> 1) The first packet is being SNATed in common zone due
> to a problem with pinctrl not preserving ct_mark/ct_label.
> The commit would create a SNAT entry within the same with DNAT
> entry.
> 
> 2) The unSNAT for reply always happened in common zone because of
> the loopback check which would be triggered only when we loop
> the packet through the LR. Now there are two possibilities how
> the reply packet would be handled:
> 
> a) If the entry for SNAT in common zone did not time out yet, the
> packet would be passed through unSNAT in common zone which would
> be fine and continue on. However, the unDNAT wouldn't work due to
> the limitation of CT not capable of doing unSNAT/unDNAT on the same
> packet twice in the same zone. So the reply would arrive to
> the original interface, but with wrong source address.
> 
> b) If the entry for SNAT timed out it would loop and do unSNAT correctly
> in separate zone and then also unDNAT. This is not possible anymore with
> a recent change 8c341b9d (northd: Drop packets destined to router owned NAT 
> IP for DGP).
> The reply would be dropped before looping after that change co the traffic
> would never arrive to the original interface.
> 
> 3) The unDNAT was happening only if the DGP was outport meaning
> the reply traffic was routed out, but in the opposite case
> the unDNAT was happening only because of the looping which made
> outport=inport. That's why it worked before introduction of explicit drop.
> 
> In order to fix all those issues do two changes:
> 
> 1) Include inport in the unDNAT match, so that we have both
> routing directions covered e.g. (inport == "dgp_port" || outport == 
> "dpg_port").
> 
> 2) Always use the separate zone for SNAT and DNAT. As the common
> zone was needed for HWOL make the common zone optional with
> configuration option called "use_common_zone". This option is
> by default "false" and can be specified per LR. Use of separate
> zones also eliminates the need for the flag propagation
> in "lr_out_chk_dnat_local" stage, removing the match on ct_mark/ct_label.
> 
> Reported-at: https://bugzilla.redhat.com/2161281
> Signed-off-by: Ales Musil <[email protected]>
> ---
> v2: Fix flaky system test.
> v3: Rebase on top of current main.

I am seeing consistent failure of system-tests with this version :(

237: SNAT in separate zone from DNAT -- ovn-northd -- parallelization=yes -- 
ovn_monitor_all=yes FAILED (system-ovn.at:8702)
238: SNAT in separate zone from DNAT -- ovn-northd -- parallelization=yes -- 
ovn_monitor_all=no FAILED (system-ovn.at:8702)
239: SNAT in separate zone from DNAT -- ovn-northd -- parallelization=no -- 
ovn_monitor_all=yes FAILED (system-ovn.at:8702)
240: SNAT in separate zone from DNAT -- ovn-northd -- parallelization=no -- 
ovn_monitor_all=no FAILED (system-ovn.at:8702)

Link: 
https://github.com/horms/ovn/actions/runs/4383139214/jobs/7676416462#step:13:3734
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Reply via email to