Roaming Across Floors with 802.1X and Different VLANs

There are two separate failures happening at the same time. The authentication failure is shown by the full EAP exchange after every roam. In a working fast-roam design, the client and controller should use PMK caching, OKC, or 802.11r FT so the client does not repeat the complete EAP-TLS exchange. A full EAP-TLS exchange can easily take several seconds, especially if the RADIUS path is slow, and that alone explains part of the freeze. The addressing failure is shown by the iPad keeping its floor-2 IP address, failing to ping the floor-3 gateway, and failing DHCP renewal. The iPad still has a valid lease from VLAN 120. When it roams to a floor-3 AP, if the controller does not anchor or tunnel the client's traffic back to VLAN 120, the client's default gateway is the VLAN 120 gateway. But VLAN 120 is not trunked to floor 3, so the client's ARP for its gateway goes nowhere. The core router routes between VLANs, but routing only works if the packet reaches the router; the client's own subnet is not locally present on floor 3. A DHCP renew may also fail because the DHCP server is reachable only through the VLAN 120 gateway. The mobility group by itself does not solve this; it allows controller coordination, but without home-agent anchoring or L2 extension, the client's data path is local to the foreign VLAN. Extending VLAN 120 to floor 3 would turn this into L2 roaming, but security has ruled that out.

L2 extension means trunking VLAN 120 to floor 3 so the client keeps its subnet and gateway everywhere. It is operationally simple and preserves sessions, but it creates a large Layer 2 domain across floors, increases broadcast and failure-domain risk, and violates the security team's constraint. It also does not fix the full EAP exchange by itself. L3 roaming with re-addressing means the client gets a new VLAN 130 address after roaming, with DHCP triggered by the roam. This is clean from a segmentation standpoint, but it breaks existing sessions and is poor for a live video call. It also requires the client to detect the link change and renew quickly; many clients do not, which is exactly the observed DHCP timeout. Home-agent anchoring is the best fit. The client's traffic is tunneled from the foreign controller or AP to the home controller on floor 2, preserving the VLAN 120 address and default gateway without extending VLAN 120 to floor 3. The foreign AP provides radio access, but the client's data path exits on the home subnet. This satisfies security because VLAN 120 remains confined to floor 2, and it satisfies the video requirement because the IP address does not change mid-call. The remaining issue is fast authentication. The design should also enable PMK caching and OKC, and 802.11r FT only if the iPad fleet and RADIUS chain support it reliably. 802.11k neighbor reports and 802.11v BSS transition help the client choose the next AP, but they do not replace anchoring.

First, enable home-agent anchoring for the 802.1X WLAN in the mobility group, and designate the floor-2 controller or anchor as the home agent for clients that begin on VLAN 120. Verify that the mobility tunnel is up and that the foreign controller forwards client traffic to the home agent. Second, enable PMK caching and OKC on the WLAN; if the client fleet supports it, enable 802.11r FT over the DS and test both FT-enabled and non-FT clients. Third, enable 802.11k and 802.11v to improve neighbor reporting and transition decisions, but do not make them mandatory. Fourth, confirm DHCP helper or relay configuration on both VLANs and ensure the DHCP scope for VLAN 120 has enough leases. Fifth, set the same SSID and security policy on both floors, and verify that the client does not cache a stale gateway ARP entry indefinitely. Validation should include a controlled roam test with an iPad on a video call: capture packets on the client, home agent, and foreign controller; confirm the client keeps its IP, the tunnel carries traffic, and the EAP exchange is abbreviated. Repeat the test in both directions and at least 20 times. Check controller logs for fast-roam or PMK-cache hits, and verify that DHCP renewal succeeds after roaming. Finally, test failure cases: home agent down, tunnel down, and RADIUS slow. The design should fail gracefully with a new DHCP address rather than a 15-second black hole.