A Basic Guide to Configuring DHCP Failover

Author: Michael McNally Reference Number: AA-00502 Views: 41930

Created: 2011-10-20 22:45 Last Updated: 2014-10-28 15:27

0 Rating/ Voters

Setting Up DHCP Failover: A Basic Overview

Many of the syntax options presented here are explained in more detain 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;
port 519;
peer address dhcp-secondary.example.com;
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" {

secondary;
address dhcp-secondary.example.com;
port 520;
peer address dhcp-primary.example.com;
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 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;
}
}

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-2015 Internet Systems ConsortiumPlease help us to improve the content of our knowledge base by letting
us know below how we can improve this article. If you have a technical question or problem on which you'd like
help, please don't submit it here as article feedback. 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.