Comment 18 for bug 1866445

Hi, sorry for the late reply.
The fix of bug #1732067 has a config option ``explicitly_egress_direct`` [1] which is for non-OVS firewall.
Please have a try to add the following config option to your compute nodes to see if the flooding still happen:
[agent]
...
explicitly_egress_direct = True

The fix has a flow which direct the unicast from br-int to tunnel/physical bridge, something like this:
able=61, n_packets=0, n_bytes=0, priority=10,in_port="qr-7fae49a8-f9",dl_src=fa:16:3e:c6:ca:b2,dl_dst=00:00:00:00:00:00/01:00:00:00:00:00 actions=mod_vlan_vid:2,output:"patch-tun"
table=61, n_packets=0, n_bytes=0, priority=10,in_port="tapfc769b36-d8",dl_src=fa:16:3e:d6:c4:37,dl_dst=00:00:00:00:00:00/01:00:00:00:00:00 actions=mod_vlan_vid:3,output:"patch-tun"
table=61, n_packets=0, n_bytes=0, priority=10,in_port="tap6d0aedf5-65",dl_src=fa:16:3e:21:40:16,dl_dst=00:00:00:00:00:00/01:00:00:00:00:00 actions=mod_vlan_vid:1,output:"patch-tun"
table=61, n_packets=0, n_bytes=0, priority=10,in_port="qr-0ae0e877-1f",dl_src=fa:16:3e:5b:8e:90,dl_dst=00:00:00:00:00:00/01:00:00:00:00:00 actions=mod_vlan_vid:3,output:"patch-tun"
table=61, n_packets=0, n_bytes=0, priority=10,in_port="qr-0d184ea8-f9",dl_src=fa:16:3e:52:39:08,dl_dst=00:00:00:00:00:00/01:00:00:00:00:00 actions=mod_vlan_vid:2,output:"patch-tun"
table=61, n_packets=0, n_bytes=0, priority=10,in_port="qr-04bfb1fd-d3",dl_src=fa:16:3e:11:d1:47,dl_dst=00:00:00:00:00:00/01:00:00:00:00:00 actions=mod_vlan_vid:3,output:"patch-tun"

so these test cases should not happen:

* For example L2 flooding, vm1(sub1, host1), vm2(sub1, host1), vm3(sub1, host2).
  Ping from vm1 to vm3, the vm2 can also grab packets.

* For example L3 flooding, vm1(sub1, host1), vm4(sub2, host1), vm5(sub2, host2).
  Ping from vm1 to vm5, the vm4 can also grab packets.

[1] https://review.opendev.org/#/c/710183/4/releasenotes/notes/accepted_egress_direct-cc23873e213c6919.yaml@18