Comment 28 for bug 1794991

Hi Alexandre,
Yes I might have missed the full text, I just noticed the one that shows up on the activity log.

I read the fulltext now.

So the problem that you mentioned in your log, is that when the Neutron-server and the openvswitch agent is restarted, that would have triggered this problem based on your statement.

"The next question is what triggered the flows to be refreshed/recreated at 22:24?

After some investigation I found that neutron-server and neutron-openvswitch services were restarted around that time."

The unicast-to-tun flow rules are created, when the Actual VM pops up on the compute, when there is a new MAC, that MAC entry will be populated on all the nodes other than the host node that is hosting the VM.
If the VM is already created and the rule is already in place, then by agent-restart we can bringback those roles. Also by enabling and disabling those ports, would trigger a 'Port-up'.

The table 22 rule is the default action or the normal action, where the traffic from the dVR routers should be routed. As and when the vxlan tunnels are added they should be populated in the list of output ports based on the Flood to tun.

This is first populated on the node, when the first port on a particular network shows up. It collects all the vxlan tunnel details for that particular network and adds it to the nodes.

So there is possibility of mismatch happening on a particular node, when the vxlan tunnels are deleted and agent restarted without the neutron-server.

I have always seen things in sync when the neutron-server restarted first and the agent restarted later.

Having understood your problem, the only way that the fdb_add_tun will not be called for add_fdb_flow is when the agent_ports does not exist.

https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/drivers/openvswitch/agent/ovs_neutron_agent.py#L560