4.2.0a2 and comms-interrupted endurance

[David W. Hankins]

Earlier, I wrote:
> 			Changes since 4.2.0a1
> 
> - An optimization described in the failover protocol draft is now included,
>   which permits a DHCP server operating in communications-interrupted state
>   to 'rewind' a lease to the state most recently transmitted to its peer,
>   greatly increasing a server's endurance in communications-interrupted.
>   This is supported using a new 'rewind state' record on the dhcpd.leases
>   entry for each lease.

I wanted to bring some extra attention to this, because in addition
to the Asynchronous DDNS support in 4.2.0a1, this was a big feature
for me that many of you have been wanting for a long time, and I'd
really appreciate it if anyone interested could have a crack at the
alpha to see if they can break it.

Who has had a server go into communications-interrupted at 5pm, and
no one notices until 5am when someone comes into the office and can't
get a DHCP lease?  The problem is the surviving server knows that
all the leases have 'expired', and can't allocate them.

This new change in 4.2.0a2 on the other hand lets a server "rewind" a
lease to the last state it negotiated with its peer.  So those expired
leases can go back to free or backup - and get allocated to a new
client - or they can go back from expired to active if that was the
state the peer last had it in (but in this case, it must be allocated
to the same client).

This should give DHCP Failover servers a _lot_ more endurance when
running in communications-interrupted, because they can keep extending
the current snapshot of active leases indefinitely, and their 'free'
pool can be replenished as clients using those leases expire or
release!

Combine this with the auto-partner-down feature in 4.2.0a1, and I
think it's possible to make a dynamic DHCP service that "won't fail."

-- 
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20100224/8a7eef60/attachment.bin>