dhcp fails with big dhcpd.leases

[dorian]

Sorry. I do not understand.
What is illegal or unusual with it?

172.16.8.0 belongs to 172.16.0.0/14
and 172.16.0.0/14 is a part of 172.16.0.0/12 private class

So what does mean 'behave "funny".' ?


> 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!!!" 
>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> dhcp-users mailing list
> dhcp-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/dhcp-users