dhcp fails with big dhcpd.leases

Sten Carlsen stenc at s-carlsen.dk
Tue Aug 31 16:41:58 UTC 2010

 You showed that your range also had in it, that is valid but
may cause some clients to behave "funny".

On 31/08/10 17:32, Simon Hobson wrote:
> dorian wrote:
>> Aug 31 15:34:26 [dhcpd] DHCPDISCOVER from 00:23:6c:73:b3:29 (AMs-iPhone)
>> via br0
>> Aug 31 15:34:26 [dhcpd] DHCPOFFER on to 00:23:6c:73:b3:29
>> (AMs-iPhone) via br0
>> Aug 31 15:34:33 [dhcpd] DHCPDISCOVER from 00:19:d2:97:ca:81 (N0336)
>> via br0
>> Aug 31 15:34:33 [dhcpd] DHCPOFFER on to 00:19:d2:97:ca:81
>> (N0336) via br0
>> Aug 31 15:34:34 [dhcpd] DHCPREQUEST for from
>> 00:23:6c:2b:08:eb via br0: wrong network.
>> Aug 31 15:34:34 [dhcpd] DHCPNAK on to 00:23:6c:2b:08:eb
>> via br0
>> Aug 31 15:34:34 [dhcpd] DHCPDISCOVER from 00:23:6c:73:b3:29 (AMs-iPhone)
>> via br0
>> Aug 31 15:34:34 [dhcpd] DHCPOFFER on to 00:23:6c:73:b3:29
>> (AMs-iPhone) via br0
>> ...
>> so it is clearly visible that in case of the failure there is no
>> DHCPACK  packets.
> Actually, that log snippet shows no such thing. There is only ONE
> DHCP-Request, to which the server responds with a DHCP-Nack as the
> requested address is not valid. There are no more Requests from
> clients and hence there should be no more Acks to go with them.
> What I do see are a number of DHCP-Offers which don't result in a
> DHCP-Request from clients. You need to be looking at why this is the
> case - are you sure there are no other (probably rogue) servers on the
> subnet ?
>> 2. the dhcpd.leases file size is the reason (or is it the only reason)?
> No, it won't even be related to the problem - unless you are running
> out of disk space or have other storage problems.
> The leases file is a log file - the server only ever appends to it,
> and during operations it never reads from it. It is only ever read
> during startup when it reads each lease in turn and populates it's
> internal tables. Even then, it does not (I assume) read the file into
> memory - it just has to parse each lease as it munches through the file.
> To avoid the file growing ever larger, the server will periodically
> clean up. It does this by writing out it's current in-memory tables to
> a new leases file, and swapping it into place by renaming the original
> file and then renaming the new file into place.

Best regards

Sten Carlsen

No improvements come from shouting:


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20100831/f6ac810e/attachment.html>

More information about the dhcp-users mailing list