
<html><head><title>Re: using of DHCP Failover Protocol</title>

<META http-equiv=Content-Type content="text/html; charset=iso-8859-15">

</head>

<body>

<span style=" font-family:'courier new'; font-size: 9pt; color: #800000;"><b>MS> Hello,<br>

<br>

MS> Infoblox told in 2007, that they have made significant improvements to<br>

MS> ISC dhcpd regarding DHCPFO protocol (draft-ietf-dhc-failover-12).<br>

<br>

MS> You can read this here:<br>

</b></span><a style=" font-family:'courier new'; font-size: 9pt;" href="http://www.lex.com.gr/downloads2/InfoBlox/SolutionNote_DHCP%20failover%20and%20Infoblox.pdf">MS> http://www.lex.com.gr/downloads2/InfoBlox/SolutionNote_DHCP%20failover%20and%20Infoblox.pdf</a><br>

<br>

<span style=" font-family:'courier new'; font-size: 9pt; color: #800000;"><b>MS> * My first question is, did ISC fix this issues as well?<br>

<br>

MS> I'm a little scared about using dhcpfo in production environemnt<br>

MS> because of the big number of<br>

MS> states and handling of them in case of error....<br>

MS> It seems that the setup is quit simple, but the handling is really complex.<br>

<br>

MS> * So, my second question is, has someone experiences with ISC dhcpfo,<br>

MS> are there anywhere<br>

MS> good documentation for handling?<br>

MS> * And can anyone recommend or has anyone bad experiences with this<br>

MS> implementation?<br>

<br>

<br>

</b><span style=" color: #000000;">We use it in a small [small, compared to many setups I've seen here] client, but in which we really need fault tolerance.<br>

<br>

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

<br>

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

<br>

See: auto-partner-down<br>

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+]<br>

<br>

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

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.]<br>

<br>

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

<br>

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.]<br>

<br>

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

<br>

Good luck!<br>

-Greg<br>

<br>

<br>

</body></html>