Home / Infrastructure Migration / How to Fix DHCP Relay Still Forwarding to the Old Server After Migration

Infrastructure Migration

How to Fix DHCP Relay Still Forwarding to the Old Server After Migration

Fix clients still getting leases from the old DHCP server after migration by checking relay targets, helper addresses, scope ownership, and stale network configuration.

Published: Nov 1, 202510 min readBy FixWikiHub Editorial Team

Abstract illustration for infrastructure migration troubleshooting guides.

Introduction

A network migration can bring the new DHCP server online while routers or switches still relay requests to the old server. Clients get the wrong lease, gateways and DNS settings remain outdated, or one subnet works while another still depends on the retired DHCP environment because helper addresses and relay configuration were not updated everywhere during the cutover.

This issue commonly occurs in enterprise environments during DHCP server consolidation, data center migrations, or when transitioning from Windows Server DHCP to a Linux-based solution like ISC-DHCP or Kea. The problem can persist for weeks or months because both old and new servers remain operational, making it difficult to detect that clients are still communicating with the wrong server.

Treat this as a lease-delivery problem instead of a generic client networking issue. Start by checking which DHCP server actually answers requests for an affected subnet, because migrations often build the new scopes and failover pairs first while relay targets on the network devices remain unchanged.

Symptoms

Clients still receive leases from the old DHCP server after migration
New network settings never appear on affected devices
One subnet or site works while another still uses the previous DHCP environment
Leases fail only after the old DHCP server is shut down
Clients receive the wrong gateway, DNS server, or PXE-related options after cutover
The issue started after moving DHCP services, scopes, relay agents, or core network hardware
DHCP lease logs show the old server IP address instead of the new one
ipconfig /all on Windows clients shows DHCP server IP pointing to the decommissioned server
Network traces (Wireshark/tcpdump) show DHCPACK responses coming from unexpected IP addresses
New VLANs work correctly but existing subnets continue using old DHCP

Common Causes

Router or switch helper addresses still point to the old DHCP server
DHCP relay configuration was updated on one VLAN or interface but not another
Scope activation, failover, or superscope ownership still leaves the old server authoritative
Relay agents or firewall rules still send DHCP traffic to the previous environment
Golden configs or network automation keep restoring the old helper target
Validation confirmed the new DHCP server had scopes but did not verify which server actually answered live requests
Network device configuration management tools reverted changes after initial update
Documentation was incomplete, missing some network segments that required helper address updates
DNS aliases or CNAME records still point to the old DHCP server hostname
Firewall rules allow DHCP traffic to both servers, creating split-brain behavior

Step-by-Step Fix

Step 1: Identify the Active DHCP Server

Capture one DHCP exchange from an affected subnet and record which server responds and which relay path forwarded the request. Use a packet capture tool on a client or configure a SPAN/mirror port:

On a Windows client: ```cmd # Start packet capture before releasing IP # Then run: ipconfig /release ipconfig /renew

# Check which server provided the lease ipconfig /all | findstr "DHCP" ```

On a Linux client: ```bash # Release and renew to see the server sudo dhclient -r eth0 sudo dhclient -v eth0

# Check active lease cat /var/lib/dhcp/dhclient.leases ```

Using tcpdump on a network device: ``bash tcpdump -i eth0 -n port 67 or port 68 -vv

The live responder determines where clients really get configuration.

Step 2: Compare Active Path with Migration Design

Compare that active DHCP path with the intended post-migration design. One stale helper address can keep an entire VLAN tied to the retired server.

Check your network device configuration for helper addresses:

Cisco IOS/IOS-XE: ``cisco show run | include helper show ip interface | include Helper

Cisco NX-OS: ``cisco show running-config interface all | include "ip helper"

Juniper JunOS: ``shell show configuration | display set | match helper show configuration forwarding-options dhcp-relay

Arista EOS: ``shell show running-config | include helper

Step 3: Review All Relay Configuration

Review helper addresses, relay agents, interface config, failover settings, and scope activation state for references to the old DHCP environment. Lease delivery depends on both server and network layers.

Check for multiple helper addresses (should point only to new server): ``cisco interface Vlan100 ip helper-address 10.1.1.10 ! Old server - should be removed ip helper-address 10.2.2.20 ! New server - correct

If using DHCP relay agents (Linux example): ```bash # Check dhcrelay configuration cat /etc/default/isc-dhcp-relay # or systemctl status dhcrelay

# Check running process ps aux | grep dhcrelay ```

