Knowledge Base ISC Main Website Ask a Question/Contact ISC
A Basic Guide to Configuring DHCP Failover
Author: Michael McNally Reference Number: AA-00502 Views: 130335 Created: 2011-10-20 22:45 Last Updated: 2017-06-22 15:39 0 Rating/ Voters

Setting Up DHCP Failover: A Basic Overview 

Many of the syntax options presented here are explained in more detail in the dhcpd.conf man page distributed with dhcp. It is recommended that you consult that document for specifics once you have grasped the basic steps involved.

1)  Select your servers.  Choose one to be primary, the other to be secondary.  Different versions of ISC dhcpd may implement failover differently.  To avoid problems, use the same version (or as close as possible) on both machines of a failover pair.
2)  Ensure that clocks are closely synchronized.  DHCP is a time-sensitive protocol and clock skew can cause problems.
3)  Identify the networks and address pools that will be served.
4)  Identify other network elements that will have to be aware of both servers.  Configure DHCP relays to relay forwarded discovers and requests to both servers.  Ensure that firewalls and filters allow DHCP traffic, OMAPI control channel traffic, and failover protocol messages to reach your servers.
5)  Add declaration blocks for the failover peers to the configuration files on the primary:

    failover peer "failover-partner" {
        port 519;
        peer address;
        peer port 520;
        max‐response‐delay 60;
        max‐unacked‐updates 10;
        mclt 3600;
        split 128;
        load balance max seconds 3;

..and secondary:

    failover peer "failover-partner" {
        port 520;
        peer address;
        peer port 519;
        max‐response‐delay 60;
        max‐unacked‐updates 10;
        load balance max seconds 3;

The parameter mclt (Maximum Client Lead Time) must be defined on the primary.  It must NOT be defined on the secondary.  "split" (or its alternate, "hba") is another parameter that should be defined on the primary and omitted from the configuration on the secondary.  For further information on these configuration parameters see the dhcpd.conf man page.

6)  Add peer references to each subnet / pool for which you want to do failover.  e.g.:

subnet netmask {
   option domain-name-servers;
   option routers;
   pool {
       failover peer "failover-partner";

7)  Configure OMAPI and define a secret key.

# insert this (with your own key text substituted) into dhcpd.conf on primary and secondary..

omapi-port 7911;
omapi-key omapi_key;

key omapi_key {
     algorithm hmac-md5;
     secret Ofakekeyfakekeyfakekey==;

Key Generation Hint

You can generate good random OMAPI keys using the dnssec-keygen utility, distributed with BIND.

e.g.:  dnssec‐keygen ‐a HMAC‐MD5 ‐b 512 ‐n USER DHCP_OMAPI

8)  Restart the servers to apply your configuration changes.
9)  Test.   If OMAPI is working properly you can test failover by putting a server into shutdown.
10)  Put all servers back into operation.  You're good to go.

Considerations for geographically-separated failover pairs

Note that the dialogue between failover partners is neither encrypted nor authenticated.  Since most DHCP servers exist within an organisation's own secure Intranet, this would be an unnecessary overhead.  However, if you have DHCP failover peers whose communications traverse insecure networks, then we recommend that you consider the use of VPN tunneling between them to ensure that the failover partnership is immune to disruption (accidental or otherwise) via third parties.

© 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.

Feedback 6
  • #
    [ Pascal]: Failover without load balancing 2014-02-28 15:24


    Is it possible to configure the failover without load balancing ?

  • #
    [Michael McNally]: Re: Failover without load balancing 2014-03-04 00:01

    That's what the "split" or "hba" values are for -- you can read more about them in the dhcpd.conf man page.

    Setting a split value of 128 divides responsibility for the clients between the two failover partners. But if you want one partner to be principally responsible for all clients and the other partner to only grant leases if the client has been retrying for more than a certain number of seconds or if the peer is in partner-down state, you can set the split to 0 (secondary is chiefly responsible for answering) or 255 (primary is chiefly responsible for answering.)

    "split" and "hba" are mutually exclusive -- you can use one or the other but never both.

    You may also want to read about the "load balance max seconds" setting, which tells how long a client is expected to retry before the peer will answer even for clients for which it is not principally responsible.

  • #
    [ Marty]: Why different TCP ports for primary and secondary? 2014-02-10 03:12


    Is it important that different TCP ports be used on the primary and secondary partners? I've seen this in various examples.

  • #
    [Cathy Almond]: Re: Why different TCP ports for primary and secondary? 2014-02-11 18:41

    No - they can be the same or they can be different (and can be any port or ports that you choose that work for you within the policies that you have for your network infrastructure).

  • #
    [Graham]: Best practice host and pool range 2013-08-08 09:42

    With reference to step 6 of this article,

    A recent discussion on the dhcp-users mailing list (subject 'DHCP "static" assignments', first mail dated Wed, 7 Aug 2013 12:01:04 -0700) has suggested that best practice is to define hosts outside of a subnet definition, rather than inside, and to exclude fixed-addresses from a pool's ranges. I would suggest updating this article to reflect this best practice.

  • #
    [Brian Conry]: Re: Best practice host and pool range 2013-10-22 16:55

    Thanks for bringing this to our attention.

    I've decided that rather than overwhelm this "Basic Guide" with a lot of explanation of the interactions between host entries, pools, and failover, it would be better to simply remove the host entry from the example. Those interactions deserve an article of their own.

Quick Jump Menu