ISC DHCP 3.0.4rc1 is now available!

[David W. Hankins]

On Wed, Apr 19, 2006 at 06:39:53AM +0200, Joerg Mayer wrote:
> On Mon, Apr 17, 2006 at 02:52:42PM -0700, David W. Hankins wrote:
> > Note that significant changes were made in this 3.0.4 release engineering
> > to the failover protocol, and you should read the RELNOTES carefully in
> > regards to the new 'atsfp' values placed upon leases and what they mean
> > to you.
> 
> Has the failover protocol itself changed? If so, is documentation on the
> changes on the network protocol side available?

No, no protocol changes, but the addition of a field to lease structures
in the dhcpd.leases database presents a substantial change to our
implementation, and bears operators pay attention to how it might
affect their installation as they upgrade.

I thought I wrote some 'what to expect: atsfp' words in the RELNOTES,
but they don't appear to be there.  I'll fix that for 3.0.4 final or
rc2.  I bet they're sitting in a source tree somewhere I forgot to
commit on.

I hate when that happens.

But in the meantime, this:

- A failover bug that was allowing leases that EXPIRED or were RELEASED
  where tsfp and tstp are identical timestamps to languish in these
  transitional states has been repaired.  As a side effect, lease
  databases should be kept more consistent overall, not just for these
  transitional states.

Means:

'tstp' and 'tsfp' were used by ISC DHCP on lease state structures to
describe something the draft calls 'potential-expiry'.  By recording
the potential-expiry time the server sent, and the time that was
received, you can detect there's a difference (tstp > tsfp), and cause
binding updates to be retransmitted.

But there's a corner case: when leases expire, or even when they are
released, tstp and tsfp are probably identical (the expiration or release
event does not alter these values: so if the two servers were in
agreement on potential-expiry before the event, they must then be equal).

So tstp > tsfp is false.

So if the expiration were rejected, or simply lost, it would never be
retransmitted, and leases would languish in expired state: never to be
allocated again.

The 'atsfp' value is identical to the 'tsfp' value except that it is
zeroed when a change is made to the lease structure that requires a
binding-update be sent over the failover channel.  This way we know
to retransmit later.  The historic tsfp value is important for many,
many other uses, so a separate field is needed.

So nothing has changed about how we deal with potential-expiry, the
only externally visible change is that we now retransmit these
'transitional state' (expired, released, reset) leases, as we were
supposed to anyway.


Now how you get these atsfp values to start out with is the interesting
thing.  Since a zero atsfp is normal, and there's no version marking
on dhcpd.leases so we can do automatic conversions, all your leases
are going to be retransmitted the first time you reconnect the failover
servers running the new software (tstp > 0 will always be true).

For small installations I doubt it would cause a problem.

But if you want to avoid this, either because you're paranoid or the
time to resync the entire lease state database would be too long in
maint window, you need to synthesize atsfp values from the most recent
tsfp value.

Literally, duplicating the line but adding an 'a' to the front is all
you need to do.

Similarly, if you need to downgrade, these atsfp values will have to
be removed for dhcpd.leases to be read without error.


As for documenting changes to ISC DHCP failover implementation that
represent protocol changes, there are changes queued for feature release
(and it looks like I'm going to get to commit them to HEAD today as
the review process has completed) which you'll see in 3.1.0.  They
are not backwards compatible to any 3.0.x version by necessity (even
the CONNECT message protocol number has changed!).

But they're already documented in draft revision 12 of the failover
draft...we're just syncing up with that.

That'll be included in the doc/ subdir with the distribution as it goes.

Additional changes that also aren't protocol changes will also be
made, and recorded in the RELNOTES.  MAC address affinity is completed,
but not yet reviewed, for example.  'Reserved' dynamic leases are in,
as well as support for dynamic bootp via failover (it's hard to do
reserved leases without doing those).

-- 
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