Comment 14 for bug 1849479

We also have similar issue. I suppose the l2pop is responsible.
In our case the OVS br-tun 22 table is not properly configured:

cookie=0x161e6c4bed4713c7, duration=8446.269s, table=22, n_packets=508, n_bytes=29903, priority=1,dl_vlan=35 actions=strip_vlan,load:0x9e->NXM_NX_TUN_ID[],output:"vxlan-0ad30035",output:"vxlan-0ad30030",output:"vxlan-0ad3004c",output:"vxlan-0ad3001e",output:"vxlan-0ad30025",output:"vxlan-0ad30010",output:"vxlan-0ad3000f",output:"vxlan-0ad3000e",output:"vxlan-0ad30016",output:"vxlan-0ad3001c",output:"vxlan-0ad3003f",output:"vxlan-0ad3003c",output:"vxlan-0ad30040",output:"vxlan-0ad30041"

The output ports list is not complete, it lacks some compute nodes where VMs attached to the same virtual network are running.
Sometimes it lacks output ports towards network nodes where DHCP servers are running.

Restarting neutron-openvswitch-agent fixes the OVS entry and resolves the issue.