<html><head><title>Re: expired lease problem</title>
</head>
<body>
<br><br>
<br>
<table>
<tr>
<td width=2 bgcolor= #0000ff><br>
</td>
<td><span style=" font-family:'courier new'; font-size: 9pt;">Thanks Bill for the insight. I am happy to report that the problem has been found and corrected. We have a failover pair and in our last maintenance the failover config on the secondary was redone with a mistake. It was pointing to itself as the failover peer. This caused the two dhcpd.leases file to be out of sync, skewed the pool numbers and caused the out of leases problem. Once corrected, everything went back to normal. This is probably a one off type thing but I hope it helps someone out there down the road.  <br>
</span><a style=" font-family:'courier new'; font-size: 9pt;" href="https://lists.isc.org/mailman/listinfo/dhcp-users"></a></td>
</tr>
</table>
<br><br>
<span style=" font-family:'Courier New'; font-size: 9pt;">I'm glad you fixed it, but isn't that something that DHCPd should vigorously complain about in the logs?<br>
*-It would seem that it should complain on startup [not sure if that's the case]<br>
*-Also, it should complain that it can't talk to the peer - itself - and I'd guess the pool balance would be really crazy.<br>
*-I'd imagine it would show communications interrupted etc.<br>
<br>
Wasn't that all in the logs? [Not trying to beat you up here - we've all made mistakes that look nuts in retrospect..I'm just really curious/surprised if there were not a ton of indications in the logs...] <br>
<br>
I'm perhaps most interested that DHCPd would even start with a peer def was pointing at itself.<br>
<br>
I've started centralizing logs with RSync, and find that DHCPd problems, especially related to peer/failover functions, often become more clear if you can see the two sets of logs from both peers in one place - together. [And the obvious benefits of retaining/archiving logs for retrospective review...]<br>
</body></html>