Implementing Redundant DHCP Servers: Best Practices for Multiple Subnets and High Availability


3 views

Running multiple DHCP servers on a single LAN is not only possible but often recommended for redundancy. The key considerations are address scope management and server synchronization. Clients will accept the first DHCPOFFER they receive, meaning the response time between servers becomes critical.

For non-overlapping subnets, standard DHCP configuration works well:

# Server 1 configuration (192.168.1.0/24)
subnet 192.168.1.0 netmask 255.255.255.0 {
  range 192.168.1.100 192.168.1.150;
  option routers 192.168.1.1;
}

# Server 2 configuration (192.168.2.0/24) 
subnet 192.168.2.0 netmask 255.255.255.0 {
  range 192.168.2.100 192.168.2.150;
  option routers 192.168.2.1;
}

The most reliable approach for the same subnet involves dividing the address pool:

# Primary DHCP Server (80% of addresses)
subnet 192.168.1.0 netmask 255.255.255.0 {
  range 192.168.1.10 192.168.1.200;
  option routers 192.168.1.1;
  max-lease-time 3600;
}

# Secondary DHCP Server (20% of addresses)
subnet 192.168.1.0 netmask 255.255.255.0 {
  range 192.168.1.201 192.168.1.250;
  option routers 192.168.1.1;
  max-lease-time 1800; # Shorter leases for failover
}

Modern implementations support active-active synchronization:

failover peer "dhcp-failover" {
  primary;
  address dhcp-primary.example.com;
  port 647;
  peer address dhcp-secondary.example.com;
  max-response-delay 60;
  max-unacked-updates 10;
  load balance max seconds 3;
}

When implementing multiple DHCP servers:

  • Use identical lease times to prevent client confusion
  • Configure identical options (DNS, NTP, etc.) on all servers
  • Monitor response times to ensure predictable behavior
  • Consider using DHCP snooping on network switches

Running multiple DHCP servers on the same LAN is technically possible but requires careful configuration to avoid conflicts. DHCP operates via broadcast messages, so clients will receive offers from all available servers. The client typically accepts the first offer it receives, which can lead to unpredictable behavior if servers aren't properly synchronized.

When multiple DHCP servers exist on a network:

  • Clients broadcast DHCPDISCOVER packets to all servers
  • All available servers respond with DHCPOFFER
  • The client usually accepts the first offer received
  • This can cause address conflicts if servers aren't properly partitioned

For serving multiple subnets, you can configure DHCP servers with different scopes:

# Example ISC DHCPD configuration for multiple subnets
subnet 192.168.1.0 netmask 255.255.255.0 {
    range 192.168.1.100 192.168.1.200;
    option routers 192.168.1.1;
}

subnet 192.168.2.0 netmask 255.255.255.0 {
    range 192.168.2.100 192.168.2.200;
    option routers 192.168.2.1;
}

For redundancy on the same subnet, you have several options:

  1. Split Scopes: Divide the address range between servers (80/20 split is common)
  2. DHCP Failover Protocol: Use the ISC DHCP failover protocol for automatic synchronization
  3. Load Balancing: Configure servers to respond in a balanced manner

Example split scope configuration:

# Primary DHCP Server (80% of addresses)
subnet 192.168.1.0 netmask 255.255.255.0 {
    range 192.168.1.100 192.168.1.180;
    option routers 192.168.1.1;
}

# Secondary DHCP Server (20% of addresses)
subnet 192.168.1.0 netmask 255.255.255.0 {
    range 192.168.1.181 192.168.1.200;
    option routers 192.168.1.1;
}
  • Always maintain non-overlapping address pools
  • Use DHCP failover protocol when possible for automatic synchronization
  • Monitor lease databases for consistency
  • Consider using DHCP snooping on network switches to prevent rogue servers
  • Document your DHCP infrastructure thoroughly

Common problems with multiple DHCP servers include:

  • IP address conflicts from overlapping pools
  • Inconsistent lease times between servers
  • Clients receiving incorrect gateway or DNS settings
  • Performance issues from excessive broadcast traffic

Use tools like dhcpdump or Wireshark to analyze DHCP traffic when troubleshooting.