DHCP peer failure and pool exhaustion...

[Simon Hobson]

Gregory Sloop wrote:
>Yeah, I can see that the technical details are more complex than I
>appreciated - and ISC's trying to make one DHCP server that satisfies
>everyone from ten-of-thousands enterprise setups to mom-and-pop little
>business setups. And doing that means you probably design for the
>enterprise setups - which means if it's not totally bullet-proof it's
>not getting rolled out.

Not just that, but the underlying philosophy is to be "100% RFC compliant" unless there's a really good and compelling reason to deviate. That certainly cannot be said of implementations from certain large commercial vendors.

There is another potential solution you may want to consider - apart from the fact that you've probably progressed past the position of being able to do it without yet another subnet change ...
You can have multiple non-failover DHCP servers on the network if you take certain precautions. Basically, each much offer a unique pool of dynamic addresses which does not overlap in any way with any other server's pools. You must also not "NACK" requests for addresses that are within the subnet but outside your own pools (that's the default anyway for the ISC server). You can offer the same address from each server where it is fixed (eg if you were to assign addresses to printers via "fixed-address" statements).

In normal operations, when a client broadcasts a Discover packet, all servers with a free lease will respond. The client will select one (typically the first it receives) and Request it. For future renewals, the client will request that address, and if it is a renewal of an active lease on an active network interface - it will unicast it only to the server that gave it the lease in the first place.

If a server fails, then the clients will eventaully run out of lease, and will go off and get another (different) one from another server. The fact that clients will change address (and hence drop any open connections) may or may not be an issue for your users. To survive failure of a server, you need enough addresses on "N-1" servers to service the client base. Thus (for example) four servers with 160 addresses between them could service 120 clients with one server down, or 80 with two servers down.

This does mean that you need sufficient available addresses to provide this redundancy - unlike failover where (once you set the state correctly) one server can take over the entire pool.


You can also run multiple failover pairs - eg you could have 3 pools and 3 servers - paired off so one pool is serviced by A & B, another by B & C, and the third by C & A. Obviously this quickly gets complex to manage/maintain and I can't recall hearing of anyone doing it.