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

Brendan Doyle brendan.doyle at oracle.com
Thu Nov 18 15:45:08 UTC 2021



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

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$



More information about the discuss mailing list