DHCP unicast requests are not responded to
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Compute (nova) |
Confirmed
|
Low
|
Unassigned | ||
nova (Ubuntu) |
Confirmed
|
Low
|
Unassigned |
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://
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/
ii nova-api 1:2015.
ii nova-common 1:2015.
ii nova-compute 1:2015.
ii nova-compute-
ii nova-compute-qemu 1:2015.
ii nova-network 1:2015.
ii nova-novncproxy 1:2015.
ii python-nova 1:2015.
ii python-
ii python-novaclient 1:2.22.
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
Changed in nova: | |
status: | New → Confirmed |
Changed in nova (Ubuntu): | |
status: | New → Confirmed |
Changed in nova: | |
importance: | Undecided → Low |
Changed in nova (Ubuntu): | |
importance: | Undecided → Low |
Revised patch with test.