Can dhcpd4.1-p1 Communicate with dhcpd3.1.3?

[David W. Hankins]

On Mon, Nov 01, 2010 at 10:16:24PM +1100, Glenn Satchell wrote:
> DHCP FAILOVER
>      This version of the ISC DHCP server supports the DHCP  fail-
>      over  protocol  as  documented  in  draft-ietf-dhc-failover-
>      12.txt.   This is not a final protocol document, and we have
>      not done interoperability testing with other vendors' imple-
>      mentations of this protocol, so you  must  not  assume  that
>      this  implementation  conforms to the standard.  If you wish
>      to use the failover protocol, make sure that  both  failover
>      peers are running the same version of the ISC DHCP server.

Hm.

The intent is that you run the same version over the long term.  There
is no reason why you wouldn't run servers of two different versions in
the lock steps to upgrade.  If we did have such a reason, that would
be a glaring bug; the upgrade path is a cited reason for the need for
Failover.  You want to run the new software, make sure it doesn't
bail, and then upgrade the peer shortly after.

There is absolutely no reason why you shouldn't do that.

The only wire format incompatibility was from the step from 3.0 to
3.1.  So 3.0.x versus any other non-3.0.x version won't work.  But
we put that in the release notes in big glaring letters, as a one-
time deal.

So if you're running 4.1 and 3.1 together, that's fine.  The advice
trying to be conveyed here is not to make that a lifestyle.  You don't
want to keep 3.1 for the next seven years thinking you're gaining
something, you want to get it upgraded too.

There are subtle feature additions we make as time wears on.  These
don't make Failover non-reverse-compatible, they just work better if
the servers are both operating consistently.

For example, if you had one server that implemented client affinity
(so it is giving away its leases that hash to the peer), and the peer
does not (so it is giving away its leases based solely on the lease
expiration age), then you might get a fair bit of extra pool rebalance
behavior as they give each other the same lease hot-potato (with long
delays in-between, but still), and the pool may not be optimally
balanced.

That's a far cry from "it won't work."

Later versions just work better, and they work better together.

-- 
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/20101104/cb08ce9e/attachment.bin>