yahoo-eng-team team mailing list archive

[Assaf Muller <amuller@xxxxxxxxxx>]

Public bug reported:

Create a DVR router, connect it to subnet 'red'. Create a new VM
connected to said subnet on a hypervisor that is currently not hosting
any ports on the subnet. Before creation of the VM, the DVR qrouter
namespace is does not exist. After the creation of the VM, it does.

However, observing
neutron/db/l3_dvrscheduler_db._notify_l3_agent_new_port, we can see that
L3 agents are first notified of new VMs going up for ARP purposes
(l3plugin.dvr_vmarp_table_update), and then L3 agents are notified of
the new VM (l3plugin.dvr_update_router_addvm, which also schedules the
router on the new VM's node). This means that in the ARP notifier, the
router is not scheduled yet on the new hypervisor, so the ARP entries
for that subnet will not be sent to it. We can confirm this by seeing
that the newly created router has no permanent entries in 'ip neigh'.
Reversing the order of notifications (First notify L3 agents of the new
VM, then send the ARP notification) is not a good fix because it's
raceful... It only guarantees that the notification to configure the
router is sent before the ARP RPC message, but not the actual
configuration of the router. This results in the ARP RPC message failing
to complete the 'ip neigh' command because the router doesn't exist yet.

** Affects: neutron
     Importance: Undecided
         Status: New


** Tags: l3-dvr-backlog

** Tags added: l3-dvr-backlog

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1438969

Title:
  DVR router newly created on a node as a result of new VM does not get
  ARP neighbors update

Status in OpenStack Neutron (virtual network service):
  New

Bug description:
  Create a DVR router, connect it to subnet 'red'. Create a new VM
  connected to said subnet on a hypervisor that is currently not hosting
  any ports on the subnet. Before creation of the VM, the DVR qrouter
  namespace is does not exist. After the creation of the VM, it does.

  However, observing
  neutron/db/l3_dvrscheduler_db._notify_l3_agent_new_port, we can see
  that L3 agents are first notified of new VMs going up for ARP purposes
  (l3plugin.dvr_vmarp_table_update), and then L3 agents are notified of
  the new VM (l3plugin.dvr_update_router_addvm, which also schedules the
  router on the new VM's node). This means that in the ARP notifier, the
  router is not scheduled yet on the new hypervisor, so the ARP entries
  for that subnet will not be sent to it. We can confirm this by seeing
  that the newly created router has no permanent entries in 'ip neigh'.
  Reversing the order of notifications (First notify L3 agents of the
  new VM, then send the ARP notification) is not a good fix because it's
  raceful... It only guarantees that the notification to configure the
  router is sent before the ARP RPC message, but not the actual
  configuration of the router. This results in the ARP RPC message
  failing to complete the 'ip neigh' command because the router doesn't
  exist yet.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1438969/+subscriptions