DVR+HA routers all answering to ping on private interface

[Arnaud Morin]

When using HA routers, the qr-xzy link interface in qrouter-namespace is set UP/DOWN based on keepalived status change.

When using DVR+HA routers, with 2 network nodes (in dvr_snat mode), the qr-xzy interface in qrouter-namespace is NOT managed anymore by keepalived. In fact, keepalived is running in a snat-namespace and have no access to this qr-xzy interface.

The result is that the qr-xyz link interface is always UP in qrouter-namespace, even if the router in in standby/backup mode.

The result is that, if any other equipment (e.g. ironic node) in the private network is trying to ping the qr-xyz IP address (e.g. 192.168.43.1), then both routers are answering:
$ arping -c1 192.168.43.1
ARPING 192.168.43.1
60 bytes from fa:16:3f:67:97:6a (192.168.43.1): index=0 time=634.700 usec
60 bytes from fa:16:3f:dc:67:91 (192.168.43.1): index=1 time=750.298 usec

--- 192.168.43.1 statistics ---
1 packets transmitted, 2 packets received, 0% unanswered (1 extra)

Note 1: a topic was starting on openstack-discuss regarding this issue:
https://lists.openstack.org/pipermail/openstack-discuss/2022-December/031480.html

Note 2: this bug describes only the "snat" (network node) part of the issue. DVR is also running on hypervisors, this will eventually be discussed in another bug.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.opendev.org/c/openstack/neutron/+/869741

[OpenStack Infra (hudson-openstack)]

Change abandoned by "Slawek Kaplonski <email address hidden>" on branch: master
Review: https://review.opendev.org/c/openstack/neutron/+/869741
Reason: This review is > 4 weeks without comment, and failed Zuul jobs the last time it was checked. We are abandoning this for now. Feel free to reactivate the review by pressing the restore button and leaving a 'recheck' comment to get fresh test results.