dissecting DHCP - Q1

David W. Hankins David_Hankins at isc.org
Mon Mar 16 17:15:49 UTC 2009


On Mon, Mar 16, 2009 at 07:55:33AM +0000, Simon Hobson wrote:
> That's odd, unless it's Client-ID (uid in the lease database) has changed, 
> it should be given the same address. That's standard operation for the ISC 
> server, and required by the RFCs.

On a release, the lease goes back to free, and there is no requirement
in the RFC's to hold it for the client.  I'm not even sure the RFC's
require the servers to offer the current active lease.  That's just
the most sensible thing to do.

The RFC's do encourage towards reusing the client's most recent lease.


It would be my suspicion that in this case the servers are running
older (3.0.x) software using failover, /and/ this particular client
LBA's to the secondary.

In this case, the lease follows backup->active->released->free.  The
secondary cannot allocate the free lease, so it selects the next
available backup lease to allocate.

In 3.1.x, I wrote an optimization so that leases whose previous client
LBA's to the secondary are shifted to backup state after they become
free, but only if the secondary does not already have more backup
leases than it should.


So this always remains a possibility, sometimes the server has no real
choice, it's just with different software and approaches you can
change the probability.

-- 
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20090316/08c042d2/attachment.bin>


More information about the dhcp-users mailing list