[ovs-discuss] OVN: MAC_Binding entries not getting updated leads to unreachable destinations

[Daniel Alvarez Sanchez]

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?

Thanks,
Daniel
On Fri, Oct 26, 2018 at 11:39 AM Daniel Alvarez Sanchez
<dalvarez at 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