<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8"></head><body ><div>Sorry I had a typo in my email we cat /dev/null into dhcp. leases~ file not the active file </div><div><br></div><div><br></div><div><div style="font-size:10px;color:#575757">Sent from Samsung Mobile</div></div><br><br><div>-------- Original message --------</div><div>From: Simon Hobson <dhcp1@thehobsons.co.uk> </div><div>Date:01-13-2017  3:30 PM  (GMT-05:00) </div><div>To: Users of ISC DHCP <dhcp-users@lists.isc.org> </div><div>Subject: Re: DHCP pair messed up, second one only running cant get primary up. </div><div><br></div>Rob Morin <rmorin@datavalet.com> wrote:<br><br>> Also the dhcpd.leases files grow too big for the /ramdisk, so we are each 10 mins catting /dev/null into /ramdisk/dhcpd.lease! file to save space.<br><br>I can't help with the other problems, but pray you don't have to stop the DHCP server at any time before it's re-written the compacted leases file ! Losing the leases file is "bad" in a big way.<br><br>I can't help with the specific problem, but I would suggest that if you lengthen the lease time (by a considerable amount) it will dramatically reduce the rate of growth of the leases file. With a lease length of 20 minutes, you'll have a renewal every 10 minutes (roughly) - so that's 6 lease updates to the leases file per hour !<br><br>For example, if you were to increase the lease time to (say) 4 hours, then your leases file would contain one record per lease (in practical terms, every address in your pools) plus one update for roughly 1/2 the active clients.<br><br>So your lease file size will change from total of IP ranges + 6x number of active clients, to total of IP ranges plus 1/2 the active clients.<br><br><br>Is there a reason for having such short leases ? It's quite short, longer leases bring much stability and much more leeway in dealing with DHCPO service issues !<br><br>Also, for consideration, you can have more than 2 servers in failover - but only 2 per pool. So it's possible to have (say) 3 servers sharing the load as A+B, B+C, and C+A. More complexity, but more scope for server failure without losing DHCP service - and more load sharing. Of course, you can also just split pools across an even number of servers as A+B, C+D, etc.<br><br>_______________________________________________<br>dhcp-users mailing list<br>dhcp-users@lists.isc.org<br>https://lists.isc.org/mailman/listinfo/dhcp-users<br></body>