Failover strangeness

[David W. Hankins]

On Tue, Oct 10, 2006 at 04:17:38PM -0400, Greg G wrote:
> Greg G wrote:
> >    The lease didn't transition back, even after a few hours, and the 
> > peer went down.  Is there a way to make that transition happen?

If the server is in partner-down state (not communications-interrupted),
I think it should happen after STOS+MCLT.

If it doesn't, that's probably a bug.

You're running into odd siutations here because failover isn't really
designed for one-lease pools like this.

Failover survivability all hinges around having a number of leases (free
and backup states) allocated to each server in the event they should
lose contact with the other.

When there's only one, that will never be better than a single point of
failure.

Although you could experiment with 'reserved' dynamic leases, which
by definition are covered by both the 'free' and 'backup' states
simultaneously.

>    (Pardon the self-follow...)
>     Also, shouldn't the dhcp server serve these leases if the peer goes 
> down?

The failover protocol document describes an optimization - if the
peer last knew the lease to be in a given state (active, free,
backup), and no failover message has been transmitted yet, the server
may elect to move the lease back into these states.  Think of it as a
'white lie'.  In this way, as you say, the server could move an 'expired'
lease back to 'active' if it knew that the peer had never been told of
the expiry (so it should also have it as active, or at worst, expired,
and will not offer it to another client).

I had hoped to support this in 3.1.0, but that development wasn't
ready for 3.1.0a1's advanced release schedule.

We'll get this into a future release.

-- 
ISC Training!  October 16-20, 2006, in the San Francisco Bay Area,
covering topics from DNS to DDNS & DHCP.  Email training at isc.org.
-- 
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