split scoping

[Ausmus, Matt]

Thanks to all that replied.  Your comments have been greatly appreciated and are helping us to make the decision we need to make.  Here's a little more information.  

We have a single ISC DHCP server handling our entire dorms.  This was not by design but more as a stop gap measure.  We've decided to keep the single location for DHCP and implement fault tolerance into the solution.  We have enough free IP space to do split scoping but as I thought more about it I think we're going to go the ISC failover route.  Someone brought up the point that users could change IPs more often and in the middle of a session if the client goes out to renew and finds the alternate DHCP server first.  Their machine would change IPs.  This would cause links to go down during the duration and if the students are downloading files, watching video, or playing online games (yes, we do have to take this into account), their connection would drop.  The failover solution, while more complex in its operation if not in its configuration, would eliminate this issue.  The servers will be in the same location for the most part eliminating the issue that David brought up.

We plan on testing the failover solution in our building before rolling it out to the dorms and if the results are what we expect we may end up rolling this out to more buildings.

____________________________
Matt Ausmus
Network Administrator
Chapman University
635 West Palm Street
Orange, CA  92868
(714)628-2738
mausmus at chapman.edu
 
"What the gods get away with, the cows don't."
-THE AQUINAS AXIOM

-----Original Message-----
From: David W. Hankins [mailto:dhankins at isc.org] 
Sent: Wednesday, December 02, 2009 11:04 AM
To: Users of ISC DHCP
Subject: Re: split scoping

On Tue, Nov 24, 2009 at 01:44:02PM -0800, Matt Causey wrote:
> On Tue, Nov 24, 2009 at 11:39 AM, Ausmus, Matt <mausmus at chapman.edu> wrote:
> > 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?

Split scopes require "N * 2" address space, where N is the maximum
number of clients.

Failover requires much less address space (not quite N), but requires
much more operator savvy.  Essentially it makes a time-versus-address-
space tradeoff.  If you can run without operator intervention for time
X, that implies allocating a number of leases Y.  So if the pool of
available/unallocated leases divided by two is greater than Y, then
you have enough leases for failover.  After operator intervention you
require only "N" leases - the surviving failover server in partner-
down can use all the leases (after STOS+MCLT).

This is complicated because the number of unallocated leases is very
large when a site is first installed, and fluctuates through the
service's runtime.  The rate at which the service will require new
addresses can also fluctuate.

Don't underestimate the complication of needing to learn some of
failover's intricacies when considering employing it.

> One thing about the failover design, is that there are scenarios which
> are engineered to require manual intervention.  For example, if a

Failover was designed to solve the problem where servers are not
co-resident, but may be in different datacenters on different
continents.

In this case, being out of communications may not mean the partner is
down, and the partner may still be in contact with the clients (the
network path between servers may be down, not the networks between
each server and the clients).

There's no way to sense the remote system's availability without an
operator's sure hand.

It is not engineered to require manual intervention, the requirement
for manual intervention produced the engineering.

But for those of you with more "HA" style deployments, heartbeat
cables and the like, where being out of comms does strongly imply a
down condition, note that committed for 4.2.0a1 there is now a
configuration parameter that moves the server to partner-down after
a timeout.

- A new failover configuration parameter has been introduced for those
  environments where DHCP servers can be reasonably guaranteed to be
  "down" when the failover TCP socket is severed, "auto-partner-down".
  This parameter is not generally safe, and by default is disabled, so
  please carefully review the documentation of this parameter in the
  dhcpd.conf(5) manpage before determining to use it yourself.

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