DHCP failover peers at a distance - configuration, loading and bandwidth considerations
  • 25 Oct 2018
  • 2 Minutes to read
  • Contributors
  • Dark
  • PDF

DHCP failover peers at a distance - configuration, loading and bandwidth considerations

  • Dark
  • PDF

Article summary


Are there any recommendations on the feasibility of running geographically-separated (e.g. two corners of the US) DHCP failover peers on a public network?  What is the practical minimal communication channel requirement?


We know of users doing similar things and it appears to be working for them. We do not have information about the quantities involved (number of leases, number of leases per second, bandwidth, etc).

As with most things DHCP, the answer is "it depends." The minimal bandwidth will depend on the number of leases and the churn rate (how often a lease is renewed).

There are several things that would affect the required bandwidth:

  1. At start up and while running the two servers will balance their pools. This means leases will be split between the two and there will be traffic to do the negotiation. A larger pool will increase the amount of traffic required to do the balancing. The run-time balancing will be based on the number and rate of leases being assigned.

  2. When a lease is handed to a client, each server will need to update the other. A larger number of leases being handed out or a higher lease churn rate will lead to a larger required bandwidth.

  3. Users can decide which server to use to process a client's request. For the failover pair to be useful, all of the broadcast requests need to be sent to both servers. However, there are options for having one server prefer serving some clients while the other server prefers the other clients. See the split, hba and load balance options. These options can be tuned such that the preferred server is the local one and only if it doesn't answer will the client fall back to the remote server. 

    For bandwidth calculations you need to have all of the broadcasts going to both servers as well as replies for those clients for which the remote server is preferred. During an outage of the local server you need to provide bandwidth sufficient for the remote server to handle all replies.

  4. Size will vary based on what information is being served. A typical DHCP packet is not overly large but its size is determined by which options are configured.

  5. The use of fixed leases can reduce the need for failover. While two servers cannot share a pool of addresses without using failover, they can share fixed addresses without failover as long as the information for use with the fixed address is identical.

    Fixed addresses need to be either unique to one server or identical on both
    Woe unto he who configures the same fixed address on two different DHCP servers for two different clients!
  6. If the desire for failover is being driven by a small number of known clients (for example several printers), they could be configured as fixed addresses on both servers with the rest of the address pool split between the servers in a non-failover configuration. A client switching between the two servers would get a different address and the pool needs to be sufficiently large to support this arrangement, but it would simplify the set-up.