DHCP Redundancy

Thu Dec 2 14:06:41 UTC 2010

But aren't they all connected to the same root gateway? A single DHCP server
should be able to serve that easily. If you have multiple subnets you just
need to have IP Helper to forward all the DHCP requests to your server. IMHO
two failed-over servers can service thousands of users without much issue.

Nathan Van Fleet
Telecommunications Analyst
Network Assessment and Integration
IITS Concordia University
(514) 848-2424 Extension:5434

> -----Original Message-----
> From: dhcp-users-bounces+nmcdavit=alcor.concordia.ca at lists.isc.org
> [mailto:dhcp-users-bounces+nmcdavit=alcor.concordia.ca at lists.isc.org]
> On Behalf Of Matt Jenkins
> Sent: Wednesday, December 01, 2010 5:50 PM
> To: Users of ISC DHCP
> Subject: Re: DHCP Redundancy
> 
> This is for a wireless ISP network built in a remote area where most of
> the systems are on solar power. It will not be unheard of for any given
> site to lose power for days or more. I need to be able to have dhcp
> servers at each location that all share the same leases information....
> 
> On 12/01/2010 02:44 PM, Bryan J Smith wrote:
> > > From everything I've seen, these services do re-read the existing
> leases file.
> > But how do you coordinate multiple DHCP services sharing the same
> leases file
> > without stomping on each other when they update it?  Even if the
> service only
> > briefly opens and closes a write lock, and you can mitigate write
> lock
> > contention when the leases file is updated, how do you force all of
> the other
> > services to re-read the file?
> >
> > For these levels of high availability, I would highly recommend you
> consider
> > configuring Red Hat Cluster Suite (RHCS) solutions in each subnet,
> for providing
> > your DHCP service.  That way you have a single DHCP service for the
> range
> > defined (multiple per subnet if you wish), it is highly available,
> possibly
> > through even networking equipment failures (depending on the design
> and
> > topology).
> >
> > I haven't kept up with ISC's latest DHCP service configuration, but I
> wasn't
> > aware of a native, clustering service that can exchange updates and
> maintains
> > their own DBs.  Has this been implemented?  I looked at developing
> such with the
> > Spread API many years ago (along with RADIUS and other
> authentication), and it's
> > quite an undertaking.
> >
> >
> >
> >
> > ----- Original Message ----
> > From: Matt Jenkins<matt at smarterbroadband.net>
> > To: Users of ISC DHCP<dhcp-users at lists.isc.org>
> > Sent: Wed, December 1, 2010 5:14:21 PM
> > Subject: Re: DHCP Redundancy
> >
> > Would it be possible to have a distributed NFS directory and have
> many dhcp
> > daemons read the same leases and configuration files? Does the DHCP
> Server
> > re-read the leases file when it starts up so it knows about all
> existing leases?
> >
> > On 11/30/2010 02:21 AM, Simon Hobson wrote:
> >> Matt Jenkins wrote:
> >>> So is it possible to maintain a central or distributed leases file
> for multiple
> >>> (unknown quantity) of servers?
> >>>
> >>> I ask because I am working on a design to change over all of my
> wireless
> >>> clients to dhcp. With the wide spread nature of the network, ALL
> services are
> >>> distributed so that any single point can fail and everything else
> stays active.
> >>> This assumes that the point of failure will never recover. The
> system MUST be
> >>> able to handle this automatically. I definitely do not have 2x the
> address space
> >>> as others suggested. I kind of assumed that the dhcp servers
> maintained
> >>> synchronised information regarding leases.
> >>>
> >>> I estimate the need for 17 dhcp servers (right now) distributed
> across the
> >>> system handling multiple /18's (in total) of address space. Can
> this be handled?
> >> Failover is only supported between two servers, but you can have
> different
> >> pairings for different subnets. Eg, you can have A&B for one subnet,
> A&C for
> >> another, A&D for another, C&E for another - whatever you want.
> >> I think you can do this by pools, but that sounds like a recipe for
> confusion
> >> myself !
> >>
> >> In your situation, a hub and spoke arrangement might make sense (it
> depends to
> >> a certain extent on your network topology). Have one central DHCP
> server that
> >> serves all networks, and a partner for each network.
> >>
> >> Obviously the central server will need to be big enough to handle
> all the
> >> traffic, but each satellite system can be much smaller.
> >>
> >> There was an interesting idea put up a while ago (that was in the
> context of an
> >> ISP setup). In that suggestion, the remotes could keep their lease
> database in a
> >> ram disk - good for performance on a low spec machine. Should the
> remote site
> >> have a power failure, then on startup, the DHCP server can load it's
> lease
> >> database from the central server. Obviously, since the central
> machine is the
> >> only one with non-volatile storage, then it will need to be
> reasonably reliable
> >> (not too hard with server grade hardware).
> >>
> >>
> >> As already said, if you wish to do so, then you can script your own
> checks to
> >> detect a partner failure, and automatically put the remaining server
> into
> >> partner down state. What checks you do is up to you - it's your
> network and only
> >> you will have the knowledge to differentiate between failure modes
> and determine
> >> if "can't talk to remote server" really means that it is either down
> or at least
> >> unable to communicate with clients.
> >>
> > _______________________________________________
> > dhcp-users mailing list
> > dhcp-users at lists.isc.org
> > https://lists.isc.org/mailman/listinfo/dhcp-users
> >
> > _______________________________________________
> > dhcp-users mailing list
> > dhcp-users at lists.isc.org
> > https://lists.isc.org/mailman/listinfo/dhcp-users
> _______________________________________________
> dhcp-users mailing list
> dhcp-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/dhcp-users