Dhclient makes system unresponsive with very short leases
Ted.Lemon at nominum.com
Tue May 12 16:02:00 UTC 2009
On May 12, 2009, at 8:49 AM, David W. Hankins wrote:
> The patch appears to enforce a 60 second minimum lease time, which is
> not described in any IETF RFC. I suspect imposing one would be met
> with some resistance.
Generally our experience has been that lease times shorter than about
30 seconds work really badly. Your point about /var filling up is
correct, but that's not the whole problem. DHCP was never intended
to support leases this short, and none of the infrastructure it
depends on or that depends on it really works in this context. E.g.,
TCP and DNS timeouts tend to be in the 90 second range, so when you go
shorter than that on a lease, does that even make sense?
I think the 60 second minimum lease time is not unreasonable.
However, the way I would address it is for the client to discard any
DHCPOFFER or DHCPACK it receives that offers a lease that's shorter
than 60 seconds. You can't simply unilaterally decide to keep the
lease for longer than the server offered.
By the way, when you get a two-second lease, it's very likely the
client will compute a renewal time of zero, because it's using integer
math. We "fixed" this in DHCPv6 by specifying intervals in
milliseconds, but DHCPv4 just uses seconds. So you could probably
make the client behave more correctly on two-second leases by tweaking
the way it does the math to compute the renewal time.
More information about the dhcp-users