Branch Office Guest DHCP Failure After an Overnight Switch Swap
A 14-AP branch office uses three SSIDs: CORP on VLAN 10, GUEST on VLAN 20, and AP management on VLAN 99. APs receive addresses from a DHCP scope on VLAN 99. After a failed access switch was replaced overnight, users can associate to GUEST but receive no IP address; CORP still works. The new switch's port to the AP is configured as an access port on VLAN 10. The NOC also cannot ping any AP management address, although the APs are passing client traffic on CORP. The DHCP server is a central Windows server reached through the core, and the branch router has no helper address on VLAN 20. The store manager wants a fix before the morning shift.
1. Explain the required AP switch port configuration and why both GUEST DHCP and AP management failed.
Read the worked answer
An enterprise AP carrying multiple SSIDs uses a trunk: one untagged/native VLAN for AP management and tagged VLANs for client SSIDs. The replacement port is an access port on VLAN 10, so it forwards only untagged VLAN 10 frames. The AP's management frames, which are untagged, land in VLAN 10 instead of VLAN 99, so the AP may keep an old address but cannot be reached at a VLAN 99 management address, and its DHCP request goes to the wrong scope. Tagged GUEST frames on VLAN 20 are dropped at the access port, so GUEST clients associate at Layer 2 but their DHCP Discover never reaches a server.
Fix the port: configure it as a trunk, allow VLANs 10, 20, and 99, and set the native VLAN to 99 (or whatever VLAN the AP expects untagged). Do not leave native VLAN 10, since that invites VLAN hopping and misplaces management traffic. Separately, add an IP helper address on the VLAN 20 SVI pointing to the central DHCP server; the missing helper would block GUEST DHCP even after the trunk is corrected.
2. What verification steps confirm the fix without disrupting CORP users, and what else would you check on the new switch?
Read the worked answer
Verify in layers. First check the trunk: show interfaces trunk, confirm allowed and active VLANs 10, 20, 99, and confirm the native VLAN is 99 with no native VLAN mismatch reported. Confirm the AP receives a VLAN 99 address and responds to ping from the NOC. Second, confirm relay: check the VLAN 20 SVI has the correct helper address and that the DHCP scope has free leases. Third, test a GUEST client and confirm it receives an address in the VLAN 20 range with the correct gateway and DNS; test a CORP client to confirm no regression. Run a packet capture on the AP port if GUEST still fails, looking for DHCP Discover and Offer.
Also check spanning tree on the new switch, port security or MAC limits that could block AP MACs, uplink trunk configuration, and whether the replacement switch has the same VLAN database and management VLAN as the old one. Make changes in a maintenance window if possible, and keep CORP on its existing path until GUEST is confirmed.