using of DHCP Failover Protocol

[Gregory Sloop]

MS> Hello,

MS> Infoblox told in 2007, that they have made significant improvements to
MS> ISC dhcpd regarding DHCPFO protocol (draft-ietf-dhc-failover-12).

MS> You can read this here:
MS> http://www.lex.com.gr/downloads2/InfoBlox/SolutionNote_DHCP%20failover%20and%20Infoblox.pdf

MS> * My first question is, did ISC fix this issues as well?

MS> I'm a little scared about using dhcpfo in production environemnt
MS> because of the big number of
MS> states and handling of them in case of error....
MS> It seems that the setup is quit simple, but the handling is really complex.

MS> * So, my second question is, has someone experiences with ISC dhcpfo,
MS> are there anywhere
MS> good documentation for handling?
MS> * And can anyone recommend or has anyone bad experiences with this
MS> implementation?


We use it in a small [small, compared to many setups I've seen here] client, but in which we really need fault tolerance.

We're running them in a VirtBox, and with <200 clients / 60m lease, they don't break even a minor sweat. Really, virtually no load. I'm also doing DNS/BIND on the same VM.

Fail-over does work, and works nicely. You may find a thread of mine about running a tight pool when one partner goes down for an extended time. In the newer versions: [IIRC 4.2.0+] there's some new options that help endurance in such situations. 

See: auto-partner-down
and a less risky optimization, see: rewind state [IIRC, it's not an option you turn on, it's just available in 4.2.0+]

Short of the issues with a tight pool running out of available leases when a partner is down, we've been very happy with f/o.
We've had a few real-world issues [problems] that have helped us tweak things - but keep in mind that without f/o, we would have run into issues much sooner and in a less friendly way. [And on a weekend, no less.]

But these problems were really not problems with f/o, per-se, but simply our lack of understanding and circumstances that were unavoidable, in having a very tight lease pool, with substantial churn.

All our testing and real-world events really show a very nice setup that is vastly more resilient than a single server. [And obviously _somewhat_ more complex, but that's a given. Yet the increase in complexity is far outweighed by the benefit of redundancy.]

I can't imagine going back, or doing most anything else to get redundancy. It [ISC's DHCPd 4.2+] is, IMO, the most simple, cheapest, and most useful f/o setup I've seen.

Good luck!
-Greg

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20140730/e2102ca2/attachment.html>