ISC DHCP server failover

Leo Bicknell bicknell at ufp.org
Sat Mar 20 20:25:20 UTC 2010


In a message written on Fri, Mar 19, 2010 at 05:10:04PM -0700, Mike wrote:
> I am certainly not prepared to develop proof of concept code or go the 
> full route of developing such a server myself, however, I belive firmly 
> that a failover implementation in dhcp could be designed as a 
> counterpoint to the current implementation that is reliable, simple, 
> scalable and requiring no special procedures once a 'break' occurs. The 
> method used by isc-dhcpd, I think, creates the problem of the potential 
> for unreliable failover because it's not designed for the 'right' 
> problem. But there are example implementations - such as vrrp/carp - 
> that would form the basis of trustworthy dhcp failover protocol. Your 
[snip technical bits]

Your method might work good where there is a LAN segment with two
DHCP servers on it, and I'm sure that's how some people operate.
However your method doesn't cover a much more common, and difficult
case.

Consider a DHCP server in Chicago and one in New York, performing
DHCP for clients in Chicago, Cleveland, Pittsburg, Buffalo, Albany,
and New York.  When the network is broken, Chicago may still need
to serve Cleveland and Pittsburg, and New York may need to serve
Buffalo and Albany, and yet Chicago and New York cannot communicate
during that time.  Also, you want to be sure when they come back
together there are no conflicts, for instance maybe Rodchester can
reach both Chicago and New York while those two cannot talk to each
other.

LAN discovery does not work for servers 1000 miles apart.  All-or
nothing failure doesn't work, when each server may see part of the
clients.

I do think the DHCP failover protocol was perhaps over-engineered
which I think is the jist of your post, but unfortunately unlike
VRRP it's not always two things on the same local LAN.  Perhaps
there is a market for DHCP redundancy "lite" where it only handles the
case of two servers on the same LAN, I dunno.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 826 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20100320/421072e1/attachment.sig>


More information about the NANOG mailing list