yahoo-eng-team team mailing list archive

[Kelvin Koh <1554227@xxxxxxxxxxxxxxxxxx>]

Public bug reported:

Issue:
We run nova-network in VLAN+multi_host mode on Kilo and notice that only one dnsmasq process (either the oldest or newest) on the hypervisor responds to unicast BOOTPREQUESTS. dhclient on VMs will retry until it eventually gives up and broadcasts the request, which is then responded to. Depending on the timing of the DHCP broadcast request, VMs can briefly lose connectivity as they attempt rebinding.

According to
http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commitdiff;h=9380ba70d67db6b69f817d8e318de5ba1e990b12,
it seems that passing "--interface" argument, in addition to "--bind-
interfaces" is necessary for dnsmasq to work correctly in VLAN mode.


Reproduce steps:
1. Create two tenants
2. Create a VM under each tenant, forcing the VMs to run on a single hypervisor. I tested with a vanilla Ubuntu cloud image, but any other image that uses dhclient should also work.
3. On the hypervisor, run dhcpdump -i <bridge interface> for each tenant's bridge interface. On at least one of them, you should see unicast BOOTPREQUEST with no corresponding BOOTPREPLY. dnsmasq will reply when the request eventually hits 255.255.255.255.


Nova/Openstack/dnsmasq versions:
ii  nova-api                             1:2015.1.2-0ubuntu2~cloud0            all          OpenStack Compute - API frontend
ii  nova-common                          1:2015.1.2-0ubuntu2~cloud0            all          OpenStack Compute - common files
ii  nova-compute                         1:2015.1.2-0ubuntu2~cloud0            all          OpenStack Compute - compute node base
ii  nova-compute-libvirt                 1:2015.1.2-0ubuntu2~cloud0            all          OpenStack Compute - compute node libvirt support
ii  nova-compute-qemu                    1:2015.1.2-0ubuntu2~cloud0            all          OpenStack Compute - compute node (QEmu)
ii  nova-network                         1:2015.1.2-0ubuntu2~cloud0            all          OpenStack Compute - Network manager
ii  nova-novncproxy                      1:2015.1.2-0ubuntu2~cloud0            all          OpenStack Compute - NoVNC proxy
ii  python-nova                          1:2015.1.2-0ubuntu2~cloud0            all          OpenStack Compute Python libraries
ii  python-nova-adminclient              0.1.8-0ubuntu2                        amd64        client for administering Openstack Nova
ii  python-novaclient                    1:2.22.0-0ubuntu2~cloud0              all          client library for OpenStack Compute API
ii  dnsmasq-base                         2.68-1ubuntu0.1                       amd64        Small caching DNS proxy and DHCP/TFTP server
ii  dnsmasq-utils                        2.68-1ubuntu0.1                       amd64        Utilities for manipulating DHCP leases

** Affects: nova
     Importance: Undecided
         Status: New

** Patch added: "nova-network-dnsmasq-vlan.patch"
   https://bugs.launchpad.net/bugs/1554227/+attachment/4591903/+files/nova-network-dnsmasq-vlan.patch

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1554227

Title:
  DHCP unicast requests are not responded to

Status in OpenStack Compute (nova):
  New

Bug description:
  Issue:
  We run nova-network in VLAN+multi_host mode on Kilo and notice that only one dnsmasq process (either the oldest or newest) on the hypervisor responds to unicast BOOTPREQUESTS. dhclient on VMs will retry until it eventually gives up and broadcasts the request, which is then responded to. Depending on the timing of the DHCP broadcast request, VMs can briefly lose connectivity as they attempt rebinding.

  According to
  http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commitdiff;h=9380ba70d67db6b69f817d8e318de5ba1e990b12,
  it seems that passing "--interface" argument, in addition to "--bind-
  interfaces" is necessary for dnsmasq to work correctly in VLAN mode.

  
  Reproduce steps:
  1. Create two tenants
  2. Create a VM under each tenant, forcing the VMs to run on a single hypervisor. I tested with a vanilla Ubuntu cloud image, but any other image that uses dhclient should also work.
  3. On the hypervisor, run dhcpdump -i <bridge interface> for each tenant's bridge interface. On at least one of them, you should see unicast BOOTPREQUEST with no corresponding BOOTPREPLY. dnsmasq will reply when the request eventually hits 255.255.255.255.

  
  Nova/Openstack/dnsmasq versions:
  ii  nova-api                             1:2015.1.2-0ubuntu2~cloud0            all          OpenStack Compute - API frontend
  ii  nova-common                          1:2015.1.2-0ubuntu2~cloud0            all          OpenStack Compute - common files
  ii  nova-compute                         1:2015.1.2-0ubuntu2~cloud0            all          OpenStack Compute - compute node base
  ii  nova-compute-libvirt                 1:2015.1.2-0ubuntu2~cloud0            all          OpenStack Compute - compute node libvirt support
  ii  nova-compute-qemu                    1:2015.1.2-0ubuntu2~cloud0            all          OpenStack Compute - compute node (QEmu)
  ii  nova-network                         1:2015.1.2-0ubuntu2~cloud0            all          OpenStack Compute - Network manager
  ii  nova-novncproxy                      1:2015.1.2-0ubuntu2~cloud0            all          OpenStack Compute - NoVNC proxy
  ii  python-nova                          1:2015.1.2-0ubuntu2~cloud0            all          OpenStack Compute Python libraries
  ii  python-nova-adminclient              0.1.8-0ubuntu2                        amd64        client for administering Openstack Nova
  ii  python-novaclient                    1:2.22.0-0ubuntu2~cloud0              all          client library for OpenStack Compute API
  ii  dnsmasq-base                         2.68-1ubuntu0.1                       amd64        Small caching DNS proxy and DHCP/TFTP server
  ii  dnsmasq-utils                        2.68-1ubuntu0.1                       amd64        Utilities for manipulating DHCP leases

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