11.3 DHCP High Availability & Failover Configurations

DHCP High Availability & Failover Configurations

Enterprise network resiliency demands that core infrastructure services such as Dynamic Host Configuration Protocol (DHCP) remain continuously available despite hardware failures, hypervisor maintenance, or network partitioning. Legacy redundancy methods—such as Split-Scope DHCP (the 80/20 rule) and Windows Server Failover Clustering (WSFC)—introduced significant administrative overhead, IP address waste, and single points of failure. Windows Server native DHCP Failover (RFC 3074) delivers high availability and load balancing across two independent DHCP servers without shared storage.

---

1. High Availability Comparison: Failover vs. Split-Scope vs. Clustering

+-----------------------------------------------------------------------------+
|                  DHCP HIGH AVAILABILITY ARCHITECTURE MATRIX                 |
|                                                                             |
|   FEATURE             DHCP FAILOVER        SPLIT-SCOPE (80/20)   WSFC CLUSTER|
|   ------------------+--------------------+---------------------+------------|
|   Redundancy Model  | Active-Active or   | Active-Passive      | Active-    |
|                     | Active-Passive     | (No Sync)           | Passive    |
|   Shared Storage    | NONE (Shared-      | NONE                | Mandatory  |
|                     | Nothing Engine)    |                     | (SAN/S2D)  |
|   Scope State Sync  | Real-time via      | None (Manual        | Shared DB  |
|                     | TCP Port 647       | reconciliation)     | on disk    |
|   IP Pool Efficiency| 100% Shared Pool   | Fragmented (20%     | 100% Single|
|                     | Utilization        | wasted per subnet)  | Pool       |
|   Failover Speed    | Instantaneous      | Delayed (via delay) | 30-60s Fail|
|   Protocol Support  | IPv4 Scopes Only   | IPv4 & IPv6         | IPv4 & IPv6|
+-----------------------------------------------------------------------------+

Detailed Redundancy Models:

1. Native DHCP Failover (Recommended Enterprise Standard):
   • Operates between exactly two Windows Server DHCP servers per failover relationship.
   • Synchronizes lease allocations, reservations, and scope options over TCP port 647 using mutual shared-secret HMAC-SHA256 authentication.
   • Does not require shared storage, cluster nodes, or identical hardware.
   • Limitation: Native DHCP Failover supports IPv4 scopes only. IPv6 scopes achieve high availability through independent dual-server stateless setups or router advertisements (RFC 4861).
2. Split-Scope DHCP (Legacy 80/20 Rule):
   • Divides a single subnet's address space between two servers (Server A manages 80%, Server B manages 20%).
   • Server B is configured with a 1,000 ms response delay to ensure Server A responds first under normal operations.
   • Drawbacks: No lease synchronization; if Server A fails during high demand, Server B's 20% pool can quickly exhaust, leaving clients unable to lease addresses.
3. DHCP Failover Clustering (WSFC):
   • Deploys a single DHCP Server instance across a Windows Server Failover Cluster sharing a clustered disk volume.
   • Drawbacks: Only one node is active at any time; failover requires mounting the shared disk and starting the DHCP service (30–60 seconds of disruption); introduces shared storage complexity.

---

2. DHCP Failover Modes: Load Balance vs. Hot Standby

+-----------------------------------------------------------------------------+
|                   DHCP FAILOVER OPERATIONAL MODES                           |
|                                                                             |
|   [LOAD BALANCE MODE: Active-Active]     [HOT STANDBY MODE: Active-Passive] |
|                                                                             |
|   DHCP-SRV01           DHCP-SRV02        DHCP-PRIMARY         DHCP-STANDBY  |
|   (50% Traffic)        (50% Traffic)     (100% Leases)        (5% Reserve)  |
|        \                  /                   |                     :       |
|         \                /                    |                     :       |
|       [Client MAC Hash Algorithm]             v                     v       |
|                 |                        (Active Leases)    (Takes over if  |
|                 v                                            Primary down)  |
|       [All Client Requests]                                                 |
+-----------------------------------------------------------------------------+

Mode 1: Load Balance (Active-Active - Default)

