dhcp fails with big dhcpd.leases

dorian dorian33 at o2.pl
Tue Aug 31 18:08:42 UTC 2010


Additional info below
> 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 ?
>
>
Here is a little bit longer another log snippet
Aug 31 13:51:47 [dhcpd] DHCPDISCOVER from 7c:c5:37:21:d9:7c via br0
Aug 31 13:51:47 [dhcpd] DHCPOFFER on 172.18.93.227 to 7c:c5:37:21:d9:7c
via br0
Aug 31 13:51:49 [dhcpd] DHCPDISCOVER from 00:23:14:c0:61:28 (BLU060) via br0
Aug 31 13:51:49 [dhcpd] DHCPOFFER on 172.18.90.186 to 00:23:14:c0:61:28
(BLU060) via br0
Aug 31 13:51:50 [dhcpd] DHCPDISCOVER from 00:25:d3:d8:71:1c
(Malgos-Komputer) via br0
Aug 31 13:51:50 [dhcpd] DHCPOFFER on 172.18.93.236 to 00:25:d3:d8:71:1c
(Malgos-Komputer) via br0
Aug 31 13:51:51 [dhcpd] DHCPDISCOVER from 00:18:41:c7:6c:01
(Touch_Diamond) via br0
Aug 31 13:51:51 [dhcpd] DHCPOFFER on 172.19.228.144 to 00:18:41:c7:6c:01
(Touch_Diamond) via br0
Aug 31 13:51:55 [dhcpd] DHCPREQUEST for 172.27.140.7 from
00:18:51:ce:b3:69 via br0: unknown lease 172.27.140.7.
Aug 31 13:51:56 [dhcpd] DHCPDISCOVER from 7c:c5:37:21:d9:7c via br0
Aug 31 13:51:56 [dhcpd] DHCPOFFER on 172.18.93.227 to 7c:c5:37:21:d9:7c
via br0
Aug 31 13:51:59 [dhcpd] DHCPDISCOVER from 00:25:d3:d8:71:1c
(Malgos-Komputer) via br0
Aug 31 13:51:59 [dhcpd] DHCPOFFER on 172.18.93.236 to 00:25:d3:d8:71:1c
(Malgos-Komputer) via br0
Aug 31 13:52:01 [dhcpd] DHCPDISCOVER from 00:25:bc:0e:09:83
(iPhone-SZAST) via br0
Aug 31 13:52:01 [dhcpd] DHCPOFFER on 172.16.215.73 to 00:25:bc:0e:09:83
(iPhone-SZAST) via br0
Aug 31 13:52:04 [dhcpd] DHCPDISCOVER from 7c:c5:37:21:d9:7c via br0
Aug 31 13:52:04 [dhcpd] DHCPOFFER on 172.18.93.227 to 7c:c5:37:21:d9:7c
via br0
Aug 31 13:52:05 [dhcpd] DHCPDISCOVER from 00:23:14:c0:61:28 (BLU060) via br0
Aug 31 13:52:05 [dhcpd] DHCPOFFER on 172.18.90.186 to 00:23:14:c0:61:28
(BLU060) via br0
Aug 31 13:52:08 [dhcpd] DHCPDISCOVER from 00:18:41:c7:6c:01
(Touch_Diamond) via br0
Aug 31 13:52:08 [dhcpd] DHCPOFFER on 172.19.228.144 to 00:18:41:c7:6c:01
(Touch_Diamond) via br0
Aug 31 13:52:09 [dhcpd] DHCPDISCOVER from 00:22:43:95:d1:1e via br0
Aug 31 13:52:10 [dhcpd] DHCPOFFER on 172.18.93.237 to 00:22:43:95:d1:1e
(TWOJA-6VJZP1GTV) via br0
Aug 31 13:52:10 [dhcpd] DHCPDISCOVER from 00:25:bc:0e:09:83
(iPhone-SZAST) via br0

If you wish I can post a whole log file which is rather long but I don't
think it is any meaning to do that.
There is nothing interesting inside (a bunch of lines with DHCPDISCOVER
& DHCPOFFER messages without DHCPACK between them) - no warnings nor errors.

Looking at the above snippet:   host with MAC 7c:c5:37:21:d9:7c asked
several times for dhcp data.
The first logs concerning this MAC which can be found are:
Aug 31 12:54:03 [dhcpd] DHCPDISCOVER from 7c:c5:37:21:d9:7c via br0
Aug 31 12:54:04 [dhcpd] DHCPOFFER on 172.18.93.227 to 7c:c5:37:21:d9:7c
via br0

It means the host haven't got IP.

Regarding the subnet - yes, I am sure this is the only one DHCP server.
What is more - I am sure the hosts did not get IPs since one of them was
my PC.
>
>> 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.
There is a lot of disk space.
>
> 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.
>
Well. Having big dhcpd.leases file (with the size near mentioned above)
I've found the server has to read the dhcpd.leases since start takes 
~10minutes (it is not an error  -10 minutes!)
Anyway.
According to my experience - removing the dhcpd.leases and restart fixes
the disfunctionality of the server immediately whereas restarting the
server with big dhcpd.leases changes nothing (apart from the restart is
extremely long)

> 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.
>
How long is the "period" ?
I've never found the file dhcpd.leases became smaller...




More information about the dhcp-users mailing list