On Mon, Oct 29, 2018 at 5:00 PM Daniel Alvarez Sanchez <dalva...@redhat.com> wrote:
> Hi, > > After digging further. The problem seems to be reduced to reusing an > old gateway IP address for a dnat_and_snat entry. > When a gateway port is bound to a chassis, its entry will show up in > the MAC_Binding table (at least when that Logical Switch is connected > to more than one Logical Router). After deleting the Logical Router > and all its ports, this entry will remain there. If a new Logical > Router is created and a Floating IP (dnat_and_snat) is assigned to a > VM with the old gw IP address, it will become unreachable. > > A workaround now from networking-ovn (OpenStack integration) is to > delete MAC_Binding entries for that IP address upon a FIP creation. I > think that this however should be done from OVN, what do you folks > think? > > Agree. Since the MAC_Binding table row is created by ovn-controller, it should be handled properly within OVN. Thanks Numan > Thanks, > Daniel > On Fri, Oct 26, 2018 at 11:39 AM Daniel Alvarez Sanchez > <dalva...@redhat.com> wrote: > > > > Hi all, > > > > While analyzing a problem in OpenStack I think I have found out a > > severe bug in OVN when it comes to reuse floating IPs (which is a very > > common use case in OpenStack and Kubernetes). Let me explain the > > scenario, issue and possible solutions: > > > > * Three logical switches (Neutron networks) LS1, LS2, LS3 > > * LS3 has external connectivity (localnet port to a provider bridge). > > * Two logical routers LR1 and LR2. > > * LS1 and LS3 connected to LR1 > > * LS2 and LS3 connected to LR2. > > * VM1 in LS1 with a FIP (dnat_and_snat NAT entry) in LS3 CIDR > > * VM2 in LS2 with a FIP (dnat_and_snat NAT entry) in LS3 CIDR > > * Ping from VM1 to VM2 FIP and viceversa works. > > > > Echo requests from VM1 reach to VM2 and VM2 responds to the FIP of VM1. > > First time, ovn-controller will insert the ARP responder and add a new > > entry to MAC_Binding table like: > > > > _uuid : 447eaf43-119a-43b2-a821-0c79d8885d68 > > datapath : 07a76c72-6896-464a-8683-3df145d02434 > > ip : "172.24.5.13" > > logical_port : "lrp-82af833f-f78b-4f45-9fc8-719db0f9e619" > > mac : "fa:16:3e:22:6c:0a" > > > > |binding|INFO|cr-lrp-198e5576-b654-4605-80c0-b9cf6d21ea2b: Claiming > > fa:16:3e:22:6c:0a 172.24.5.4/24 > > > > The problem happens when VM1, LS1, LR1 entry are deleted and recreated > > again. If the FIP (172.24.5.13) is reused, the MAC_Binding entry won't > > get updated and VM2 will be now unable to respond to pings coming from > > VM1 as it'll attempt to do it to fa:16:3e:22:6c:0a. > > > > If I manually delete the MAC_Binding entry, a new one will then > > correctly be recreated by ovn-controller with the right MAC address > > (the one of the new cr-lrp). > > > > |00126|binding|INFO|cr-lrp-f09b2186-1cb2-4e50-99a5-587f680db8ad: > > Claiming fa:16:3e:14:48:20 172.24.5.6/24 > > > > _uuid : dae11bdb-47d3-471e-8826-9aefb8572700 > > datapath : 07a76c72-6896-464a-8683-3df145d02434 > > ip : "172.24.5.13" > > logical_port : "lrp-82af833f-f78b-4f45-9fc8-719db0f9e619" > > mac : "fa:16:3e:14:48:20" > > > > > > Possible solutions: > > > > 1) Make ovn-controller (or ovn.-northd?) to update the MAC_Binding > > entries whenever a new NAT row is created. > > > > 2) Send GARPs (I guess we're not doing this yet) whenever a LRP gets > > bound to a chassis for all the nat_addresses that it has configured. > > > > For 2), I guess that it would make MAC_Binding entries getting updated > > automatically? > > > > How does this sound? > > > > Thanks a lot, > > Daniel Alvarez > _______________________________________________ > discuss mailing list > disc...@openvswitch.org > https://mail.openvswitch.org/mailman/listinfo/ovs-discuss >
_______________________________________________ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
