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. Having said this, I'm not sure what should be the ideal behaviour. Thanks Numan > > Brendan. > > _______________________________________________ > 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
