[ovs-discuss] [ovn] ovn-controller: packet buffering resumes the packet through the tunnel incorrectly

[Daniel Alvarez Sanchez]

Hi folks,

We found a problem related to the packet buffering feature introduced by
[0] when the destination address is unknown. In such a case, ovn-controller
sends an ARP request and, upon resolving the MAC address, the packet will
be resumed.

If the packet is coming from a Floating IP (dnat_and_snat NAT entry with
external_mac and logical_port fields filled in) it should be resumed
through a localnet port (DVR use case). However, it will be instead pushed
via the tunnel interface to the chassis that is hosting the gateway port.

This creates traffic disruption as the ToR switch will see the MAC address
of the Floating IP on the gateway port and subsequent packets will not be
sent to the compute node where the logical port is bound to.

When the next ARP request for the FIP is sent, as a MAC_Binding entry will
already be present, the packet buffering feature doesn't kick in and the
ARP reply will be sent through the localnet port and seen by the ToR switch
in the right port as expected. More details at [1].

An easy way to reproduce this is to ping a Floating IP from an external
node. In order to reproduce it 100% of the time, you can delete the
MAC_Binding entry corresponding to the source IP to force the packet
buffering in the compute node. I use vagrant setup like [2].

Thanks,
Daniel

[0]
https://github.com/openvswitch/ovs/commit/d7abfe39cfd234227bb6174b7f959a16dc803b83
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1788193
[2] https://github.com/danalsan/vagrants/tree/master/ovn-playground
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openvswitch.org/pipermail/ovs-discuss/attachments/20200127/ef759c00/attachment.html>