DHCPNAK after neutron-dhcp-agent restart

Bug #1487626 reported by Andrew Woodward
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Mirantis OpenStack
Invalid
High
Andrew Woodward
6.0.x
Invalid
High
Andrew Woodward
6.1.x
Invalid
High
Alexey Khivin

Bug Description

(backport of https://bugs.launchpad.net/neutron/+bug/1345947)

After rolling out a configuration change, we restarted neutron-dhcp-agent service, and then dnsmasq logs start flooding: DHCPNAK ... lease not found.
DHCPNAK is replied by dnsmasq for all DHCPREQUEST renews from all VMs. However the MAC and IP pairs exist in host files.
The log flooding increases when more and more VMs start renewing and they keep retrying until IP expire and send DHCPDISCOVER and reinit the IP.
The log flooding gradually disappears when the VMs IP expire and send DHCPDISCOVER, to which dnsmasq respond DHCPOFFER properly.

Analysis:
I noticed that option --leasefile-ro is used in dnsmasq command when started by neutron dhcp-agent. According to dnsmasq manual, this option should be used together with --dhcp-script to customize the lease database. However, the option --dhcp-script was removed when fixing bug 1202392.
Because of this, dnsmasq will not save lease information in persistent storage, and when it is restarted, lease information is lost.

Solution:
Simply replace --leasefile-ro by --dhcp-leasefile=<path to dhcp runtime files>/lease would solve the problem. (patch attached)

Andrew Woodward (xarses)
Changed in mos:
status: Confirmed → New
milestone: none → 7.0
Revision history for this message
Sergey Kolekonov (skolekonov) wrote :

The fix for this bug is available in upstream stable/kilo branch and has been already backported to MOS.
The commit is https://github.com/openstack/neutron/commit/c07687c985703609ccc80f0151a2a40e2036a3f4

Revision history for this message
Oleg Bondarev (obondarev) wrote :

Was it reproduced on MOS 7.0?

Changed in mos:
status: New → Incomplete
Revision history for this message
Vitaly Sedelnik (vsedelnik) wrote :

Andrew - please confirm this issues affects MOS 7.0 and provide exact steps to reproduce. Note, that per comment #1 the backport you are requesting is already in the 7.0 branch.

Changed in mos:
assignee: MOS Neutron (mos-neutron) → Andrew Woodward (xarses)
Revision history for this message
Andrew Woodward (xarses) wrote :

@Vitaly,

If the patch is already in 7.0 then it's resolved for 7. Status was New in order for someone to check

(It was reproduced in 6 so added confirmed there and new for 7)

Changed in mos:
status: Incomplete → Invalid
Revision history for this message
Denis Meltsaykin (dmeltsaykin) wrote :

Andrew, was the bug reproduced in 6.1 release or 6.0? 6.1 contains already the fix you've mentioned.

Revision history for this message
Alexey Khivin (akhivin) wrote :
Revision history for this message
Denis Meltsaykin (dmeltsaykin) wrote :

Andrew, could you clarify is this a customer-found bug and what are affected releases?

Revision history for this message
Eugene Nikanorov (enikanorov) wrote :

6.1+ are not affected since we are providing lease database to each dhcp server (dnsmasq).

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.