matt.causey at gmail.com
Tue Nov 24 21:44:02 UTC 2009
On Tue, Nov 24, 2009 at 11:39 AM, Ausmus, Matt <mausmus at chapman.edu> wrote:
> Hello All,
> We’re using ISC DHCP pretty much everywhere in our environment. It has been
> suggested to me that we start using split scoping so I’ve started doing
> research on the issue. ISC includes the draft failover mechanism which I’m
> leaning toward instead of just split scoping. In fact, all the
> documentation I’ve found available only refers to setting up Windows DHCP
> servers split scoping but nothing with regards to ISC DHCP servers. Split
> scoping appears that it would work fine and be very quick to setup but would
> be not very elegant.
> What are the pros and cons to using just split scoping between a couple of
> ISC servers vs. using the draft fault tolerance mechanisms built into ISC
> DHCPd? 1 obvious con is that DHCP leases would be split between 2 different
> machines. What are some others and are there any pros to this setup?
One thing about the failover design, is that there are scenarios which
are engineered to require manual intervention. For example, if a
server goes into communications-interrupted for a time, you'll need to
either automate your recovery actions, or instrument alarming to
automatically engage an engineer to respond to the condition. The
service out of the box is engineered to protect leases integrity at
all costs....even if that means the individual dhcp server decides to
stop handing out leases (banking on the possibility that the other
server could be servicing those leases).
If you've got IP space to burn, I'd say that the split-scoping concept
is far simpler and more reliable.
Having said that, in our environment we've been running the failover
model on 30 pairs of systems across the remote sites...and it works
well. I've added some crons that perform some self-healing actions on
the systems based on their faiover status. I do this because I'd like
our sites to prioritize handing out and servicing leases over leases
integrity / ip conflict protection. For example, if a system is
determined to be in communications-interrupted for awhile, and it
clearly is on the network, and it can't communicate with its peer,
then it automatically places itself in partner-down. There are some
other bits and pieces, but thats one example.
I'm certainly open to ideas and constructive criticism on the design,
but that's been the evolution of our use of dhcp failover.
More information about the dhcp-users