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

Brendan Doyle brendan.doyle at oracle.com
Thu Nov 18 17:39:34 UTC 2021



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",

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

>
> 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$
>>



More information about the discuss mailing list