Intermittent Roaming Failures After Controller Firmware Upgrade
A campus with 600 Aruba APs (mixed 500-series and 600-series) is managed by Aruba Central, with two Mobility Controllers in an L2 cluster for a legacy building and Central-managed gateways elsewhere. After a controller firmware upgrade, users in the legacy building report that clients roaming between floors occasionally lose connectivity for 10-30 seconds, and some clients get stuck on the old AP with poor signal. The building uses a single large VLAN for all floors (flat L2). 802.11k/v is enabled; 802.11r is enabled only on the 600-series APs. The controllers show no crashes, but show ap debug client-table shows clients associated to a distant AP with RSSI around -78 dBm.
1. Identify the most likely causes of the roaming failures given the mixed AP fleet and flat L2 design, and explain the role of 802.11r mismatch.
Read the worked answer
Most likely causes:
802.11r mismatch across the fleet: 802.11r (FT) is enabled only on 600-series APs. A client that negotiates FT on a 600-series AP and then roams to a 500-series AP (no FT) can fail the fast transition and either drop or fall back poorly, producing the 10-30 s outage. Mixed FT support within one ESS is a classic roaming failure.
Flat L2 / large broadcast domain: A single VLAN across floors means the client's PMK/OKC state and ARP/DHCP are shared, but broadcast/multicast and large client tables slow roaming decisions; clients may stay associated to a distant AP (-78 dBm) because there is no L3 boundary forcing a re-evaluation.
Sticky client behavior: With 802.11k/v enabled but inconsistent 802.11r, the client may ignore neighbor reports or fail the transition, staying on the far AP.
Judgement: The upgrade likely changed default FT/OKC behavior or PMK caching on one controller, exposing the pre-existing 802.11r inconsistency. The flat L2 amplifies the symptom but is not the root cause.
2. What configuration changes and verification steps would you apply to stabilize roaming without redesigning the L2 topology?
Read the worked answer
Configuration changes:
- Make 802.11r consistent across the entire ESS: either enable FT on all APs (500 and 600 series, if firmware supports it) or disable it fleet-wide. Mixed support is the core defect.
- Ensure OKC/PMK caching is enabled consistently on both controllers and gateways.
- Keep 802.11k/v enabled; verify neighbor reports are being generated (
show ap arm rf-summary/ client debug). - Tune ARM so distant APs do not hold clients: raise minimum RSSI / enable client-match so clients at -78 dBm are steered to a closer AP.
- Optionally enable band steering and client match to reduce sticky behavior.
Verification:
show ap debug client-table- confirm clients associate to nearest AP (RSSI better than ~-70 dBm).- Roam test between a 500-series and 600-series AP; capture client logs to confirm FT succeeds or falls back cleanly.
show ap debug mgmt-frame/ controller logs for FT failures.- Monitor roam times; target <200 ms for voice-capable clients.
Note: Do not change the flat L2 design in this window; fix the FT inconsistency first, then evaluate L3 segmentation as a later project.