<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /></head><body style='font-size: 10pt; font-family: Arial,Helvetica,sans-serif'>
<p>I found the following entry in /var/log/auth.log which shows neutron as root (sudo) calling dhcp_release on IP: 132.16.0.13, MAC: fa:16:3e:8e:83:97 two minutes after the DHCPACK and two minutes before the dnsmasq-dhcp log failure saying: "not using configured address 132.16.0.13 because it is leased to fa:16:3e:8e:83:97". Looks to me like Openstack is calling dhcp_release correctly. The dnsmask log is in a folder named "34705fcf-4f9c-48eb-b0bc-ac5091e181c8", same as the arg to ip netns exec without the "qdhcp-" prefix. So far it looks like a dhcp_release/dnsmasq issue to my untrained eye. I have been able to work around it somewhat by setting the max lease time to 30 seconds, although that seems to be introducing other issues, more investigation required there.<br /><br />./auth.log:May 16 16:55:21 my-ucs-69 sudo: neutron : TTY=unknown ; PWD=/var/lib/neutron ; USER=root ; COMMAND=/usr/bin/neutron-rootwrap /etc/neutron/rootwrap.conf ip netns exec qdhcp-34705fcf-4f9c-48eb-b0bc-ac5091e181c8 dhcp_release tapc5399cce-70 132.16.0.13 fa:16:3e:8e:83:97</p>
<p>Thanks again,<br />Graeme<br /><br /></p>
<p>On 2017-05-17 12:24, Graeme Peterson wrote:</p>
<blockquote type="cite" style="padding: 0 0.4em; border-left: #1010ff 2px solid; margin: 0"><!-- html ignored --><!-- head ignored --><!-- meta ignored -->
<p>Hi all.<br /><br />Sorry if this issue has been discussed and resolved, I am new to the list. I tried to find it in the list, and came across this reference to the issue from Jan 2016:<br /><br /><a href="http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2016q1/010273.html">http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2016q1/010273.html</a><br /><br /><br />What I am seeing is with OpenStack Newton on Ubuntu 16.10 (4.8.0-49-generic), with force_dhcp_release=True in /etc/nova/nova.conf, using tcpdump on the netns for the relevant Openstack network, I see dnsmasq receives the dhcp request, issues an IP, and that IP should be released (Openstack should be calling dhcp_release, I need to figure out how to verify that it is or is not happening, however force_dhcp_release=True is explicitly set in /etc/nova/nova.conf) , but it seems like the dhcp entry isn't being entirely released. The odd thing is that when a new VM wants an IP, tcpdump shows the request coming in for an address, but no reply, and OpenStack thinks it got an IP - the same one that used to belong to the recently terminated VM - but there is no dhcp offer in the tcpdump, and the dnsmasq log shows:<br /><br />May 16 16:53:15 dnsmasq-dhcp[40394]: 3306068020 DHCPREQUEST(tapc5399cce-70) 132.16.0.13 fa:16:3e:8e:83:97<br />May 16 16:53:15 dnsmasq-dhcp[40394]: 3306068020 tags: tag0, known, tapc5399cce-70<br />May 16 16:53:15 dnsmasq-dhcp[40394]: 3306068020 DHCPACK(tapc5399cce-70) 132.16.0.13 fa:16:3e:8e:83:97 host-132-16-0-13<br />...<br />...<br />...<br />May 16 16:57:12 dnsmasq-dhcp[40394]: 461988430 available DHCP subnet: 132.16.0.0/255.255.0.0<br />May 16 16:57:12 dnsmasq-dhcp[40394]: not using configured address 132.16.0.13 because it is leased to fa:16:3e:8e:83:97<br />May 16 16:57:12 dnsmasq-dhcp[40394]: 461988430 DHCPDISCOVER(tapc5399cce-70) 192.168.0.51 fa:16:3e:31:de:d3 no address available</p>
<p>I don't see a log entry for a release of 132.16.0.13, not sure if there should be one.<br /><br /><br />Is this a known and hopefully fixed issue? Can I provide further info to help investigate it?<br /><br />Thanks,<br />Graeme</p>
<!-- html ignored --><br />
<div class="pre" style="margin: 0; padding: 0; font-family: monospace">_______________________________________________<br /> Dnsmasq-discuss mailing list<br /><a href="mailto:Dnsmasq-discuss@lists.thekelleys.org.uk">Dnsmasq-discuss@lists.thekelleys.org.uk</a><br /><a href="http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss">http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss</a></div>
</blockquote>
</body></html>