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; 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..
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.
[Michael McNally]: Re: Failover without load balancing2014-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.
[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 range2013-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 range2013-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.
Hello,
Is it possible to configure the failover without load balancing ?