Step 4: Check All Affected VLANs Separately

Check every affected VLAN, SVI, or branch interface separately if only some clients are wrong. DHCP migrations commonly fix one relay path while another still points at the previous server.

Create a spreadsheet or configuration audit: ``VLAN ID Interface Helper Address Status -------- ---------- ---------------- --------- Vlan10 10.1.10.1 10.1.1.10 NEEDS FIX Vlan20 10.1.20.1 10.2.2.20 CORRECT Vlan30 10.1.30.1 10.1.1.10 NEEDS FIX

Step 5: Update Helper Addresses

Update the authoritative relay and server configuration so requests from the affected subnet reach the intended DHCP service. Moving scopes alone does not redirect network-device helpers.

Cisco example: ``cisco conf t interface Vlan100 no ip helper-address 10.1.1.10 ip helper-address 10.2.2.20 end write memory

Juniper example: ``shell configure delete forwarding-options dhcp-relay server-group OLD-DHCP set forwarding-options dhcp-relay server-group NEW-DHCP 10.2.2.20 commit

Remove the old server from helper lists on all affected interfaces: ``cisco # Use a script or automation to update all interfaces show run | include helper > helper-audit.txt # Edit and apply corrected configuration

Step 6: Test the Fix

Renew a controlled client lease and confirm it receives the expected options from the intended server. A valid IP address does not prove the right DHCP source answered.

```cmd # Windows - clear existing lease first ipconfig /release ipconfig /renew ipconfig /all

# Verify the DHCP Server field shows the new server IP ```

Step 7: Verify Old Server Receives No Requests

Verify the old DHCP server no longer receives requests from migrated segments. Partial relay drift can stay hidden while both servers remain reachable.

On Windows Server DHCP: ``powershell Get-DhcpServerAuditLog | Select-Object -First 50 # Check for recent client requests

On Linux ISC-DHCP: ``bash tail -f /var/log/syslog | grep -i dhcp # Watch for incoming requests

Check lease database for recent entries: ``bash # On old server - should show no new leases from migrated VLANs grep "lease" /var/lib/dhcp/dhcpd.leases | tail -20

Step 8: Handle Edge Cases

Review lease timers, rogue DHCP sources, and firewall policy if behavior still looks inconsistent. The target can be fixed while old leases or duplicate responders still interfere.

Check for rogue DHCP servers: ```bash # Use dhcploc tool on Windows dhcploc 10.1.10.50

# Or nmap DHCP discovery nmap --script broadcast-dhcp-discover -e eth0 ```

Clear stale ARP entries: ``cmd # Windows netsh interface ip delete arpcache arp -d *

Verification

Confirm the fix by verifying:

1.Client renewal test: Multiple clients across different VLANs successfully renew from the new DHCP server
2.Packet capture verification: No DHCP traffic reaches the old server from migrated network segments
3.Lease database check: New lease entries only appear in the new DHCP server's database
4.Configuration audit: All helper addresses point exclusively to the new server
5.Documentation update: Network diagrams and runbooks reflect the new DHCP infrastructure

Verification commands: ```bash # Check from multiple clients ipconfig /all | findstr "DHCP Server"

# Monitor new server leases tail -f /var/log/dhcpd.log

# Verify no broadcast to old server tcpdump -i eth0 host <old-dhcp-server-ip> and udp port 67 ```

Prevention

To prevent this issue in future migrations:

1.Create a complete helper address inventory before starting the migration. Document every VLAN, SVI, and routed interface with DHCP relay configured.
2.Use configuration management tools to update helper addresses consistently across the network:
3.```yaml
4.# Ansible example for Cisco helper address update
5.- name: Update DHCP helper addresses
6.cisco.ios.ios_config:
7.lines:
8.- no ip helper-address {{ old_dhcp_server }}
9.- ip helper-address {{ new_dhcp_server }}
10.parents: interface {{ item }}
11.loop: "{{ vlan_interfaces }}"
12.`
13.Test the actual relay path as part of migration validation, not just the server-side scope configuration. Use packet captures on a test client in each VLAN.
14.Implement monitoring that alerts when DHCP leases come from unexpected servers:
15.```yaml
16.# Example alert logic
17.- alert: DHCPLeaseFromOldServer
18.expr: dhcp_lease_server == "10.1.1.10" # old server
19.for: 5m
20.annotations:
21.summary: "Client received DHCP lease from old server"
22.`
23.Use a phased cutover approach: Migrate one VLAN at a time, verify complete relay path operation, then proceed to the next segment.
24.Document ownership clearly: Specify which team owns helper address configuration (typically network team) versus DHCP server configuration (typically server/AD team).
25.Schedule post-cutover validation: Run automated checks for 30 days after migration to catch any delayed configuration drift from automation or golden configs.
26.Implement change control that requires verification of both server and relay configuration before marking the migration complete.

