<div dir="ltr">Hi folks,<br><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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].</div><div><br></div><div>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].</div><div><br></div><div>Thanks,</div><div>Daniel</div><div><br></div><div>[0] <a href="https://github.com/openvswitch/ovs/commit/d7abfe39cfd234227bb6174b7f959a16dc803b83">https://github.com/openvswitch/ovs/commit/d7abfe39cfd234227bb6174b7f959a16dc803b83</a></div><div>[1] <a href="https://bugzilla.redhat.com/show_bug.cgi?id=1788193">https://bugzilla.redhat.com/show_bug.cgi?id=1788193</a></div><div>[2] <a href="https://github.com/danalsan/vagrants/tree/master/ovn-playground">https://github.com/danalsan/vagrants/tree/master/ovn-playground</a></div></div>