Inconsistent renews from F/O peers
rharolde at umich.edu
Tue May 12 15:09:57 UTC 2015
On Tue, May 12, 2015 at 9:25 AM, Mark Sandrock <sandrock at mac.com> wrote:
> > On May 11, 2015, at 11:20 AM, Shawn Routhier <sar at isc.org> wrote:
> > Another item to check is if dhcp-cache-threshold is enabled on both
> > This is a feature to limit the number of times the servers touch the
> lease file.
> > If a client requests a renew early instead of handing out a full lease
> the server
> > simply hands out the previous lease again, correcting the lease time it
> > as necessary. ...
> So, dhcpd.conf(5) gives a default of
> 25% for 'dhcp-cache-threshold',
> which contradicts what I am seeing.
> The issuing F/O (primary) peer indeed
> ACKs a 3597 in response to the renew,
> but at the same time, (as the 3-second
> renew is broadcast), the secondary
> F/O peer ACKs an 86,400 value,
> i.e., extends the MCLT lease time.
> This seems like incorrect behavior
> on the part of the F/O peer.
> Thank you.
As I understand it...
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the dhcp-users