Question about DHCPRELEASE
David W. Hankins
David_Hankins at isc.org
Fri Jul 28 04:19:00 UTC 2006
On Thu, Jul 27, 2006 at 08:37:43PM -0400, Darren wrote:
> 2006-07-27 00:00:00 client does DHCPDISCOVER
> 2006-07-27 00:00:00 server does DHCPOFFER of an IP Address with
> min/default/max lease length of 3600 seconds
Actually, ISC dhcpd will generally answer somewhere between 0 and 1
seconds later, in default configuration. The ping-check does this.
The timer system literally gates on the edge between seconds, so if
the client's packet was received late in the second, very close to
the next second, then the actual amount of time waited is closer to
zero (but never equal of course). Likewise the contrary - if the
client's packet happened to be received very close to the start of
the second, the time between will be very close to 1 second (but
again not quite equal).
> 2006-07-27 00:00:00 client does DHCPREQUEST for that IP Address with a
> 3600 second lease.
> 2006-07-27 00:00:00 server does DHCPACK and creates 3600 secon lease
> for client of that IP Address
> 2006-07-27 00:30:00 client does DHCPREQUEST of that IP Address with a
> 3600 second lease
> 2006-07-27 00:30:00 server does DHCPACK of that IP Address and updates
> the lease begin and end.
> 2006-07-27 00:33:27 client does DHCPRELEASE and removes the IP Address
> from its interface. The server subsequently destroys the lease and marks
> the IP Address as free upon receipt of this packet.
DHCPRELEASE is optional. Very few operating systems do a DHCPRELEASE
when they "think they are done". Most choose to keep their old lease
on the (generally safe) bet that they will need it soon. It speeds
up re-acquisition of the network and causes the DHCP server slightly
ISC dhclient will send a DHCPRELEASE if it is explicitly invoked to do
I know of very few cases where that's actually used, and none of them
are default operating system installs.
Windows for example has a DHCP configuration option you can set that
informs the client that it is expected to release its lease when it
is done with it (eg on shutdown).
I'm not sure if Mac OSX has a similar option.
There is no standard option for this at any rate.
> How does this behavior change in a failover situation, if at all?
Well, once a lease is DHCPRELEASEd, it becomes FREE. That's not
BACKUP. It might stay free, it might move to BACKUP to balance the
pools. The client in question might LBA to the primary or secondary,
and this may not match the state of the lease either way.
So the client might get a different address when it returns.
And the state change doesn't happen until the server is in partner-down
for more than MCLT, or if the two servers agree on the state change (so
it might happen substantially later than when the client indicated).
But even this is the same as if the lease had expired: it's just an
I bring it up mostly because 3.1.0 behaviour will be different: if
the previous client for the lease (the one that just released)
hashes on LBA to the secondary, the primary will queue a new binding
update to move it to BACKUP directly after receiving the
acknowledgement from the peer.
This should reduce churn in the lease pools, leases should return to
FREE and BACKUP states more or less in approximate (if random)
balance, so there should also be less of a need for events to
rebalance the pools.
I guess we'll have to wait to find out how it works out there in
the real world.
David W. Hankins "If you don't do it right the first time,
Software Engineer you'll just have to do it again."
Internet Systems Consortium, Inc. -- Jack T. Hankins
More information about the dhcp-users