atom feed19 messages in org.isc.lists.dhcp-usersRe: dhcp fails with big dhcpd.leases
FromSent OnAttachments
dorianAug 31, 2010 7:25 am 
Simon HobsonAug 31, 2010 8:32 am 
Sten CarlsenAug 31, 2010 9:41 am 
dorianAug 31, 2010 11:08 am 
Simon HobsonAug 31, 2010 11:09 am 
dorianAug 31, 2010 11:15 am 
dorianAug 31, 2010 11:28 am 
Simon HobsonAug 31, 2010 12:10 pm 
dorianAug 31, 2010 2:05 pm 
Sten CarlsenAug 31, 2010 3:55 pm 
sth...@nethelp.noAug 31, 2010 11:58 pm 
Simon HobsonSep 1, 2010 12:25 am 
dorianSep 1, 2010 1:36 am 
dorianSep 1, 2010 2:54 am 
Simon HobsonSep 1, 2010 3:21 am 
Glenn SatchellSep 1, 2010 5:06 am 
Simon HobsonSep 2, 2010 12:00 am 
dorianSep 2, 2010 2:41 am 
Sten CarlsenSep 2, 2010 4:38 am 
Subject:Re: dhcp fails with big dhcpd.leases
From:Sten Carlsen (ste@s-carlsen.dk)
Date:Aug 31, 2010 9:41:58 am
List:org.isc.lists.dhcp-users

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!!!"