On Thu, Nov 18, 2021 at 12:40 PM Brendan Doyle <[email protected]> wrote: > > > > 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", >
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. 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 > >>>> [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 _______________________________________________ discuss mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
