DHCP Address Assignment Fails Across VLANs, Switches, and Wireless Access Points — Relay Agent and Snooping Misconfiguration
DHCP address assignment fails for clients connected via managed switches, wireless access points, or across VLAN boundaries, causing clients to fall back to APIPA (169.254.x.x) addresses. The root cause is typically missing or misconfigured DHCP relay agent (ip helper-address) on Layer 3 switch SVIs, DHCP snooping blocking relay packets on untrusted ports, or VLANs missing from trunk links. Resolution requires verifying relay configuration on inter-VLAN routing interfaces, confirming DHCP snooping trusted port settings, and ensuring scope availability on the DHCP server.
Indicators
- Clients on one or more VLANs fail to obtain an IP address and fall back to APIPA (169.254.x.x) addresses
- Wireless clients associated to WAPs cannot obtain DHCP leases while wired clients on the same VLAN may also be affected
- DHCP server shows no DISCOVER or REQUEST packets arriving from affected subnets/VLANs
- Network devices log errors related to BOOTP/DHCP relay failure or missing helper-address configuration
- Intermittent DHCP failures affecting only specific VLANs or switch ports, while other segments work normally
Likely causes
- Missing or incorrect DHCP relay agent (ip helper-address) configuration on the Layer 3 switch virtual interface (SVI) or router subinterface for the affected VLAN
- DHCP server scope exhaustion — no available addresses remain in the pool for the affected subnet
- VLAN misconfiguration on switch trunk or access ports preventing DHCP broadcast traffic from reaching the relay agent
- ACL or firewall rules blocking UDP port 67 (server) or 68 (client) between VLANs or toward the DHCP server
- WAP VLAN tagging misconfiguration causing client traffic to be placed on the wrong VLAN or untagged VLAN
- DHCP snooping enabled without correct trusted port configuration, causing relay agent packets to be dropped
- Spanning tree topology change leaving ports in a blocking state, isolating DHCP traffic paths
- Rogue DHCP server on the network issuing incorrect or conflicting leases
Diagnostic steps
-
On an affected client, check the assigned IP address to confirm APIPA or no-address state, then attempt a manual DHCP renewal: ipconfig /all && ipconfig /release && ipconfig /renewConfirms DHCP failure is active and not a stale cached state; establishes the scope of the problem (single client vs. all clients on VLAN)
-
On the DHCP server, inspect available scopes, check for scope exhaustion, and review the lease table for the affected subnet using PowerShell: Get-DhcpServerv4Scope | Select-Object ScopeId, Name, State, StartRange, EndRange, FreeAddresses | Format-Table -AutoSizeDetermines whether the problem is DHCP server-side (scope full, scope inactive, no traffic arriving) or network-side (traffic not reaching the server)
-
On the Layer 3 switch or router, inspect the SVI or subinterface for the affected VLAN and verify DHCP relay configuration: show running-config interface vlan <VLAN_ID>Identifies missing or incorrect DHCP relay agent (ip helper-address) configuration, which is the most common cause of cross-VLAN DHCP failure
-
On the switch, verify DHCP snooping configuration and trusted port status: show ip dhcp snooping && show ip dhcp snooping bindingDHCP snooping with untrusted uplinks silently drops relay agent packets, causing DHCP failure even when relay is correctly configured
-
Check trunk port configuration between switches and WAP uplinks: show interfaces trunkA VLAN missing from a trunk allowlist will silently drop all client traffic including DHCP broadcasts, making it appear as a DHCP server issue
-
Perform a packet capture on the DHCP server's network interface filtered for UDP port 67: tcpdump -i <interface> -n udp port 67 or udp port 68Definitively distinguishes between a network delivery problem (no packets arrive) and a DHCP server configuration problem (packets arrive but are not answered correctly)
Resolution path
- 1. If DHCP relay (ip helper-address) is missing from the affected VLAN SVI: configure interface vlan <VLAN_ID>, then add ip helper-address <DHCP_SERVER_IP>. Save configuration with write memory. Repeat for each affected VLAN.
- 2. If DHCP snooping is dropping relay packets: identify the uplink/trunk port facing the DHCP server and mark it trusted — interface <uplink_port>, then ip dhcp snooping trust. Save configuration.
- 3. If a scope is exhausted: on Windows DHCP server, either reduce lease duration (shorten 8-day default to 4–8 hours for high-density environments), expand the scope address range, or audit exclusions. Use Get-DhcpServerv4Lease -ScopeId <scope_id> to identify stale leases and remove them with Remove-DhcpServerv4Lease.
- 4. If the VLAN is missing from a trunk: on the switch, add the VLAN — interface <trunk_port>, then switchport trunk allowed vlan add <VLAN_ID>. Confirm with show interfaces trunk.
- 5. If a WAP is assigning clients to the wrong VLAN: verify the SSID-to-VLAN mapping in the WAP or wireless controller configuration and correct the VLAN tag/ID assigned to the affected SSID.
- 6. If a rogue DHCP server is identified via lease conflicts: locate the source using show ip dhcp snooping binding or MAC address table lookup, isolate the port (shutdown on the offending switchport), and remove the unauthorized device.
Prevention
- Document and template-enforce DHCP relay (ip helper-address) configuration for every VLAN SVI as part of switch provisioning standards — include in change management checklists so new VLANs are never deployed without a relay or local scope
- Enable DHCP snooping on all access VLANs and explicitly define trusted ports (uplinks, inter-switch trunks) during initial switch configuration to prevent rogue DHCP servers from issuing leases
- Monitor DHCP scope utilization and alert when free address count drops below 20% — use Windows DHCP server built-in alerts or monitoring tool (PRTG, SolarWinds, Zabbix) polling free lease counts per scope
- Standardise WAP VLAN and SSID mapping through a wireless controller template to prevent per-AP misconfiguration that assigns clients to the wrong VLAN
- Conduct periodic audits of DHCP lease tables to identify and remove stale reservations and expired leases that consume scope space without serving active clients
- Implement network access control (802.1X or NAC) to prevent unauthorized devices from connecting to switch ports, reducing the risk of rogue DHCP servers being introduced
Tools
- ipconfig (Windows client — release/renew DHCP lease and inspect assigned address)
- Get-DhcpServerv4Scope / Get-DhcpServerv4Lease (PowerShell — inspect Windows DHCP server scopes and active leases)
- show running-config / show interfaces trunk / show ip dhcp snooping (Cisco IOS — verify switch VLAN and relay configuration)
- tcpdump / Wireshark (packet capture — verify DHCP DORA exchange at server or relay)
- ping / traceroute (connectivity verification between relay agent and DHCP server)
- show mac address-table (locate rogue DHCP server or misconfigured device by MAC)