dhcpd lease problems?

Alan DeKok adekok at infoblox.com
Tue Jun 6 22:45:15 UTC 2006

David W. Hankins wrote:
> If at some point, the complaint I hear from the user community is that
> the server does not start up slow enough, then I will consider
> encumbering the server startup logic.  As it stands, I hear the converse
> fairly loudly.

   Our analysis using "callgrind" indicates that 90% or more of start 
time is new_address_range().  Most of that is the checks for overlapping 
ranges, by looking up each newly allocated lease in the 
lease_ip_addr_hash.  Given the fixed size of the hash table, the result 
is pretty much O(N^2) in the number of managed leases.

   Hence the long startup time.

   If, instead, the leases are allocated as needed, DHCPOFFER's would 
down a bit.  But since the server is already limited by sync's and 
syslog, the extra call to lease_allocate() wouldn't matter much.

> In the world where you have a dhcp daemon which is dynamically given
> its dynamic pool ranges (eg via something resembling OMAPI, but not),
> it is simply not a good idea to permit lease structures to remain around
> forever.

   Once the leases are allocated as needed, rather than in one big 
block,  free'ing leases becomes trivial.  The contiguous allocation & 
initialization is causing the slow startup time, *and* the inability to 
free leases.

> There is simply no compelling reason for this complexity, considering
> that reserved dynamic lease are not only what's being asked for, but
> are already completed.

   I'm not clear on the difference between the current hosts, and 
reserved dynamic leases.  Is it just that the reserved dynamic leases 
inherit the pool & range properties, where hosts don't?

   Alan DeKok.

More information about the dhcp-users mailing list