Entries in dhcpd.leases file
adekok at infoblox.com
Fri May 26 18:32:18 UTC 2006
Simon Kelley wrote:
> By contrast, dnsmasq doesn't make a change of server state when it sends
> an OFFER, but the offered address is calculated as a hash from the
> client MAC address. This ensures that addresses are not re-used except
> when the hash algorithm collides.
This works if the range is largely empty. If the range is nearly
full, then the mac->IP hash doesn't help, because it's cheaper just to
scan the free list. And if the range is nearly full, then it's much
more important to save the OFFER with a temporary lease, because it's
likely that many people are asking for leases in a small time period.
Not tracking the offers in that scenario would mean that many people
would get the offer, and you have a race condition. So most people
would go through many OFFER, ACK, NACK stages before getting a lease.
If dnsmasq *doesn't* have an option to remember OFFERs (I haven't
looked), then it probably will fail in awkward ways when the range is
> In the case of a hash collision,
> dnsmasq takes advantage of the "free to reuse" language to stay within
> spec. (at least, I contend that it's within spec and nobody has ever
> demonstrated otherwise!)
> As always, there's More Than One Way To Do It.
This is an optimization that works in some cases, but not in others,
like most optimizations.
More information about the dhcp-users