Spontaneously shortened leases

[Patrick Trapp]

Ah, thank you both. That appears to be the case. Of course, the next question I need to answer (not for the list, of course) is why on earth someone (it could have been me, but I cannot prove anything) commented out the 3600 value in favor of 60.

All I can find is it was changed the morning after we applied a patch to the DHCP servers, so I presume it was related to that activity.

Thanks again for your time and attention.

________________________________
From: dhcp-users-bounces at lists.isc.org [dhcp-users-bounces at lists.isc.org] on behalf of Patrick Trapp [ptrapp at nex-tech.com]
Sent: Friday, January 09, 2015 3:38 PM
To: dhcp-users at lists.isc.org
Subject: Spontaneously shortened leases

We are running a pair of 4.2.7 servers in failover mode. On Christmas, we had an issue with the
clients on the network they support and eventually discovered that the servers were handing out leases with 60-second lease times. As a result, the servers were swamped with DHCP requests and the clients were unable to consistently get and keep an address as the servers were dropping tens of thousands of packets a second as every device tried to renew.

It was noted that the normal "balancing" entries (for failover) in the dhcp logs were not present during this time.

The timestamps on the configuration files where the leases are configured were several months old and were still correctly configured for 24-hour leases.

We tried stopping DHCP on each of the servers for a time to see if the remaining server would take over without success. Ultimately, we had to restart one of the servers itself, not just its DHCP process, to recover.

Once that was done and the downed server came online, the balancing entries were visible in the logs once again and the leases were for 24 hours instead of 60 seconds. Has anyone else seen this problem? We have had no success determining what started this and would prefer to avoid it in the future as it took ten days to get all of clients straightened back out.

Patrick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20150109/9e273e36/attachment-0001.html>