• Print
  • Share
  • Dark

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

  • Updated on 03 May 2017
  • 3 minutes to read
  • Contributors 


Are there any recommendations on the feasibility of running geographically-separated (e.g. two corners of the U.S) 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.The decision on which server to process a client's request . In order 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.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.

© 2001-2018 Internet Systems Consortium For assistance with problems and questions for which you have not been able to find an answer in our Knowledge Base, we recommend searching our community mailing list archives and/or posting your question there (you will need to register there first for your posts to be accepted). The bind-users and the dhcp-users lists particularly have a long-standing and active membership. ISC relies on the financial support of the community to fund the development of its open source software products. If you would like to support future product evolution and maintenance as well having peace of mind knowing that our team of experts are poised to provide you with individual technical assistance whenever you call upon them, then please consider our Professional Subscription Support services - details can be found on our main website.

Problems with this site? Email us at marketing@isc.org