yahoo-eng-team team mailing list archive

[Arnaud Morin <2002417@xxxxxxxxxxxxxxxxxx>]

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