[Openstack] DHCP release

David Hill david.hill at ubisoft.com
Mon Mar 25 17:51:03 UTC 2013


Hi guys,

                I've found what the problem is...


1)      nova-dhcpbridge wasn't configured

2)      The version provided with redhat seems to be buggy and I created a bug report: https://bugzilla.redhat.com/show_bug.cgi?id=927349



With the provided version, dhcp-script is called only once at dnsmasq startup and never at IP ack/release.
I've found a package (dnsmasq-2.62-1.el6.rfx.x86_64.rpm) that is more recent and everything is behaving as expected.

Dave




From: Nathanael Burton [mailto:nathanael.i.burton at gmail.com]
Sent: March-23-13 4:15 PM
To: David Hill
Cc: openstack at lists.launchpad.net; Robert Collins
Subject: Re: [Openstack] DHCP release


On Mar 23, 2013 4:02 AM, "David Hill" <david.hill at ubisoft.com<mailto:david.hill at ubisoft.com>> wrote:
>
>
> ________________________________________
> From: Robert Collins [robertc at robertcollins.net<mailto:robertc at robertcollins.net>]
> Sent: March 23, 2013 02:21
> To: David Hill
> Cc: Kevin Stevens; openstack at lists.launchpad.net<mailto:openstack at lists.launchpad.net>
> Subject: Re: [Openstack] DHCP release
>
> On 23 March 2013 14:53, David Hill <david.hill at ubisoft.com<mailto:david.hill at ubisoft.com>> wrote:
> > Hello Kevin,
> >
> > Thanks for replying to my question.   I was asking that question because if we go there: http://docs.openstack.org/trunk/openstack-compute/admin/content/configuring-vlan-networking.html  and look at the very bottom of the page, it suggests the following:
> >
> > # release leases immediately on terminate
> > force_dhcp_release=true? (did I miss something?)
> > # one week lease time
> > dhcp_lease_time=604800
> > # two week disassociate timeout
> > fixed_ip_disassociate_timeout=1209600
> >
> > I tried that and if you have at some creation/destruction of virtual machines, let's say 2046 in the same week, you'll end up burning the 2046 IPs because they're never disassociated.  At some point, nova-network complains with "no more fixed IP are available".  Changing fixed_ip_disassociate_timeout to something smaller solves this issue.
> > Is there any reasons why fixed_ip_disassociate_timeout should be bigger than dhcp_lease_time?
> >
> > Also, I thought that by destroying a virtual machine, it would release/disassociate the IP from the UUID since it has been destroyed (DELETED).  I've turned on the debugging and with fixed_ip_disassociate_timeout set to 600 seocnds, it disassociate stale IPs after they've been deleted for at least 600 seconds.  Is it a bug in our setup/nova-network or nova-network/manage relies on the periodic task that disassociate stale IPs in order to regain those IPs?
> >
> > Finaly, wouldn't it be better to simply disassociate a released IP as soon as the VM is deleted?  Since we deleted the VM, why keep it in the database?
>
> When you reuse an IP address you run the risk of other machines that
> have the IP cached (e.g. as DNS lookup result, or because they were
> configured to use it as a service endpoint) talking to the wrong
> machine. The long timeout is to prevent the sort of confusing hard to
> debug errors that that happen when machine A is replaced by machine C
> on A's IP address.
>
> My 2c: just make your pool larger. Grab 10/8 and have 16M ip's to play with.
>
> -Rob
>
> I'm not the network guy here but, if I use a 10/8 and that we already have 10/8 in our internal network, this could easily become a problem.... am I wrong?
>
> Also, if a VM is deleted, IMHO, it's destroyed with all it's network.     I don't know if this is "old minding" or anything,  but when I destroy a VM in VSphere,  I expect it to disappear leaving no trace.   This is the cloud, and when I delete something,  I expect it to simply be deleted.
>
> My 2c, but I see your point and have nothing against it.
>
>
> Dave
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack at lists.launchpad.net<mailto:openstack at lists.launchpad.net>
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp

David,

I believe the biggest reason for the long timeout is historical based on bugs in dnsmasq [1].  You can probably just use the default of 600 now if you're using a new enough version of dnsmasq.

[1] - https://lists.launchpad.net/openstack/msg11696.html

Thanks,

Nate
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20130325/6140f79e/attachment.html>


More information about the Openstack mailing list