Watching performance on a DHCP Server

[Simon Hobson]

Enrique Perez-Terron wrote:

>There is another solution:
>
>For each address pool, create an in-memory list of e.g., 20 free
>addresses.  Create a "pre-commit" log entry with these addresses. The
>next 20 requests get served from this smaller pool, without commit to
>disk - except if there is a timeout. When all 20 have been given out (or
>on timeout) commit the leases to disk, and pre-commit a new list of 20
>free addresses.  The timeout may well be the one in the o.s.
>buffercache, i.e., no coding in the server (on suitable platforms).
>
>When the server terminates normally, add a "close" record. Upon reboot,
>rebuild memory and the state of the pool. If there is no close record,
>assume there was a crash. It is not known if the addresses in the latest
>pre-commit entry have been given out, so the server creates dummy leases
>with these addresses, as a way of marking them not available.
>
>This does not work well with many small pools. If pools are too small,
>the pre-commit lists must be smaller. Is that a problem?
>
>A variation of this method without changes to the log file format:
>
>Split the pool in blocks of 32 addresses, e.g. using a "netmask" of 27
>bits. When the server commits to disk a lease with an address within a
>particular such block, then all subsequent lease assignments should go
>from that block until it is exhausted. When that happens, the next lease
>will be given out from another block, and that lease, and all earlier
>uncommitted leases, are committed to disk before the lease is given to
>the client. Further leases from the same block are given to the client
>without commitment to disk.
<snip>

Now consider the case (the normal case for a server that's been 
installed for a while on a busy network) that there are NO unused 
leases at all. Also consider that in the situations mentioned (long 
term power outage), nearly all the clients will have had prior leases.

In both these cases, there is no list of unused leases to 
pre-allocate - if you go ahead and pre-allocate expired leases, then 
you risk violating the protocol by pre-allocating an address that a 
client later wants to come back and use. But the main issue is that 
when these clients with expired leases come back online - do you a) 
give them their old lease back (your method has gained nothing), or 
b) give them a new pre-allocated lease (which brings loads of churn, 
a rush of DNS updates, AND violates the RFC) ?

DHCP is far from being as simple as it looks !