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@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/