<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, May 12, 2015 at 9:25 AM, Mark Sandrock <span dir="ltr"><<a href="mailto:sandrock@mac.com" target="_blank">sandrock@mac.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
> On May 11, 2015, at 11:20 AM, Shawn Routhier <<a href="mailto:sar@isc.org">sar@isc.org</a>> wrote:<br>
...<br>
><br>
> Another item to check is if dhcp-cache-threshold is enabled on both servers.<br>
> This is a feature to limit the number of times the servers touch the lease file.<br>
> If a client requests a renew early instead of handing out a full lease the server<br>
> simply hands out the previous lease again, correcting the lease time it sends<br>
> as necessary.  ...<br>
<br>
So, dhcpd.conf(5) gives a default of<br>
25% for 'dhcp-cache-threshold',<br>
which contradicts what I am seeing.<br>
<br>
The issuing F/O (primary) peer indeed<br>
ACKs a 3597 in response to the renew,<br>
but at the same time, (as the 3-second<br>
renew is broadcast), the secondary<br>
F/O peer ACKs an 86,400 value,<br>
i.e., extends the MCLT lease time.<br>
<br>
This seems like incorrect behavior<br>
on the part of the F/O peer.<br>
<br>
Thank you.<br>
Mark<br></blockquote><div><br></div><div>As I understand it...</div><div>As soon as both servers have a copy of the lease information, then they should return the full lease time.  The MCLT time is only returned while the lease information has not been synchronized.  So I think the peer is giving the correct response.  The primary might not have gotten confirmation back from the peer, so it might also be giving the 'correct' response from what it knows.  But you would need to trace the traffic or watch debug logs to know if the primary had gotten a response in those three seconds, in which case it gave the wrong response.</div><div><br></div><div>-- </div><div>Bob Harold</div><div><br></div></div></div></div>