I created a revert for the patch [1] mentioned in the bug description.
As the commit meassage says, all those changes are now not necessary anymore. Because the final approach [2] will not be accepted in current implementation way.
@Brian, the problem is if neutron uses ``bagpipe_bgpvpn`` to populate the L2 entry (IP+mac+ vxlan vni). The arp responder flows and tunnel direct flows will be covered by that mechanism. But after patch 669938, ovs-agent will not be allowed to do that. Since if you enable DVR, the "arp_responder" and "l2_population" are enforced.
I created a revert for the patch [1] mentioned in the bug description.
As the commit meassage says, all those changes are now not necessary anymore. Because the final approach [2] will not be accepted in current implementation way.
@Brian, the problem is if neutron uses ``bagpipe_bgpvpn`` to populate the L2 entry (IP+mac+ vxlan vni). The arp responder flows and tunnel direct flows will be covered by that mechanism. But after patch 669938, ovs-agent will not be allowed to do that. Since if you enable DVR, the "arp_responder" and "l2_population" are enforced.
[1] https:/ /review. opendev. org/c/openstack /neutron/ +/778820 /review. opendev. org/c/openstack /neutron/ +/601336
[2] https:/