• Mechanics: Both partner servers actively service client requests concurrently on the same subnet.
• MAC Hashing Algorithm: When a client broadcasts a DHCPDISCOVER, both servers receive the packet. Each server runs a deterministic hash algorithm on the client's hardware MAC address. Based on the configured Load Percentage Split (e.g., 50/50, 70/30), only the server responsible for that hash bucket responds.
• Use Case: Best suited for single-site datacenters or campuses with high DHCP transaction volumes where both servers reside in close physical proximity.

Mode 2: Hot Standby (Active-Passive)

• Mechanics: One server is designated as Active Primary, and the partner server is designated as Passive Standby (Secondary).
• Normal Operation: The Primary server issues 100% of client leases and updates the Standby partner in real time via TCP port 647. The Standby server remains passive and does not respond to client requests.
• Standby Reserve Percentage (Default 5%): The portion of unallocated IP addresses permanently assigned to the Standby partner. If the Primary server fails, the Standby server immediately services new clients using this reserve pool during the initial failure window.
• Use Case: Ideal for hub-and-spoke or branch office architectures where a central datacenter server acts as a passive standby for multiple remote branch DHCP servers.

---

3. Failover State Machine, MCLT & State Switchover Interval

Understanding the DHCP Failover state machine and timer interactions is critical for troubleshooting outage scenarios and preventing split-brain conditions.

+-----------------------------------------------------------------------------+
|                     DHCP FAILOVER STATE TRANSITION FLOW                     |
|                                                                             |
|   +------------+   Loss of TCP 647 Heartbeat    +-------------------------+ |
|   |   NORMAL   | -----------------------------> | COMMUNICATIONS-         | |
|   |  (In Sync) |                                | INTERRUPTED             | |
|   +------------+                                +-------------------------+ |
|         ^                                                    |              |
|         | (Partner Restored & Synced)                        | Switchover   |
|         |                                                    | Timer Expires|
|   +------------+       Surviving Node Assumes 100% Pool      v              |
|   |  RECOVER   | <----------------------------- +-------------------------+ |
|   |   STATE    |    (After MCLT duration passes)|       PARTNER-DOWN      | |
|   +------------+                                +-------------------------+ |
+-----------------------------------------------------------------------------+

Key Concepts & Timers:

1. COMMUNICATIONS-INTERRUPTED State:
   • When a server loses communication with its partner over TCP 647, it enters COMMUNICATIONS-INTERRUPTED.
   • In this state, neither server knows if the partner is dead or if a network partition occurred.
   • Lease Handling: The surviving server continues servicing its own clients. For new clients or partner clients, it grants temporary leases equal to the Maximum Client Lead Time (MCLT).
2. Maximum Client Lead Time (MCLT - Default 1 Hour):
   • MCLT is the maximum time a server can extend a client lease beyond the lease time known by its partner.
   • When in COMMUNICATIONS-INTERRUPTED, the standby/partner server issues new leases valid only for the duration of the MCLT (e.g., 1 hour instead of 8 days).
   • When transitioning from COMMUNICATIONS-INTERRUPTED to PARTNER-DOWN, the surviving server must wait for the MCLT interval to elapse before it can assume control of the partner's entire IP address pool and issue full-length leases.
3. State Switchover Interval:
   • By default, a server in COMMUNICATIONS-INTERRUPTED will NEVER transition to PARTNER-DOWN automatically; an administrator must manually open DHCP Manager or run PowerShell to set the state.
   • If Automatic State Transition is enabled (-AutoStateTransition $true) with a State Switchover Interval (e.g., 60 minutes), the surviving server automatically transitions itself to PARTNER-DOWN once communication has been interrupted for that duration.

[!CAUTION] The Split-Brain Risk of Short Switchover Intervals: Setting the State Switchover Interval too short (e.g., under 30 minutes) creates a catastrophic risk during transient network routing disruptions. If both servers transition to PARTNER-DOWN simultaneously while isolated from each other, both servers begin leasing 100% of the scope independently, resulting in duplicate IP address assignments across the enterprise.

---

4. PowerShell Configuration for DHCP Failover

Deploying and managing DHCP Failover relationships via PowerShell provides declarative, scriptable control over replication and configuration synchronization.

