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

[Brendan Doyle]

On 18/11/2021 21:22, Numan Siddique wrote:
> 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.

Got it thanks.
> 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://urldefense.com/v3/__https://mail.openvswitch.org/mailman/listinfo/ovs-discuss__;!!ACWV5N9M2RV99hQ!Zbx3Huwtf7HQOQSj1AbLdfJ9lcY2uHfpDnZrFcz3Bqcc9M0ubKiXXSidBugo9wSA9g8$