I85PREP
⌘ K
HCIA-WLAN study materials
HCIA-WLAN study resources

HQ Rollout: APs Get IP Addresses but Never Join the AC

HCIA-WLAN · Put your knowledge to work in context.

All case studies

HQ Rollout: APs Get IP Addresses but Never Join the AC

Harbor Logistics HQ has an AC6605 in the core with Vlanif 100 at 10.10.100.10/24. Access points sit on VLAN 10, subnet 10.10.10.0/24, whose gateway is the core switch at 10.10.10.1. The core switch is also the DHCP server for the AP subnet. APs are cabled to access switches on floors 1–3 and their uplink ports are configured as access ports in VLAN 10. After power-on, the APs obtain addresses in 10.10.10.0/24 (verified from the DHCP pool), and a test PC in VLAN 10 can ping 10.10.100.10, but display ap all on the AC lists every AP in fault state and no VAPs come up. The integrator says "routing works, so it must be an AC bug". Separately, a guest SSID is planned on VLAN 200 (10.10.200.0/24) with its gateway and DHCP on the firewall, and the customer wants guests to break out locally at each floor switch rather than traverse the core.

1. Explain why the APs cannot find the AC despite IP reachability, and give the two configuration changes that fix it, including the exact DHCP option syntax.

Read the worked answer

Reachability is not discovery. An AP with no pre-configured AC address finds the AC by DHCP option 43, by DNS resolving the AC's hostname, or by broadcast on the local subnet. Broadcast does not cross the L3 boundary between VLAN 10 and VLAN 100, so with no option 43 and no DNS, the AP has no way to learn 10.10.100.10 - it simply retries and stays in fault.

Fix 1 - tell the APs where the AC is (core switch DHCP pool):

ip pool ap
 network 10.10.10.0 mask 255.255.255.0
 gateway-list 10.10.10.1
 option 43 sub-option 2 ip-address 10.10.100.10

The sub-option 2 ip-address form is Huawei's readable syntax; the equivalent hex payload for a 4-byte address is 02 04 0A 0A 64 0A (sub-option 2, length 4, 10.10.100.10). Only one format is needed, not both.

Fix 2 - give the AC a stable, routable CAPWAP source:

wlan
 capwap source interface Vlanif100

Without this, the AC may source CAPWAP from a different interface or the wrong VLAN, so even a correctly addressed AP fails to establish the tunnel. Confirm the APs can reach that address, and that any firewall between VLANs permits CAPWAP (UDP 5246/5247).

Verification: display ap all shows the APs moving to normal, and display ap online-fail-record all stops accumulating new entries. Reboot one AP to prove the DHCP path is really working, not just cached state.

2. The guest SSID must use local forwarding so guest traffic exits at each floor switch. Explain what must exist on the AP uplink ports, on the AC, and in the VAP profile, and why tunnel forwarding would behave differently.

Read the worked answer

Forwarding mode changes where the service VLAN must live.

Tunnel forwarding (the default): the AP encapsulates guest frames in CAPWAP and sends them to the AC; the AC needs Vlanif 200 and the guest gateway, and the floor switches never see VLAN 200. This is what the customer does not want - all guest traffic would hairpin through the core AC.

Local forwarding: the AP bridges guest traffic onto its wired uplink, so:

  • On the AP uplink switch ports: VLAN 200 must be allowed on the trunk toward the AP (or the port must carry the service VLAN the AP tags), and VLAN 200 must exist on that switch with an L3 gateway or a DHCP relay toward the firewall. If the port is an access port in VLAN 10 only, guest frames are dropped.
  • On the AC: the VAP profile must be set to local forwarding, and the AC must still know about the service VLAN for management and for the CAPWAP control path. The AC does not need Vlanif 200 for data if it is not the gateway.
  • On the VAP/service VLAN mapping: the guest VAP must be bound to VLAN 200 and to the correct AP group; otherwise the AP tags guest traffic with the management VLAN.

Guest DHCP: with local forwarding, the DHCP discover from a guest appears on the floor switch in VLAN 200, so the relay or server must be reachable from there - not only from the core. If the firewall is the DHCP server, configure a relay (or dhcp relay/server group) on the floor switch's Vlanif 200.

Confirm with a capture on the AP uplink: guest frames should appear tagged VLAN 200 at the floor switch, not inside CAPWAP to the core.

3. After both fixes, some guests still receive 169.254.x.x addresses while others work. Describe a step-by-step isolation of the remaining fault.

Read the worked answer

169.254 means the client got no DHCP reply - so the fault is in the L2/L3 path from the AP to the DHCP server, and the fact that some guests work points at a partial path, not a global outage.

Isolation order:

  1. Which APs? Check whether failures cluster on one floor/one AP. A single-AP pattern suggests the uplink trunk is missing VLAN 200 on that switch, or the AP is still in tunnel mode for that VAP.
  2. Which clients? If failures follow specific client models, suspect security/profile mismatch rather than DHCP; if random, suspect DHCP scope exhaustion or relay.
  3. Check the relay/server path: on the floor switch, verify Vlanif 200 exists, is up, has an address, and has a relay configured to the firewall. display ip pool / DHCP server logs show whether requests arrive.
  4. Scope exhaustion: 10.10.200.0/24 with a short lease and a busy guest area can run out; check used vs total addresses and lease time.
  5. L2 path: confirm VLAN 200 is permitted on every trunk between AP and the DHCP server's subnet, and that no switch has it pruned by a VLAN filter.
  6. Broadcast/relay duplication: if both the core and the firewall serve 10.10.200.0/24, clients may get offers from the wrong server or conflicting gateways; ensure exactly one authoritative DHCP server per subnet.

Resolution criterion: a guest on each floor obtains an address in 10.10.200.0/24, reaches the internet, and display station all on the AC shows the station with the expected service VLAN and no repeated deauth.