dhcp fails with big dhcpd.leases

[Sten Carlsen]

 You showed that your range also had 172.16.8.0 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 172.16.221.214 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 172.16.215.48 to 00:19:d2:97:ca:81
>> (N0336) via br0
>> Aug 31 15:34:34 [dhcpd] DHCPREQUEST for 192.168.1.101 from
>> 00:23:6c:2b:08:eb via br0: wrong network.
>> Aug 31 15:34:34 [dhcpd] DHCPNAK on 192.168.1.101 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 172.16.221.214 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:

       "MALE BOVINE MANURE!!!" 

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