Two Dhcp Servers on Same Network: How to Detect and Resolve Overlaps

Running two DHCP servers on the same network is like having two chefs in the kitchen—except instead of duplicate recipes, you get devices fighting for IP addresses. ⚡ I’ve debugged this mess more times than I’d like to admit, and the symptoms are always the same: devices failing to connect, random IP conflicts, and logs full of "DHCP offer" collisions.

The root cause is almost always overlapping IP ranges or scopes. One server hands out 192.168.1.100–200 while the other covers 192.168.1.150–250, leaving a messy overlap where devices get stuck in limbo. Worse, some switches or firewalls might be silently dropping DHCP requests, making the problem harder to spot.

The fix isn’t always about disabling a server—sometimes it’s about smart segmentation or relay agents.

Here’s the good news: you can spot this quickly with a few commands. Run ipconfig /all on a Windows machine or arp -a on Linux to see duplicate IPs, then check your router’s DHCP logs for conflicts.

Once you isolate the overlap, the solution is straightforward—either adjust scopes, enable DHCP snooping, or use VLANs to separate traffic. No more guessing games.

For the stubborn cases, I’ve included the exact CLI commands to diagnose and resolve overlaps, plus a simple network diagram to visualize the fix. This isn’t just theory—it’s what I’ve used to save clients from hours of downtime. Let’s get to the steps that actually work.

Root Causes of DHCP Conflicts

Running two DHCP servers on the same network can cause chaos—especially when they’re unaware of each other. This happens due to a mix of misconfigurations, protocol limitations, and human oversight. Below, we break down the most common reasons why this conflict arises, along with the technical mechanics behind each.

🔄 Misconfigured scope overlaps

DHCP servers assign IP addresses from predefined scopes (ranges of IPs). If two servers have overlapping scopes, clients may receive conflicting leases from different servers, leading to:

• Duplicate IP assignments: A single device gets two leases (e.g., 192.168.1.100 from Server A and 192.168.1.100 from Server B).
• Lease corruption: The DHCP client may reject one lease, leaving it without connectivity.
• ARP/Broadcast storms: Duplicate IPs trigger ARP conflicts, flooding the network.

Why it happens: Network admins often split scopes by VLAN or subnet but forget to update both servers. For example:

Actionable fix: Use non-overlapping scopes (e.g., Server A: 192.168.1.1–100, Server B: 192.168.1.101–200) or implement DHCP relay agents to isolate traffic.

⚠️ Lack of DHCP snooping or guard

Modern switches support DHCP snooping and DHCP guard, which block rogue DHCP servers. If these features are disabled, a second server can operate undetected, causing:

• Unauthorized leases: Clients may get IPs from an unapproved server.
• Security risks: Rogue servers can distribute malicious configurations (e.g., fake DNS or default gateways).
• Network instability: Conflicting leases lead to dropped connections.

Why it happens: DHCP snooping is often disabled by default, or admins assume their network is "safe." Without it, a second server (even a misconfigured IoT device) can hijack DHCP traffic.

Actionable fix: Enable DHCP snooping on your switch and configure ip dhcp snooping trust only on ports connected to legitimate DHCP servers.

📡 DHCP relay misconfigurations

When DHCP relays (like routers or layer-3 switches) forward requests to multiple servers, clients may receive responses from both servers, creating a race condition. This is common in:

• Multi-subnet environments (e.g., a corporate WAN with distributed DHCP).
• Cloud/hybrid networks where on-prem and cloud DHCP servers coexist.
• Legacy setups where relays point to multiple upstream servers.

Why it happens: Relays don’t inherently prioritize servers—if both respond, the client picks the first reply. If Server A replies faster but Server B’s lease is "better" (e.g., longer lease time), conflicts arise.

Actionable fix: Configure ip helper-address to point to one DHCP server per subnet, or use DHCP failover with strict priority rules.

🔌 Physical or virtual redundancy without coordination

High-availability setups (like active-active DHCP clusters) can backfire if servers aren’t synchronized. Common scenarios:

• Virtual machines: Two VMs (e.g., on Hyper-V or VMware) running DHCP without shared lease databases.
• Failover clusters: Servers taking over without updating lease states.
• Cloud auto-scaling: New DHCP instances spin up without scope coordination.

Why it happens: DHCP leases are stateless by default—if Server B starts without knowing Server A’s active leases, it may reassign them. This causes:

• Lease starvation: Clients lose connectivity when leases expire.
• IP exhaustion: Both servers compete for the same pool.

Actionable fix: Use DHCP failover (Microsoft) or ISC DHCP shared networks to sync lease databases across servers.

🎯 Human error: forgetting to disable or isolate

Sometimes, the issue is simpler: a second DHCP server was enabled accidentally. Examples:

• A test server left running in production.
• A new router/firewall with DHCP enabled by default.
• A backup server that wasn’t powered down.

