Antw: Re: partner-down still peer holds all free leases

[David W. Hankins]

On Fri, Sep 12, 2008 at 01:33:56PM +0200, Thomas Zenz wrote:
> We actually set the mclt value to have in normal state this:
> (from dhcpd.conf) This  is the length of time for which a lease may be
> renewed by either failover peer without contacting the other.

That is the purpose of the MCLT.  The impact of this purpose however
runs into many other failover operations.  How long a peer may have
extended or allocated any lease tells us there is a "danger zone" of
potential allocations for which the local server saw no updates.

For example;

If I can assume that the secondary will only have allocated a backup
lease for no more than MCLT seconds, then if I am in partner down, I
can expect that at worst all of the peer's leases were allocated
without my knowledge, and that also at worst all those leases will
expire by "potential-expiry + MCLT", or "start time of service (STOS)
+ MCLT", depending on which is later.

So if your objective was to avoid any potential duplicate allocations,
it is only safe to allocate that lease after STOS+MCLT.


I am going to save you a bit of trouble in your testing, because after
you reduce your MCLT (or edit STOS), there are a couple bugs you need
to know about.

In 3.1.0, we were going for full adoption of the latest version of the
failover draft;

  http://www.isc.org/sw/dhcp/drafts/draft-ietf-dhc-failover-12.txt

One of the many changes in the draft since we'd last worked on this
(-07) was that many of the messages and state values had been changed
(it seems, alphabetized).  Of them, the server state binary values
which, due to OMAPI's design, you're using directly.

It seems however the help text you're looking at hasn't been updated.

Until we get that fixed, you need to refer to includes/failover.h and
search forward for 'partner_down' to get the appropriate numerical
values.

The second bug is that in lease allocation it's possible that a server
in partner-down will refuse to allocate a lease to a client it has
never before seen (has no mac or client id attached to any lease).  A
fix for this has already been queued for the next maintenance release.

-- 
Ash bugud-gul durbatuluk agh burzum-ishi krimpatul.
Why settle for the lesser evil?	 https://secure.isc.org/store/t-shirt/
-- 
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