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.

./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 

Thanks again,
Graeme

On 2017-05-17 12:24, Graeme Peterson wrote:

> Hi all.
> 
> 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:
> 
> http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2016q1/010273.html
> 
> 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:
> 
> May 16 16:53:15 dnsmasq-dhcp[40394]: 3306068020 DHCPREQUEST(tapc5399cce-70) 
> 132.16.0.13 fa:16:3e:8e:83:97
> May 16 16:53:15 dnsmasq-dhcp[40394]: 3306068020 tags: tag0, known, 
> tapc5399cce-70
> 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
> ...
> ...
> ...
> May 16 16:57:12 dnsmasq-dhcp[40394]: 461988430 available DHCP subnet: 
> 132.16.0.0/255.255.0.0
> 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
> 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 
> 
> I don't see a log entry for a release of 132.16.0.13, not sure if there 
> should be one.
> 
> Is this a known and hopefully fixed issue? Can I provide further info to help 
> investigate it?
> 
> Thanks,
> Graeme 
> _______________________________________________
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss@lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
_______________________________________________
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Reply via email to