[ovs-discuss] [External] : Re: OVN using the wrong SNAT for established connections

[Numan Siddique]

On Thu, Nov 18, 2021 at 12:40 PM Brendan Doyle <brendan.doyle at oracle.com> wrote:
>
>
>
> On 18/11/2021 17:01, Numan Siddique wrote:
> > On Thu, Nov 18, 2021 at 10:46 AM Brendan Doyle <brendan.doyle at oracle.com> wrote:
> >>
> >>
> >> On 08/11/2021 16:14, Numan Siddique wrote:
> >>> On Mon, Nov 8, 2021 at 5:39 AM Brendan Doyle <brendan.doyle at oracle.com> wrote:
> >>>> Hi,
> >>>>
> >>>>
> >>>> So I have a Distributed router port gateway that had the following NAT entry
> >>>>
> >>>>        nat 2dbfe551-50ff-43f3-b8b0-7d2e857dea8c
> >>>>            external ip: "253.255.80.24"
> >>>>            logical ip: "10.117.0.0/23"
> >>>>            type: "snat"
> >>>>
> >>>> A VM with IP 10.117.0.3 is using this to mount a filesystem in the
> >>>> underlay, all works fine
> >>>> it's 10.117.0.3 is SNAT'd to 253.255.80.24.
> >>>>
> >>>> Another NAT entry is added, so we have:
> >>>>
> >>>>        nat 2dbfe551-50ff-43f3-b8b0-7d2e857dea8c
> >>>>            external ip: "253.255.80.24"
> >>>>            logical ip: "10.117.0.0/23"
> >>>>            type: "snat"
> >>>>       nat 80572056-3bfd-4b10-abd0-4c084cd73474
> >>>>            external ip: "253.255.80.30"
> >>>>            logical ip: "10.117.0.0/24"
> >>>>            type: "snat"
> >>>>
> >>>>
> >>>> I expect OVN to now SNAT 10.117.0.3 to 253.255.80.30 based on the
> >>>> longest prefix match.
> >>>> But it does not, it SNAT' to 253.255.80.24. If I umount the filesystems
> >>>> originally mounted when
> >>>> there was only the /23 SNAT entry. i.e the TCP connections are closed.
> >>>> Then I see OVN SNAT'ing
> >>>> to the correct IP with the longest prefix.
> >>>>
> >>>> It seems that the longest prefix match is not applied if there
> >>>> established TCP connections?
> >>>>
> >>>> What's the expected behavior here?
> >>> To me this seems to be the expected behavior with the present code.
> >>> Because since the connection was established already and since there
> >>> is a conntrack entry present for that connection,  the newly added flows
> >>> don't take effect.
> >>>
> >>> On the gateway node (or on the node where the NAT happens) if you
> >>> flush the conntrack entries, it would work as expected.
> >> So I'm assuming you mean with
> >>
> >> ovs-ofctl ct-flush-zone
> >>
> >> How would I find out what zone is associated with the NAT IP
> > On the gw node,  run - ovs-vsctl get bridge br-int external_ids
> >
> > You can see the snat zone and dnat zone ids allocated for the logical router.
> > The SB datapath_binding uuid for the logical router is used as the key.
>
> Thanks, so
>
>   ct-zone-ln-ls_vcn3_external_stgw="25",
>

This zone is for logical ports.

For SNAT/DNAT, router snat/dnat ids are used.

Eg. ct-zone-65b40bfa-9266-4ec7-826f-06cd99397427_dnat="4",
ct-zone-65b40bfa-9266-4ec7-826f-06cd99397427_snat="6"

Before flushing, you can run "conntrack -L  | grep <NAT IP>"  just to
make sure that you see an entry for your old connection.

Thanks
Numan

> ovs-ofctl ct-flush-zone br-int 25

 For testing I normally run "conntrack -F" which flushes all the zones.
But I guess your approach to use ovs-ofctl ct-flush-zone is safer.

Numan

>
> >
> > Thanks
> > Numan
> >
> >> Brendan
> >>> Having said this,  I'm not sure what should be the ideal behaviour.
> >>>
> >>> Thanks
> >>> Numan
> >>>
> >>>> Brendan.
> >>>>
> >>>> _______________________________________________
> >>>> discuss mailing list
> >>>> discuss at openvswitch.org
> >>>> https://urldefense.com/v3/__https://mail.openvswitch.org/mailman/listinfo/ovs-discuss__;!!ACWV5N9M2RV99hQ!ZmCZlVEXQ1H-EANp8kVvFMa2SBzTAAJtqR5F3NXQnDc3HV0DVd90cLpqFe3RBKCsX_8$
> >> _______________________________________________
> >> discuss mailing list
> >> discuss at openvswitch.org
> >> https://urldefense.com/v3/__https://mail.openvswitch.org/mailman/listinfo/ovs-discuss__;!!ACWV5N9M2RV99hQ!ZJJyHZpS1-U1dPvEPVMZTChVVS-nkSERP7BuA7nMm4GmqWjGLrBpQZ8bjRWNpw3oTlo$
> >>
>
> _______________________________________________
> discuss mailing list
> discuss at openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss