Clarification on PARTNER-DOWN and MCLT

[Ian Anderson]

Thank you for taking the time to explain this.  I think I am missing
something extremely simple. 

I understand now that the state of the dhcp servers has no bearing on
what the lease times given out to clients is set to. 

I understand that there is a difference between potential expiry and
lease times.  

Below is an example of one our lease records.  When reading your
description of how a "virgin client" obtains a lease and what fields
change within the lease DB, everything seems to make sense.  The one
piece that is eluding me is how does having a potential expiry time
greater than a lease time help in a dhcp-failover environment.  

How does MCLT "help ensure that any leases the failed server may have
given out while out of contact with its partner will have expired."

lease 10.60.7.27 {
  starts 5 2006/11/03 23:11:32;
  ends 6 2006/11/04 23:11:32;
  tstp 0 2006/11/05 11:11:32;
  tsfp 0 2006/11/05 11:11:23;
  cltt 5 2006/11/03 23:11:32;
  binding state active;
  next binding state expired;
  hardware ethernet 00:13:10:89:c2:78;
  uid "\001\000\023\020\211\302x";
  client-hostname "00131089C278";
}

Thanks again for your patience and time. 

-----Original Message-----
From: dhcp-users-bounce at isc.org [mailto:dhcp-users-bounce at isc.org] On
Behalf Of David W. Hankins
Sent: Friday, November 03, 2006 1:01 PM
To: dhcp-users at isc.org
Subject: Re: Clarification on PARTNER-DOWN and MCLT

On Fri, Nov 03, 2006 at 09:24:02AM -0800, Ian Anderson wrote:
> >> So in other words when a server in partner-down is handing out
> addresses >> with (cur_time, lease.tsfp) + MCLT it adjusts it lease
time
> to correspond >> to when MLCT would expire.  

No.  It does not matter what state the server is in.  It never matters
what state a server is in.  A server in any state will give a lease time
so that the expiration time is no larger than 'max(cur_time, tsfp) +
MCLT'.

> >> For example
> >> First Client - Lease time of 30 minutes 
> >> Second Client - requests a lease 5 minutes later. The lease time
> would be >> 25 minutes?

No, these are separate leases.  Potential expiry is on a lease-by-lease
basis.

Look in your dhcpd.leases file for tstp and tsfp values.

> >> So in a recover-wait state the partner-down server is handing out
> leases >> with lease_time+(mclt/2),

No, the server hands out lease-times equal to max(cur_time, tsfp) +
MCLT.

It does not matter what states the servers are in.  It only matters
wether or not they are speaking, and how long it has been.

> when both servers are back to a
> normal >>condition the lease time will revert back to lease_time?

That depends on the negotiated potential expiry, but if one server
is in recover-wait, then the lease-times have probably already reached
normal.


A virgin client asks for a lease.  The lease therefore has no
potential expiry, or it is in the past, and so the current time is
used.  The lease time is equal to MCLT.

The server sets TSTP to desired lease_time + MCLT/2, but note that
the actual lease time is equal to MCLT in this case, not the desired
lease time (so it's not MCLT + MCLT/2) which is still equal to,
well, the desired lease time.

The remote server acknowledges this change, TSFP is set the same
as TSTP.

The client renews at MCLT/2.  This means that TSFP now marks a time
that is equal to the desired lease time in the future.

The server offers the desired lease time, and sets TSTP to
lease_time + lease_time / 2.

This is the way it works.  It doesn't matter what state the server
is in.  In some states, it necessarily means that the remote server
is not acknowledging binding updates (such as communications-
interrupted).  In those cases the clients will receive lease times
that are negotiated downwards towards MCLT.  In some states it might
imply or requires that the servers be communicating.  In those
cases, the desired lease time will be negotiated upwards as normal.

-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		you'll just have to do it again."
Internet Systems Consortium, Inc.	-- Jack T. Hankins