Dhclient makes system unresponsive with very short leases

David W. Hankins David_Hankins at isc.org
Wed May 13 17:46:13 UTC 2009


On Tue, May 12, 2009 at 09:02:00AM -0700, Ted Lemon wrote:
> Generally our experience has been that lease times shorter than about 30 
> seconds work really badly.   Your point about /var filling up is correct, 

I use 10 second lease times in our lab to increase traffic and
excercise the software faster.  It works really well.

I'm not prepared to say that a given lease time N is inapplicable to
all use cases forevermore.

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

That's right, the randomization will round down from 2/2=1 to 0.  I
had thought the user was reporting 1-second renewals filling up logs
and var.

We took a conservative approach in terms of amount of change when we
put microsecond timing in the event system.  I think lease expiration
timers need to use whole seconds on the client, as it is also likely
the server is rounding down as well (and your only vain hope for
accuracy is that both systems are using a network clock source), but
renewal and rebinding timers could probably be reworked to use
microseconds to keep the fraction rather than rounding down.  The
server could use microseconds to schedule lease expiration time, but
then we'd need to extend failover and our configuration language
(which also parses dhcpd.leases) to express them...probably not worth
the trouble.


Failing to respond to a DHCPOFFER is vaguely described in RFC 2131, it
is stipulated the client will undertake a selection process, but I've
never been comfortable with the lack of specification for that
process (unlike RFC 3315 which gives several hints at least, even if
it doesn't define one - at least here, you can imagine a process, and
then document it in a later rfc), nor with the consequence of
de-selecting a lease; which is that the DHCP server operator has
absolutely no feedback to know why a client does not wish to accept
its offer.  Did it even get the packet?  This is an issue in 3315 as
well.

So we could start filtering out offers based upon some rules like
these, but I think it has to be hand in hand with an RFC describing
that (de-)selection process...

And you really have to squint at a client that discards an ack.

-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		     you'll just have to do it again."
Internet Systems Consortium, Inc.		-- Jack T. Hankins
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20090513/cc17320c/attachment.bin>


More information about the dhcp-users mailing list