# 1. Create an Active-Active Load Balance Failover Relationship (50/50 Split)
Add-DhcpServerv4Failover `
    -ComputerName 'DHCP01.corp.contoso.com' `
    -Name 'DHCP01-DHCP02-LoadBalance' `
    -PartnerServer 'DHCP02.corp.contoso.com' `
    -ScopeId 10.10.1.0 `
    -Mode LoadBalance `
    -LoadPercent 50 `
    -MaxClientLeadTime (New-TimeSpan -Hours 1) `
    -AutoStateTransition $true `
    -StateSwitchoverInterval (New-TimeSpan -Minutes 60) `
    -SharedSecret 'S3cur3F@1l0v3rP@ss2026!'

# 2. Create an Active-Passive Hot Standby Failover Relationship
Add-DhcpServerv4Failover `
    -ComputerName 'DHCP01.corp.contoso.com' `
    -Name 'DHCP01-DHCP02-HotStandby' `
    -PartnerServer 'DHCP02.corp.contoso.com' `
    -ScopeId 10.10.2.0 `
    -Mode HotStandby `
    -ServerRole Primary `
    -ReservePercent 5 `
    -MaxClientLeadTime (New-TimeSpan -Hours 1) `
    -AutoStateTransition $true `
    -StateSwitchoverInterval (New-TimeSpan -Minutes 60) `
    -SharedSecret 'S3cur3F@1l0v3rP@ss2026!'

# 3. Replicate Scope Configuration Changes to Partner Server
# (DHCP Failover synchronizes leases automatically, but SCOPE OPTION changes require replication!)
Invoke-DhcpServerv4FailoverReplication `
    -ComputerName 'DHCP01.corp.contoso.com' `
    -Name 'DHCP01-DHCP02-LoadBalance' `
    -Force

[!IMPORTANT] Scope Option Replication Rule: While DHCP Failover synchronizes active IP lease states dynamically across TCP 647 in real time, administrative scope changes (such as adding a new reservation, changing a DNS server option, or modifying exclusions) ARE NOT automatically replicated. Administrators must manually execute Invoke-DhcpServerv4FailoverReplication or select 'Replicate Scope' in DHCP Manager after making configuration edits.

---

5. DHCP Database Maintenance, Compaction & Migration

Windows Server DHCP utilizes the Extensible Storage Engine (ESE / JET) database engine. The database files reside in %SystemRoot%\System32\dhcp (dhcp.mdb, j50.log, dhcp.tmp).

Automated Database Backups:

• The DHCP server automatically backs up its database every 60 minutes by default to %SystemRoot%\System32\dhcp\backup.
• The backup path and interval are stored in the Windows Registry under HKLM\SYSTEM\CurrentControlSet\Services\DHCPServer\Parameters as the BackupDatabasePath and BackupInterval values, and both are settable with Set-DhcpServerDatabase -BackupPath <path> -BackupInterval <minutes>. The backup folder must be a local path.

Offline Database Compaction (Jetpack.exe):

As leases are created, expired, and deleted, the dhcp.mdb file accumulates whitespace and database fragmentation. Windows Server automatically performs online compaction, but severe fragmentation requires offline compaction via Jetpack.exe:

:: Stop the DHCP Server service
net stop dhcpserver

:: Navigate to DHCP database directory
cd /d %SystemRoot%\System32\dhcp

:: Compact dhcp.mdb into a temporary database file
jetpack.exe dhcp.mdb temp_dhcp.mdb

:: Restart the DHCP Server service
net start dhcpserver

DHCP Server Migration (Export-DhcpServer & Import-DhcpServer):

When upgrading legacy Windows Server DHCP servers to Windows Server 2022 or 2025, administrators use the PowerShell DHCP migration cmdlets to export all scopes, active leases, reservations, and server settings into a single XML artifact:

# On Legacy Source Server: Export all scopes, active leases, and options
Export-DhcpServer `
    -ComputerName 'DHCP-2016.corp.contoso.com' `
    -File 'C:\Migration\DhcpConfig.xml' `
    -Leases `
    -Force

# On Target Server: Import full configuration, leases, and activate
Import-DhcpServer `
    -ComputerName 'DHCP-2025.corp.contoso.com' `
    -File 'C:\Migration\DhcpConfig.xml' `
    -Leases `
    -BackupPath 'C:\DHCP_Backup' `
    -Force