Problem solve Get help with specific problems with your technologies, process and projects.

DHCP Failover

Learn about some of the advances in DHCP Failover protocol.

Dynamic Host Configuration Protocol (DHCP) service is a vital component of all but the smallest networks, however...

the existing standard provides for limited DHCP server redundancy. Work now underway in the DHCP Working Group of the Internet Engineering Task Force (IETF) adds DHCP Failover to provide uninterrupted service to DHCP clients when a DHCP server or a network link fails, preventing clients from reaching a server.

When the majority of clients were desktop PCs, the need for DHCP redundancy was not as pressing. Addresses were assigned with longer lease periods and a DHCP server failure would not immediately be noticed by the clients. The mobility of laptops increases the importance of DHCP reliability since they acquire new addresses more frequently.

Request for Comments (RFC) 2131, the defining standard for DHCP, provides for a very simple form of redundancy. Two or more DHCP servers can operate on the same network. Each maintains a separate pool of addresses. There is no communication between the servers. When a client boots, it sends out a request for a lease. Any server on the network can respond, and the client usually accepts the first response it receives. Once a client accepts a lease from a server, it must contact that server to renew the lease. Other servers on the network cannot renew the lease since they have no information about it.

This simple form of redundancy has several shortfalls. Maintaining multiple separate pools requires a greater number of addresses. An additional shortfall is that when a server fails, leases received from it will eventually expire. The client will receive a new lease from another server. This lease will be for a different address since the servers have separate address pools. A change in address will abruptly break any existing connections.

DHCP Failover Protocol, defined by draft-ietf-dhc-failover-12, provides a mechanism for two DHCP servers to exchange the status of leases. If one of the servers fails or a network partition makes it impossible for a client to communicate with the server from which it received the lease, the other server can renew the lease. Existing connections will not break.

One server is designated the primary and another the secondary for each subnet address pool. One server can be primary for some subnets and secondary for others. Each primary and secondary pair exchange keep-alive messages.

Under normal operation the primary server responds to client requests and the secondary ignores them. After the primary responds to a client, it informs the secondary about the updated lease. If the secondary no longer receives keep-alives, it assumes either the primary has failed or some network path has failed. It then begins responding to client requests. The Failover protocol contains a complex set of states to deal with problems such as a network or server failure after granting a lease to a client but before updating the secondary, and a network failure in which a client can communicate with both servers but the servers cannot communicate with each other. After communication is restored between the servers, the secondary updates the primary with information on leases granted and extended while the primary was unavailable.

A benefit of failover in addition to redundancy is that when you need to upgrade hardware or software on one of the servers, you can simply shut it down. The other server will pick up the load. When the upgraded server comes back on line, the other server will automatically bring it up to date.

Even though the protocol has yet to be accepted as an RFC, several implementations exist. These include the Internet Systems Consortium (ISC) public domain implementation, Nominum Inc.'s Foundation, Cisco Systems' Network Registrar and Lucent's VitalQIP products. As your need for DHCP reliability increases, you should consider taking advantage of this new protocol in your network.

David B. Jacobs has more than twenty years of networking industry experience. He has managed leading-edge software development projects and consulted to Fortune 500 companies as well as software start-ups.


This was last published in February 2005

Dig Deeper on Network Infrastructure