Cross-Building Voice Roam on Two Controllers
Two Aruba 7210 Mobility Controllers serve a 120-AP campus. The controllers are in the same mobility domain but are not clustered. APs in Building A terminate to Controller-1 and Building B to Controller-2. Each controller has 128 AP licenses. A single corporate SSID uses VLAN 110 in Building A and VLAN 120 in Building B; the buildings are separated by a Layer 3 routed core. Nurses with voice-over-Wi-Fi handsets walk between buildings and keep the same IP address, but calls drop for 20 to 40 seconds. The security team refuses to extend VLAN 110 across buildings. The underlay permits all controller-to-controller traffic. You must reduce roam disruption without redesigning the routed core or adding a new SSID for voice. The handsets support 802.11r and 802.11k.
1. Why do the voice calls drop for 20-40 seconds, and what is the first architecture change you would evaluate?
Read the worked answer
The 20-40 second drop is consistent with a Layer 3 roam, not just a slow 802.11 association. The client keeps its IP address but moves to an AP on Controller-2, where VLAN 120 is local and no client state exists for VLAN 110. The new controller must re-authenticate and the client must renew DHCP or re-establish sessions; voice suffers. A shared mobility domain by itself does not preserve the client's home VLAN.
First check whether both controllers can join one ArubaOS cluster with L3 mobility enabled, so the home controller anchors the client's VLAN 110 traffic while the client is at Building B. If clustering is not supported, the alternatives are extending VLAN 110 (blocked by security), tunneling the VLAN, or anchoring the voice SSID. Do not expect 802.11r alone to fix it; fast transition reduces authentication time but not the L3/DHCP problem.
2. How would you verify that the fix preserves the security team's VLAN separation?
Read the worked answer
Test a handset before and after the roam: it should keep the same 10.110.x address and default gateway, with no DHCP discover after handoff. On the controllers, confirm the client appears as a mobility/client entry anchored to the home controller and that traffic exits VLAN 110 there, not VLAN 120. Capture traffic at both controllers to verify the tunnel path and symmetric return. Confirm Building B still has no VLAN 110 interface and that no new route leaks VLAN 110 into Building B. Review role ACLs and firewall policy for the anchored traffic. If the client IP changes, or if traffic exits locally in VLAN 120, the design has not preserved separation.
3. What would you monitor after the change to confirm voice quality, and what result would show the change did not work?
Read the worked answer
Monitor roam time, packet loss, jitter, DHCP latency, and 802.1X reauthentication events per handset across repeated A-to-B walks. In Aruba Central or the controller client table, watch for IP changes or new DHCP leases after roaming. A working fix should show sub-150 ms roaming gaps and no reauthentication or DHCP on a normal walk. If calls still drop, or if the client gets a new address, the change is not working. Also monitor controller-to-controller tunnel health and MTU, because a fragmented or dropped tunnel will look like a coverage problem.