A Basic Guide to Configuring DHCP Failover
  • 14 Sep 2022
  • 2 Minutes to read
  • Contributors
  • Dark
    Light
  • PDF

A Basic Guide to Configuring DHCP Failover

  • Dark
    Light
  • PDF

Article Summary

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" {
     primary;
     address dhcp-primary.example.com;
     peer address dhcp-secondary.example.com;
     max-response-delay 60;
     max-unacked-updates 10;
     mclt 3600;
     split 128;
     load balance max seconds 3;
}

...and secondary:

failover peer "failover-partner" {
     secondary;
     address dhcp-secondary.example.com;
     peer address dhcp-primary.example.com;
     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.

  1. Add peer references to each subnet / pool for which you want to do failover.  e.g.:
subnet 10.100.100.0 netmask 255.255.255.0 {
    option domain-name-servers 10.0.0.53;
    option routers 10.100.100.1;
    pool {
        failover peer "failover-partner";
        range 10.100.100.20 10.100.100.254;
    }
}
  1. 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==;
}



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

  1. Restart the servers to apply your configuration changes.
  2. Test. If OMAPI is working properly you can test failover by putting a server into shutdown.
  3. 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.