DHCP Failover with relay that only sends requests to a single server

[Chris Buxton]

On Feb 18, 2014, at 5:00 AM, Leigh Porter <leigh.porter at ukbroadband.com> wrote:

> I would like to create a DHCP failover group for a number of relay agents. However, although these agents can be configured with a primary and secondary DHCP server, they only try them in sequence (i.e. they will send the request to one and then the other if that fails to respond).

There are network devices (switches, routers, firewalls) that can be configured this way. The ISC DHCP relay agent does not operate this way. You should not use this type of arrangement with ISC's implementation of DHCP failover — failover is designed to have both peers receive every new lease request (discover message). They then determine automatically which one will answer the request.

This type of relay behavior works well with split scopes, as you would typically set up with DHCP servers that don't utilize failover (whether capable of it or not — you could use split scopes with ISC DHCP, but you would lose the benefits of failover).

> So I can configure a load balance of 255 and cause the primary server to answer all new requests and then the secondary should answer renews if it ever gets them. However, the secondary server will never answer requests as it has no pool available.

I'm by no means an expert on failover — I'm continually amazed by the creative ways people get dhcpd to work the way they want, rather than the way in which I'm accustomed to seeing it work. But I don't believe failover can be made to work that way. I believe you have a few misconceptions:

- The failover peering arrangement is defined per-pool — the dynamic pool must be shared between them. They will divvy up the free addresses 50/50 between them, rebalancing as needed.
- A 255/0 split is not 100% to 0% service. The lower-numbered peer (with the split value of 0) will still be expected to answer a small number of lease requests.

> Could I configure two failover groups with both servers to be primary in one group for a pool and then secondary for eachother? Or is there a nicer way to achieve this?

I've never seen that done.

Why do you want to do these things? Both peers must record every lease, so you won't see much of a performance advantage for any given lease, if any. You'll add a lot of network traffic, since the peers will be constantly rebalancing the pools, in addition to synchronizing all of the leases. You'll decrease your overall performance, since you won't be spreading the load evenly between the two peers. And DHCP clients are pretty forgiving of performance hiccups — 3000 ms to obtain a lease should be within tolerances.

Regards,
Chris Buxton