Entries in dhcpd.leases file

[Simon Kelley]

Simon Hobson wrote:
> Usman Wahid wrote:
> 
> 
>>I am using the latest version of ISC DHCP V3.0.4. I have noticed that 
>>dhcpd logs leases in lease database even if a client has not accepted 
>>its offer. Like when they are more than one DHCP server on a network 
>>and client can choose IP from one of them. Is there a configuration 
>>option that will force DHCP to only log its accepted offers (in other
>>words, those for which it sends DHCPACKs).
> 
> 
> Short answer: No, that would break a requirement of the protocol specification.
> 
> Longer explanation: It is a requirement that all lease offers are 
> written to permanent storage before being offered to the client - 
> that is so that should the power fail, server crash, or whatever, the 
> network isn't left with client that believe they have a lease but the 
> lease is unknown to the server.

Simon, I'm picking a nit which makes no difference to the bulk of your 
explanation.

I don't think the above is quite right: there's no requirement for the 
server to keep track of DHCP _offers_ in order to keep the clients and 
servers in sync, only DHCP _acks_. If a server offers an address and 
then promptly forgets all about it, the worst that can happen is that 
the client subsequently requests that address and gets a NAK, causing it 
to re-start the address aquisition cycle. The reason that the server 
keeps track of offers is to ensure that it doesn't offer the same 
address to more than one client in the time-window between an address 
being offered, and finally requested and ACKed. From RFC2131:

       Because
       the servers have not committed any network address assignments on
       the basis of a DHCPOFFER, servers are free to reuse offered
       network addresses in response to subsequent requests.  As an
       implementation detail, servers SHOULD NOT reuse offered addresses
       and may use an implementation-specific timeout mechanism to decide
       when to reuse an offered address.

The two minute leases are the dhcpd way of implementing the SHOULD NOT.

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


Cheers,

Simon.