Controller HA and Seamless Roaming Across a Routed Core
A university campus has two buildings separated by a routed core. Each building has its own /24 client subnet. There are 400 APs and 8,000 clients, including 1,500 voice handsets. Two Aruba Mobility Controllers are installed in one data center, but each AP is statically pointed to one controller; there is no cluster or VRRP. When users walk between buildings, voice calls drop for 8-12 seconds. If a controller fails, half the APs reboot and clients reconnect. The university wants sub-second failover and seamless roaming.
1. Design the controller high-availability topology. Explain how APs should terminate and what happens when one controller fails.
Read the worked answer
Put the two controllers into a cluster and configure a VRRP virtual IP for AP termination and client services. Distribute APs across both controllers rather than pinning all APs on one side. Enable AP fast failover so an AP's CAPWAP tunnel can move to the surviving controller without the AP rebooting or losing its configuration. Ensure both controllers have identical software, licenses, and sufficient capacity to absorb the full AP and client load after a failure.
With this design, a controller failure causes APs to fail over to the peer, and the VRRP address remains reachable. Clients may see a brief interruption, but the AP does not reboot and the SSID configuration persists. Test the failure by powering off one controller and measuring AP rejoin time, client reauthentication, and voice call impact. The design target should be no AP reboot and a failover short enough that voice calls either survive or recover before the user notices a multi-second outage.
2. Design roaming for voice clients crossing between the two buildings' different subnets. What controller and RF features are required?
Read the worked answer
Because the buildings use different /24 subnets, this is L3 roaming. Keep both controllers in the same mobility domain or cluster so the client's home agent can remain anchored while the client roams to a foreign controller. The client keeps its original IP address, and traffic is tunneled between controllers. Configure 802.11k neighbor reports and 802.11v BSS transition to help voice clients choose the next AP, and enable 802.11r only if the handsets support it and the key-management design is compatible.
On the RF side, align AP coverage between buildings, avoid excessive transmit power that creates a large overlap with poor SNR, and set a voice role with appropriate QoS marking and call admission control. Verify that both controllers have matching mobility domain settings and that the inter-controller path has sufficient bandwidth and low latency for tunneled client traffic. Test a call while walking the route between buildings and confirm the client keeps its IP address and the call survives.
3. What test plan would prove both failover and roaming meet the requirement?
Read the worked answer
Run separate tests for failure and roaming, then a combined test. For failover, establish 200 active clients and 20 voice calls, power off one controller, and record AP rejoin time, client reauthentication time, packet loss, and whether calls survive. For roaming, walk a voice handset between buildings while running a continuous ping and a call, recording roaming delay, packet loss, and whether the IP address changes. Repeat with a loaded network, because roaming behavior under idle conditions is not representative.
Pass criteria should include no AP reboot on controller failure, voice roaming interruption short enough to avoid call drop, and no duplicate or stale client entries. Use controller logs, client traces, and AP event logs to confirm the client moved through a planned neighbor rather than a distant AP. If a call drops, determine whether the delay came from L3 tunnel setup, 802.1X reauthentication, or RF retries before changing the design.