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 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://mail.openvswitch.org/mailman/listinfo/ovs-discuss > _______________________________________________ discuss mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