Why it happens: DHCP is often an "out of sight, out of mind" service. Admins may not realize a secondary server is active until clients start dropping connections.

Actionable fix: Run arp -a or show ip dhcp binding to spot duplicate IPs, then disable the redundant server.

Fixing DHCP Server Conflicts

Running two DHCP servers on the same network can cause chaos—imagine two chefs 👨‍🍳🔥 trying to season the same dish without communicating. The result? Overlapping IP assignments, device connection failures, and frustrated users.

But don’t worry—solutions exist! Below, we’ll break down fixes based on the root cause, from quick tweaks to long-term fixes.

🔧 When Both Servers Are Active (Overlap Conflict)

If both DHCP servers are live and handing out IPs, devices may get conflicting leases, leading to no internet or slow performance. Here’s how to resolve it:

🔥 Step 1: Identify the Primary Server

• 📋 Check DHCP scopes: Ensure one server’s scope doesn’t overlap with the other. For example:
  • Server 1: 192.168.1.10 – 192.168.1.100
  • Server 2: 192.168.1.101 – 192.168.1.200
  • ⚠️ Problem: If Server 2 starts at 192.168.1.1, it conflicts with Server 1’s range.
• 🔍 Use tools like Wireshark or ipconfig /all to see active leases.

🍳 Step 2: Disable One Server (Temporary Fix)

• 🛑 On Windows Server: Open Server Manager → DHCP → Right-click the server → Stop.
• 🐧 On Linux (ISC DHCP): Run sudo systemctl stop isc-dhcp-server.
• ✅ Test: Reboot a few devices to confirm connectivity.

👨‍🍳 Step 3: Configure DHCP Failover (Permanent Fix)

If both servers are needed for redundancy:

1. 🔄 Enable DHCP failover (Windows Server only):
   • Open DHCP Manager → Right-click a scope → Configure Failover.
   • Set Load Sharing (both servers share the pool) or Hot Standby (one is backup).
2. 🔄 On Linux (ISC DHCP): Use dhcpd.conf with failover peer settings.
3. ⚠️ Warning: Only do this if both servers are trusted and synchronized.

🔄 When One Server Is Rogue (Unauthorized DHCP)

A misconfigured or malicious DHCP server can hijack your network. Here’s how to evict it:

🔪 Step 1: Locate the Rogue Server

• 📡 Use arp -a (Windows) or arp -n (Linux) to find the MAC address of the rogue server.
• 🔍 Check DHCP logs (Event Viewer on Windows, /var/log/syslog on Linux).
• 🕵️‍♂️ Scan with Wireshark to capture DHCP DISCOVER/OFFER packets.

⏰ Step 2: Disable or Remove the Rogue Server

• 🛑 If it’s a physical device: Unplug it or block its MAC address in your switch.
• 🔒 If it’s a VM: Shut it down via hypervisor (VMware, Hyper-V).
• 🚫 Block at the firewall: Add a rule to drop DHCP traffic (port 67/68) from the rogue server’s IP.

💡 Prevention Tip:

• 🔐 Enable DHCP snooping on your switch to filter untrusted DHCP traffic.
• 📋 Document all authorized DHCP servers in your network inventory.

🔄 When Scopes Overlap (IP Range Conflict)

If both servers use the same IP range, devices may get duplicate IPs or none at all. Fix it like this:

📋 Step 1: Adjust DHCP Scopes

• ✏️ On Windows:
  • Open DHCP Manager → Right-click the conflicting scope → Properties.
  • Change the Range to non-overlapping (e.g., Server 1: 192.168.1.10-100, Server 2: 192.168.1.101-200).
• ✏️ On Linux:
  • Edit /etc/dhcp/dhcpd.conf and modify range statements.

🔄 Step 2: Exclude Overlapping IPs

• 🚫 Add exclusions in both servers to avoid conflicts:
  • Example: If Server 1 uses 192.168.1.1-100, exclude 192.168.1.101-200 in Server 2.

💡 Prevention Tip:

• 📊 Use a network diagram to map all DHCP scopes before deployment.
• 🔄 Automate scope monitoring with tools like PRTG or SolarWinds.

🛡️ Best Practices to Avoid Future Conflicts

Once you’ve resolved the issue, keep it from happening again with these pro tips:

• 🔐 Centralize DHCP management—use a single server for small networks or failover clusters for large ones.
• 📋 Document everything—keep a record of all DHCP scopes, exclusions, and server locations.
• 🔄 Regularly audit your network—scan for unauthorized DHCP servers every 3-6 months.
• 🛡️ Enable DHCP guard on switches to prevent rogue servers from broadcasting.
• 📢 Educate your team—ensure IT staff knows the risks of adding a second DHCP server without planning.

With these fixes, your network should run smoothly—no more IP conflicts, no more frustrated users, and no more "Why won’t my Wi-Fi work?!" calls. 🚀 Now go forth and troubleshoot like a pro!

Frequently asked questions