Description of problem:
If allowed address pairs are used and the secondary IP is assigned to a single interface inside a VM. Currently, this will cause issues as described here:
https://bugzilla.redhat.com/show_bug.cgi?id=1818695 

This can be worked around in the case of Octavia by adding it to the ignored_device_owners list. However, this would still impact normal VM's that are using something like keepalived to float the IP address around as required. If the IP address were to be moved, and we were using ignored_device_owners, then the arp cache would never be updated to reflect the move. As such, it would break the HA Nature of the application.

Version-Release number of selected component (if applicable):
openstack-neutron-12.1.1-6.el7ost.noarch

How reproducible:
100%

Steps to Reproduce:
1. Create 2 VM's with allowed-address-pairs and 1 extra Port that matches the allowed-address-pair
2. Configure the extra port IP as a secondary IP on one of the VM's
3. Restart neutron_l3_agent
4. Under current situations this will break as described in https://bugzilla.redhat.com/show_bug.cgi?id=1818695. If we use HA Octavia as an example, we have added Octavia to the ignored_device_owners and fixed the initial problem.
5. Fail-over the FIP to a Standby Device. 


Actual results:
This change will not be updated in the ARP cache, as such the traffic will break. 

Expected results:
The ARP cache needs to be updated in such a way that it takes into account unbound ports and updates the MAC addresses more dynamically to reflect where the IP address actually lives.

Additional info:
This is going to be difficult to preempt since we can't know where the IP address is at any one time. keepalived could choose a host that we are not expecting. As such, the only solution I can think of is to rely on the ARP who-has responses seen on the DVR routers. We could use that response to update the ARP entries on each DVR qrouter namespace.