dhcpd lease problems?
adekok at infoblox.com
Wed Jun 7 18:53:31 UTC 2006
David W. Hankins wrote:
> In vast, vast excess of the effective hash table size on that version
> of software (even if you increase the table size).
> 1% (6-4 = 2) of the leases utilized is a fairly inapplicable-to-production
It was production data, where the customer had concerns. Not
typical, perhaps, but something we looked at.
> Another thing that will probably surprise you: dhcpd.leases sizes for
> folks on the order of magnitude we're talking about are more on the
> order of 30-40 MB for 10^5 leases. So assuming 10^6 leases, we're
> talking more about 300-400 MB...not merely 1.
That is surprising.
> [ hash table size work-arounds ]
> No, but you're using it as an argument for your case for dynamically
> allocating lease structures during runtime.
> It doesn't follow.
For most situations, yes. For the original production case we ran
into, updating the hash *and* the use of it helped enormously.
> It very clearly to me would violate the failover draft in terms of
> compatibility with other implementations if we suddenly deleted a leased
> out of the middle of a pool simply because someone allocated it to fixed
> But then what do you propose should be done when a host entry is added
> during runtime (a feature we already have today)?
"When in danger, or in doubt, run in circles, scream and shout."
enter_host() doesn't delete the dynamic leases, so the current
behavior is to keep the dynamic lease, including exchanging it in
failover. It won't be used, because hosts take precedence, but it will
be exchanged and managed as part of failover.
More information about the dhcp-users