Public bug reported: 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. ** Affects: neutron Importance: Undecided Assignee: Arnaud Morin (arnaud-morin) Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/2002417 Title: DVR+HA routers all answering to ping on private interface Status in neutron: New Bug description: 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. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/2002417/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : [email protected] Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
