DHCP failover doesn't receive DHCP requests in secondary server

[Simon Hobson]

Gregory Sloop <gregs at sloop.net> wrote:

> ...because the only reason I can see to have it run with more leases to one peer vs the other would be if one of the peers couldn't handle all the load, while running even. But then how in the world would one expect the machine that can't even handle half the load to survive when in a peer-down situation where it has to handle ALL the load, and likely more heavy than "normal," since all the non owned leases would get renewed at the MCLT time instead of the full regular lease time.
> 
> So I'm probably not thinking of some corner case, but I honestly can't think of a case where a non-even split makes the slightest sense. Thus the option, while nice - doesn't seem to have any real-world practical use.

I can think of one possible case - but it still comes under "but how would the remaining server cope".

In the past, one creative use of failover was to put a DHCP server in each pop, and configure all their pools in failover with a single central server. In practice, the distributed servers would take up the client load due to the extra round trip time for packets from the clients going back to the central server and back - but setting the split value would (I guess) force the issue anyway.
The main reason for doing this was to use the failover protocol to create a real-time backup of the leases in a central place (where it's easy to arrange stable power etc) and not have to worry about (eg) power cuts at the pop messing up the server there - the server would not even need to have persistent storage, it could save on ramdisk (good performance) and sync the leases from the central server any time it gets rebooted (eg if there's a power cut).
But even then, you have to consider the effect of a widespread power failure and what happens when all your pops (and their connected customers) come back on line together.