If you have a cluster of statically-addressed DHCP-server nodes, and a cluster of dynamically-addressed PXE-boot nodes that from those DHCP nodes, and a cluster of statically-addressed PXE-boot nodes that boot from those DHCP nodes...

Given the precondition that the DHCP-server nodes should (at all times) contain the exact same PXE image and the exact same DHCP configuration (including static leases & dynamic ranges), is there any reason to not have all the DHCP servers running at once?

The way I figure, the worst case scenario is this (all DHCP servers running with identical configurations):
- DynamicClient#1 gets IP/lease randomly from Server#1
- Server#1 goes down
- DynamicClient#1 needs to renew/replace its lease, but cant find Server#1
- DynamicClient#1 gets new IP (maybe) and lease randomly from Server#2
- Server#1 comes back up (with old lease for DynamicClient#1)
- Some time later Server#1 scrubs the leases

For static clients, there is no issue, because even if the lease is handed out by a different server, it is always guaranteed to be the same IP.

I have seen numerous people say "this is bad" but never has one of them really given many details... and as far as theory goes, I personally haven't found the hole... in fact, it would seem that "homogeneous DHCP" would offer premium fail-over protection.

Am I missing something?

As each DHCP server would not know what addresses the others had handed out there is nothing stopping them from handing out the same address if requested resulting in an ip conflict.

The way around this SPOF is to use contiguous address ranges with enough capacity to absorb the leases of a failed DHCP server node

eg.
dhcpserver01 - [192.168.0.1-192.168.0.80]
dhcpserver02 - [192.168.0.81-192.168.0.160]
dhcpserver03 - [192.168.0.161-192.168.0.240]

In this configuration, the loss of a single dhcp server would result in - maximum number of addresses = (n-1)*80 = 160

If you have more than this many dhcp clients then you can increase the number of servers to 4 ( inefficient) -
maximum number of addresses = (n-1)*60 = 180

or change the subnet to a supernet and increase the ranges for a maximum > 254

The second option is to use active/passive clustering where the loss of a single node (dhcp server) has no impact on the number of available addresses.

cheers

Ahh, interesting... so are you saying DHCP has a non-resolved race condition?
I mean, why is the DHCP-client not required to ARP-test the set address? (ala Link-Local Addressing - aka APIPA)

This would mean, set the address on both clients... ARP for duplicate address... re-pick both on "duplicates found"
It just seems strange that a protocol like DHCP would allow for a (albeit impossibly rare) use-case that delivers all dynamic clients the exact same address... ok, ok, ok, granted DHCP preceded clustering by just a bit...

Is there a DHCP-client out there that employs this ARP test?


Anyway, I think I have been personally avoiding this given some "likelihoods", and "really short leases"...
- If there is a conflict, then on re-lease, the conflict will be discovered due to the client asking for address X and the duplicate server responding that X is already taken by a different MAC.
- If the client has a valid lease, then it will continually renew that lease, instead of re-IPing. (Static clients are guaranteed of this even if the lease-expire case - dynamic clients should be robust enough to handle IP switching anyway)


Given that DHCP-lease traffic is relatively benign, what (besides lots of log messages) do I have to loose with my personal approach?

It's not a race condition as such, the dhcp process is just very simple - a client sends a dhcp discover packet, and any dhcp servers that receive it respond with an offer. The client will accept the first one it receives by responding back to that server.

This is why rogue dhcp servers on the network can cause so much trouble, handing out wrong subnet masks, default gateways, conflicting addresses etc

You'd have to check the rfc's to see what changes are in the pipeline -
http://www.ietf.org/dyn/wg/charter/dhc-charter.html

cheers