Roaming Failures After L3 Redesign
A campus with two Mobility Controllers (MC-A in Building 1, MC-B in Building 2) is connected by a routed core. Originally both controllers sat in the same VLAN and clients roamed freely. A redesign placed each controller in its own subnet: MC-A at 10.10.10.10/24 and MC-B at 10.20.20.10/24, with an OSPF-routed core between them. After the change, clients walking between buildings drop their sessions and re-authenticate, and voice calls fail during the walk. WLANs are bridged (local) on each controller. The customer insists on keeping the two subnets and will not collapse the L3 boundary. There are roughly 1,800 clients, 400 of which are voice handsets.
1. Diagnose why roaming broke and determine what architectural change restores seamless roaming without collapsing the L3 boundary.
Read the worked answer
The symptoms (re-auth on every building change, dropped voice) confirm the client is getting a new IP subnet on the second controller, so this is an L3 roam, not L2. With WLANs bridged locally to each controller's uplink, the client's anchor/gateway follows the controller it is on, so the DHCP lease cannot be preserved.
Two viable paths that keep the L3 boundary:
- Tunnel/overlay mobility - put the two controllers in a mobility domain and configure the WLAN for tunnel mode (or use an overlay/gateway-cluster model) so client traffic is anchored to a single home controller and the client keeps its IP across the L3 core.
- Centralized anchor - designate MC-A as the anchor for the voice and data WLANs and have MC-B tunnel to it, again preserving the subnet.
Because ~400 clients are voice, the tunnel path must be validated for latency/jitter and the mobility tunnel heartbeat must ride a resilient path. Simply enabling a mobility domain with bridged WLANs is insufficient - the WLAN forwarding mode is the deciding factor.
2. The customer reports that after enabling a mobility domain, some clients still re-auth when moving from Building 2 to Building 1 but not the reverse. What would you check?
Read the worked answer
Asymmetric behavior points to a configuration mismatch between the two controllers rather than the core:
- Mobility domain membership: confirm both controllers list each other and the domain is up (heartbeat/peers).
- WLAN forwarding mode consistency: if the WLAN is tunneled on one controller and bridged on the other, roaming only works in one direction.
- VLAN/interface mapping: the home VLAN must exist and be reachable on the anchor; a missing VLAN on MC-A would break the B→A direction.
- Mobility role / anchor assignment: verify which controller is the anchor and that the standby/anchor config is symmetric.
- Version and license parity between controllers.
Start with the mobility domain peer status and the per-WLAN forwarding mode on both sides; the one-directional failure is the strongest clue that the two controllers are not configured identically.