On 2/24/21 10:34 AM, Numan Siddique wrote:
On Wed, Feb 24, 2021 at 2:43 PM Numan Siddique <[email protected]> wrote:
On Wed, Feb 24, 2021 at 2:37 PM Numan Siddique <[email protected]> wrote:
On Tue, Feb 23, 2021 at 6:50 PM Dumitru Ceara <[email protected]> wrote:
If two load balancer VIPs share the same backend, both sets of hairpin
reply learn() flows should be generated. In order to ensure that,
also match on the original destination IP and port tuple. These are
now stored in OVS registers by ovn-northd in stage ls-in-stateful.
An alternative solution would be to add an additional match on
ct_nw_dst() and ct_tp_dst() in the hairpin detection flows but it's
better to avoid that because these matches are usually not offloadable
to hardware.
To ensure backwards compatibility though, if ovn-controller detects
that ovn-northd doesn't store the original destination tuple
information in OVS registers, ovn-controller falls back to using
ct_nw_dst() and ct_tp_dst().
Reported-by: Tim Rozet <[email protected]>
Reported-at: https://bugzilla.redhat.com/1931599
Fixes: 022ea339c8e2 ("lflow: Use learn() action to generate LB hairpin reply
flows.")
Signed-off-by: Dumitru Ceara <[email protected]>
Hi Dumitru,
Thanks for the fix.
A couple of minor nits below.
With those addressed.
Acked-by: Numan Siddique <[email protected]>
I would also suggest to enhance the test in ovn.at to pause ovn-northd,
clear the lb option - 'hairpin_orig_tuple' and make sure that flows
have the match with the ct_* fields.
My bad. You already do it. Please forget this comment.
Numan
Thanks for the review Numan!
I sent a v2: http://patchwork.ozlabs.org/project/ovn/list/?series=230875
Regards,
Dumitru
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev