Duplicate SSID, Two Subnets: Which Virtual AP Actually Wins
A 48-AP campus runs ArubaOS 8 with two controllers in one cluster. HQ-CORP is the only corporate SSID; it uses 802.1X against RADIUS, which returns VLAN 110. Last month a newly acquired team moved into the second floor, and a contractor added a second virtual AP also named HQ-CORP, mapped to VLAN 120 with an open AAA profile, and applied it to a building-wide virtual-ap group. Users now report two symptoms. About 30 people on floor 2 receive 10.120.x addresses and cannot reach file servers on 10.110.x, even though they are on HQ-CORP. Separately, a handful of floor-2 clients associate but never obtain any address at all. Nothing else changed in the configuration or the network.
1. Explain the mechanism that produces two different subnets for one SSID, and describe how you would confirm which virtual AP a given client landed on.
Read the worked answer
The SSID is only a name. What decides the client's VLAN is the virtual AP instantiated on the AP the client joins. Two VAPs share the name HQ-CORP, and which one exists on a given AP depends on the AP group's virtual-ap group and, where both are present, on VAP order, because Aruba builds only one instance per SSID per AP and first match wins.
Consequences:
- Clients on floor 1 take the VLAN 110 VAP; clients that associate to a floor-2 AP take the VLAN 120 VAP. The SSID is identical, so clients cross that boundary without any visible signal, and existing sessions break at the subnet change.
- Nothing in the client UI explains the behaviour, so it looks random to the help desk.
Confirm by mapping client to AP to VAP:
show user-tableandshow ap associationshow the VLAN and role per client.show ap databasegives each AP's group.- Compare
show ap virtual-apoutput for each group and the VAP ordering inshow ap-group <name>.
If the same client MAC shows a different VLAN depending on the AP it joined, the mechanism is proven.
2. Why do some floor-2 clients associate successfully but never receive an IP address? What would you check first, and why not RF?
Read the worked answer
Association succeeding but DHCP failing means the wireless layer did its job and the address path is broken. With the VAP bridged, the client's DHCP discover leaves the AP uplink tagged for VLAN 120; if VLAN 120 is not allowed on the access switch trunk, or is pruned upstream, the discover never reaches a server.
Candidates in order of likelihood:
- VLAN 120 missing or pruned on the floor-2 switch trunk or the AP's port.
- DHCP scope exhausted, or the scope is not on the subnet those APs are bridged into.
- No DHCP relay/helper on the SVI, if the DHCP server sits on another subnet.
Discriminate, do not guess:
show user-tablefor those clients: associated, still in the initial role, no IP, and never aging out is the signature.- On the switch, check the trunk and allowed VLAN list for the AP port.
- Capture on the AP uplink and look for DHCP frames and whether any offer comes back.
RF is the wrong first move because the client already associated; weak signal would show as retries and deauth, not as a clean association with a silent DHCP failure.
3. Give a remediation sequence that fixes both symptoms without stranding the 30 users currently on VLAN 120, and state what you verify after each step.
Read the worked answer
Order matters, because deleting the duplicate VAP instantly disconnects the 30 users who are on it.
- Fix the address path first: add VLAN 120 to every floor-2 AP uplink, then verify a test client gets an address. This alone clears the no-DHCP group.
- Build a distinct SSID (for example CORP-ACQUIRED) as a new VAP on the same AP group with the same AAA profile, VLAN 120, and a role/firewall policy that permits only the specific access that team needs toward 10.110.x.
- Announce, then migrate the team to the new SSID.
- Only after migration, remove HQ-CORP from the second VAP or delete that VAP entirely, and check VAP ordering so the remaining corporate VAP is unambiguous.
Verification after each step: correct VLAN and role per client, successful DHCP, reachability from client to file server in both directions (stateful policy permits return traffic), 802.1X authentication events in RADIUS, and a count of clients in 10.120.x that falls to zero on the old SSID.
The design lesson: one SSID maps to one VAP per AP group, and per-group differences must be expressed as role or server-derived VLAN, not as two identically named VAPs.