dhcp fails with big dhcpd.leases

Wed Sep 1 12:06:19 UTC 2010

On 09/01/10 00:25, dorian wrote:
> Hello everybody,
> I have a problem with dhcp server working in hotspot (public place).
> It stops working when the dhcpd.leases grows to much.
> I observed that having dhcp.lease file size around 893116 bytes causes
> clients not to get the IP address.
> To be precise: sometimes (but very seldom) it services the requests. But
> generally does not.
>
> In that case the log content is like this:
> 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
>
> After stopping the server, removing dhcpd.leases and next running it again
> the log content is like the following:
> Aug 31 15:34:42 [dhcpd] DHCPREQUEST for 172.19.235.111 (172.16.0.1) from
> 00:23:6c:2b:08:eb (kPhone) via br0
> Aug 31 15:34:42 [dhcpd] DHCPACK on 172.19.235.111 to 00:23:6c:2b:08:eb
> (kPhone) via br0
> Aug 31 15:34:43 [dhcpd] DHCPDISCOVER from 00:23:6c:73:b3:29 via br0
> Aug 31 15:34:44 [dhcpd] DHCPOFFER on 172.18.100.204 to 00:23:6c:73:b3:29
> (AMs-iPhone) via br0
> Aug 31 15:34:44 [dhcpd] DHCPDISCOVER from 00:25:bc:bb:d5:ac via br0
> Aug 31 15:34:45 [dhcpd] DHCPOFFER on 172.16.222.41 to 00:25:bc:bb:d5:ac
> (iPhone-user) via br0
> Aug 31 15:34:46 [dhcpd] if AMs-iPhone.moben IN A rrset doesn't exist add
> AMs-iPhone.moben 36000 IN A 172.18.100.204: timed out.
> Aug 31 15:34:46 [dhcpd] DHCPREQUEST for 172.18.100.204 (172.16.0.1) from
> 00:23:6c:73:b3:29 (AMs-iPhone) via br0
> Aug 31 15:34:46 [dhcpd] DHCPACK on 172.18.100.204 to 00:23:6c:73:b3:29
> (AMs-iPhone) via br0
> Aug 31 15:34:47 [dhcpd] if AMs-iPhone.moben IN A rrset doesn't exist add
> AMs-iPhone.moben 36000 IN A 172.18.100.204: timed out.
> Aug 31 15:34:47 [dhcpd] DHCPREQUEST for 172.18.100.204 (172.16.0.1) from
> 00:23:6c:73:b3:29 (AMs-iPhone) via br0
> Aug 31 15:34:47 [dhcpd] DHCPACK on 172.18.100.204 to 00:23:6c:73:b3:29
> (AMs-iPhone) via br0
> Aug 31 15:34:49 [dhcpd] if iPhone-user.moben IN A rrset doesn't exist
> add iPhone-user.moben 36000 IN A 172.16.222.41: timed out.
>
> so it is clearly visible that in case of the failure there is no
> DHCPACK  packets.
>
> The conf file is following:
>
> ddns-update-style ad-hoc;
> log-facility local7;
> #--------- 172.16.0.0/14----------------------------
> subnet 172.16.0.0 netmask 255.252.0.0 {
>     authoritative;
>     option subnet-mask   255.252.0.0;
>     option routers 172.16.0.1;
>     option domain-name "moben";
>     option domain-name-servers 10.2.0.1;
>     option interface-mtu 1450;
>     default-lease-time 72000;
>     max-lease-time 72000;
>     range 172.16.8.0  172.19.255.254;
> }
> + some static leases based on hw address which gives addresses<172.16.8.0
>
> The questions are:
> 1. why the server stop working?
> 2. the dhcpd.leases file size is the reason (or is it the only reason)?
> 3. how to fix the problem (it is 24/24 service so restarting is not the
> best solution for me)
>
> Regards,
> Dorian

Hi Dorian

I've chopped out a lot of the replies, now to answer your questions:

1. Don't know. There are sites that have more than 100,000 clients and 
lease files that are many 10s of megabytes in size, much bigger than yours.

2. The size of the lease file is probably not the problem. More likely 
is that the restart with no lease file just delays the problem from 
happenning.

3. We don't know how to fix it. The other users on this list can make 
suggestions about things to try to see if we can narrow down the range 
of the problem, but you may need to try some configuration changes to 
help here.

In another post I think you said that the dhcpd version is 3.1.2. The 
current release is 4.2.0. First suggestion is to try a later version, 
either 4.2.0 or 4.1.1 to see if that works any better. If there is a bug 
in your current version it may be fixed in the newer one. For RedHat you 
can search for a new rpm, or perhaps compile from source. Your 
configuration file will work just fine with the new version.

The long startup time is due to having a very large range (172.16.8.0 
172.19.255.254). In the older versions there are a few hash bucket 
structures that are too small for that number of leases. The newer 
versions user larger hash buckets, so they should load a lot quicker.

One suggestion is to show us all the requests only from one client, for 
example:

grep 00:23:6c:73:b3:29 /var/log/syslog

In this case find a client that has a problem and use that ethernet address.

Turn of dynamic DNS updates. The dhcp server blocks while the DNS update 
is performed. Your DNS updates are timing out, so the server may be 
missing replies during the timeout period.

ddns-update-style none;

See how you go with that and let us know. Then we can make some more 
suggestions.

-- 
regards,
-glenn
--
Glenn Satchell                            |  Miss 9: What do you
Uniq Advances Pty Ltd, Sydney Australia   |  do at work Dad?
mailto:glenn.satchell at uniq.com.au         |  Miss 6: He just
http://www.uniq.com.au tel:0409-458-580   |  types random stuff.