On 18/11/2021 17:01, Numan Siddique wrote:
On Thu, Nov 18, 2021 at 10:46 AM Brendan Doyle <[email protected]> wrote:
On 08/11/2021 16:14, Numan Siddique wrote:
On Mon, Nov 8, 2021 at 5:39 AM Brendan Doyle <[email protected]> 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
[email protected]
https://urldefense.com/v3/__https://mail.openvswitch.org/mailman/listinfo/ovs-discuss__;!!ACWV5N9M2RV99hQ!ZmCZlVEXQ1H-EANp8kVvFMa2SBzTAAJtqR5F3NXQnDc3HV0DVd90cLpqFe3RBKCsX_8$
_______________________________________________
discuss mailing list
[email protected]
https://urldefense.com/v3/__https://mail.openvswitch.org/mailman/listinfo/ovs-discuss__;!!ACWV5N9M2RV99hQ!ZJJyHZpS1-U1dPvEPVMZTChVVS-nkSERP7BuA7nMm4GmqWjGLrBpQZ8bjRWNpw3oTlo$
_______________________________________________
discuss mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