[WordPress troubleshooting: Fix CloudFormation Permission Denied - C](fix-cloudformation-permission-denied)
[Technical troubleshooting: Fix Cloud Migration Data Transfer Incomplete Issue](cloud-migration-data-transfer-incomplete)
[Fix Database Migration Schema Lock Timeout in Infrastructure Migration](database-migration-schema-lock-timeout)
[Fix DNS Cutover Propagation Delay Issue in Infrastructure Migration](dns-cutover-propagation-delay)
[How to Fix Ansible Automation Controller Still Running Jobs Against the Old Execution Environment After Migration](fix-ansible-automation-controller-still-running-jobs-against-old-execution-environment-after-migration)

Was this guide helpful?

Related search paths

People also search for

If the symptom is close but not identical, these search paths usually surface the right neighboring fixes faster than scrolling the full archive.

DHCP Relay Still Forwarding to the Old Server DHCP Relay Still Forwarding to the Old Server Infrastructure Migration DHCP Relay Still Forwarding to the Old Server troubleshooting DHCP Relay Still Forwarding to the Old Server fix Fix clients still getting leases from the old DHCP server after migration by checking relay targets, helper addresses, scope ownership, and stale network configuration Infrastructure Migration Fix clients still getting leases from the old DHCP server after migration by checking relay targets, helper addresses, scope ownership, and stale network configuration

Explore Related Topics

Browse Guides from Other Categories

Discover troubleshooting guides from related categories to expand your knowledge.

FAQ

Infrastructure Migration Troubleshooting FAQs

Common questions about troubleshooting and preventing similar issues

How do I know if this infrastructure-migration troubleshooting guide applies to my situation?

This guide is designed for infrastructure-migration issues. If you're experiencing similar symptoms described in the article, follow the step-by-step instructions. Start with the most common causes and work through the diagnostic process.

Is it safe to follow these infrastructure-migration troubleshooting steps?

Yes, all steps are designed to be safe and non-destructive. We recommend creating backups before making significant changes and testing each step before proceeding to the next.

How long does it typically take to resolve this type of infrastructure-migration issue?

Most infrastructure-migration issues can be resolved within 30 minutes to 2 hours, depending on the complexity and root cause. Follow the troubleshooting flow to identify and fix the problem efficiently.

How can I prevent this infrastructure-migration issue from happening again?

Regular maintenance, monitoring, and following best practices for infrastructure-migration configuration can help prevent recurrence. Consider implementing automated checks and alerts for early detection.

Written by

FixWikiHub Editorial Team

Our editorial team consists of experienced DevOps engineers, systems administrators, and cloud architects with hands-on experience in production environments across AWS, Azure, GCP, and on-premises infrastructure.

Every guide undergoes technical review for accuracy and is updated when software versions, commands, or best practices change.

Last updated: Nov 1, 2025

About our team

Important Notice

Disclaimer & Safety Guidelines

The troubleshooting steps in this guide are provided for educational and informational purposes. Before applying any changes to production systems:

Test in a staging environment first — Always verify commands and configurations in a non-production environment before deploying to live systems.
Create backups — Ensure you have current backups of databases, configurations, and critical files before making changes.
Understand the impact — Review how each step may affect your specific environment, dependencies, and users.
Consult official documentation — This guide supplements, but does not replace, official vendor documentation and best practices.

FixWikiHub is not responsible for any damages arising from the use of this content. See our Terms of Use for more information.

Resources

Official Documentation & Further Reading

For authoritative information, consult the official documentation for the technologies discussed in this guide. Our troubleshooting content supplements, but does not replace, vendor documentation.

AWS Documentation — Official Amazon Web Services guides and API references
Kubernetes Documentation — Official Kubernetes documentation
Nginx Documentation — Official Nginx web server documentation
Apache Documentation — Official Apache HTTP Server documentation
Docker Documentation — Official Docker container documentation