Glossary

DHCP Failover

What is DHCP Failover

DHCP Failover is a technology for improving the reliability and availability of DHCP (Dynamic Host Configuration Protocol) service. In a traditional DHCP deployment, a single DHCP server typically handles all address assignment, lease management, default gateway, and DNS configuration for clients on the network — leaving that server a single point of failure. DHCP Failover addresses this by establishing a cooperative relationship between two DHCP servers, allowing them to work together to handle a single server failing or becoming overloaded.

The two servers share the same address pool, lease database, reservations, options, and policies through this failover relationship, so either server can respond to and service client requests consistently.

How DHCP Failover Works

Two servers — a Primary and a Secondary — maintain their relationship through a defined message exchange: CONTACT messages are periodically exchanged to verify the link between the pair is healthy and stays active even when no other traffic is flowing. If the pair needs to (re-)establish a session, CONNECT initiates it and CONNECTACK confirms the connection succeeded. STATE messages exchange status information such as current load and address pool usage. When either server allocates, renews, or releases a lease, it synchronizes that change to its partner via BNDUPD (Binding Update), which the partner acknowledges with BNDACK (Bind Acknowledge) — this is what keeps both servers' lease databases consistent.

Built on this exchange, a DHCP Failover pair moves through three operating states:

  1. Normal: CONTACT messages are exchanging normally, meaning both servers are healthy and can see each other. Each server owns a configured share of the address pool, set by a split value (0–100, representing the Primary server's percentage of the load). When a client requests an address, both servers receive the request, but only one responds — determined by hashing the client's CLIENT_IDENTIFIER to decide which server is responsible for that client. Whichever server assigns the address synchronizes the lease information to its partner via DHCP Failover; a client renewing its lease can do so through either server.

  2. Communications_interrupted: entered when a server misses three consecutive CONTACT messages from its partner, i.e. no contact for a duration of max-response-delay (default 60 seconds). Each server still owns half the address pool. When a new client requests an address, a server first checks whether it's the one responsible for that client; if so, it allocates immediately, and if not, it holds off and waits up to 3 seconds to see whether it continues receiving DHCP DISCOVER messages from that client — if so, it allocates the address itself rather than risk a conflict. When communication is restored, servers resynchronize lease information and clients can renew through either server again.

  3. Partner_down: entered when communication remains interrupted for longer than auto-partner-down seconds. The surviving server considers its partner offline and, after a further Maximum Client Lead Time (mclt, default 3600 seconds) has elapsed, takes over the entire address pool. In this state, the surviving server allocates addresses to new clients based on client information and pool state, and clients can only renew leases through the surviving server.

Why DHCP Failover is Beneficial

The core value of DHCP Failover lies in eliminating a single point of failure and evening out load across two cooperating servers:

· No single point of failure: In enterprise or data center environments, if the sole DHCP server fails — hardware fault, software crash, or network disruption — clients can't obtain new addresses or renew existing leases, breaking network connectivity. A DHCP Failover pair ensures the surviving server can take over quickly when one server fails, keeping service continuous.

· Faster recovery than manual intervention: Traditional recovery (rebooting or reconfiguring a failed server) requires manual intervention and results in longer downtime. DHCP Failover automates the failover process, minimizing downtime and business impact.

· Load balancing under high request volume: In environments with large numbers of devices — enterprise campuses, schools, hotels — a single DHCP server can struggle to keep up with request volume. DHCP Failover's split-based load balancing distributes requests evenly across both servers, improving overall processing capacity and response time.

· Configurable failure detection and recovery timing: max-response-delay and auto-partner-down give operators direct control over how quickly a pair declares its partner unreachable and takes over the full pool, letting the tradeoff between fast failover and false-positive risk be tuned to the environment.

At Asteraix

What We Can Do at Asteraix

AsterNOS implements DHCP Failover with a dedicated configuration mode and full support for the Normal / Communications_interrupted / Partner_down state model:

· Dedicated failover configuration mode: configure dhcp failover <name> establishes a named failover relationship, with address and peer address defining the local and partner IP (a loopback address is commonly used), role primary/secondary assigning each server's role, and split 1-100 setting the load-sharing ratio between them.

· Tunable failure detection: max-response-delay <seconds> (default 60s if unset) controls how long without a CONTACT message before a server considers communication interrupted, and auto-partner-down <seconds> controls how long an interruption persists before the surviving server declares its partner down — Asteraix recommends explicitly configuring auto-partner-down, since without it a server will never automatically transition into partner_down state.

· Integration with DHCP Pool and DHCP Relay: A DHCP pool is bound to its failover relationship via failover <name> inside dhcp pool, and works transparently behind a standard dhcp-relay configuration with multiple server_ip entries pointing at both the primary and secondary servers.

· Deployment guidance for lease timing: Asteraix recommends configuring DHCP lease time to at least 3x the mclt value, so that a client's renewal request always falls within a window longer than the time a server pair could spend in communications_interrupted state — avoiding a scenario where a client fails to renew and has to re-acquire an address, causing a brief network interruption.

· Full operational visibility: show dhcp failover displays the failover name, local/peer addresses, role, configured timers, current local and peer state (normal/communications_interrupted/partner_down), and the configured split ratio — giving operators a single command to check pair health.

· Typical deployment: A Primary and Secondary DHCP server each own half the address pool (via split 50) and sit behind a DHCP Relay that forwards client requests to both. Under Normal operation, load is split evenly and either server can service renewals; if the servers lose contact with each other, they degrade gracefully through Communications_interrupted (still each serving their own known clients) before one takes over the full pool in Partner_down — so that neither a single server failure nor a single link failure interrupts DHCP service to clients downstream.