Comment 4 for bug 1864822

It is that first flow, the 'drop' flow, that is responsible for the issue. I am having a similar issue in a Stein environment and am trying to reproduce in a lab. That drop flow is implemented shortly after the disconnect observed in the logs.

Do you see a log message like this in the neutron-openvswitch-agent.log file?

> "Physical bridge br-ex was just re-created"

Shortly after that message, the drop flow is implemented and the cookies are changed for a subset of the flows. A restart of the agent only temporarily addresses the issue.

I am not positive, but think this patch may have something to do with it:

https://github.com/openstack/neutron/commit/8d8f66eddd43658e59de157dfcbd0f9dc9c716c6#diff-9cca2f63ca397a7e93909a7119fdd16f

To address this temporarily, I made this change to the ovs agent code:

--- ovs_neutron_agent.py 2020-02-22 20:23:43.606606000 +0100
+++ ovs_neutron_agent.py.mod 2020-02-23 00:25:01.014768189 +0100
@@ -2223,7 +2223,7 @@
             # Check if any physical bridge wasn't recreated recently
             added_bridges = idl_monitor.bridges_added + self.added_bridges
             bridges_recreated = self._reconfigure_physical_bridges(
- added_bridges)
+ idl_monitor.bridges_added)
             sync |= bridges_recreated
             # Notify the plugin of tunnel IP
             if self.enable_tunneling and tunnel_sync:

So far, it's working as expected. Still trying to find the root cause.