Campus Roaming SLE Drop After Firmware and RADIUS Changes
After a firmware upgrade on a 300-AP campus, the Roaming SLE falls from 96% to 71% in three buildings, while Time to Connect falls to 82%. About 4,000 clients are active. Marvis Actions shows DHCP failures on VLAN 20 in Building B, 802.1X failures from one RADIUS server, and 18 APs with bad-cable indications in Building C. Clients roam at -78 dBm and take about 1.8 seconds; some Apple devices fail to reconnect after roaming. The VLAN 20 DHCP scope has 254 addresses with 240 leases in use. 802.11r is enabled globally; 802.11k and 802.11v are also enabled. One RADIUS server was patched last week, and the affected buildings contain a mix of Wi-Fi 5 and Wi-Fi 6 clients.
1. How would you separate and prioritize the root causes rather than treating the Roaming SLE as one problem?
Read the worked answer
The roaming score is likely a symptom of several independent failures, so do not start by changing roaming settings. Filter the SLE classifiers by building and client type. In Building B, 240 of 254 leases in use is about 94% utilization; new associations and reconnections can fail, and a failed reconnect after roaming will be counted as a roaming problem. Treat DHCP exhaustion as the first fix: expand or rebalance the scope, shorten leases if appropriate, and check for a rogue DHCP server. In the building with the patched RADIUS server, the 802.1X failures are a separate authentication fault; compare a pre-patch and post-patch server, and consider rollback. The bad-cable APs in Building C affect backhaul and AP health, not client roaming directly. Fix DHCP and RADIUS first, then re-read the Roaming SLE before touching 802.11r.
2. What would you check about 802.11r and client behavior, given that Apple devices fail to reconnect after roaming?
Read the worked answer
Check whether the failure is a fast-transition failure or a coverage/roaming-threshold problem. Clients roaming at -78 dBm are roaming late; a sticky client can fail to reconnect even with perfect 802.11r. Confirm that 802.11r is configured consistently on the WLAN and that the mobility domain is coherent across the affected APs, and check whether the Apple failures cluster on particular APs or firmware versions. Rather than disabling 802.11r globally, test one SSID or one building with fast roaming disabled or with a different transition setting, then compare the client timeline and failure stage. Also verify that 802.11k neighbor reports are being received and that 802.11v is not steering clients in a way that conflicts with the client's own roam decision. If the clients fail before the handshake, the issue is likely scan/roam behavior, not the key exchange.
3. How would you validate the DHCP and RADIUS fixes with Marvis Minis and other Mist evidence?
Read the worked answer
Use Marvis Minis to run synthetic tests from APs on VLAN 20: a DHCP test can show whether a new lease can be obtained, and a DNS or RADIUS test can show whether the authentication path works from the same network vantage point. Run the tests before and after the scope change or RADIUS rollback, and compare APs in the affected building with APs in an unaffected building to avoid blaming the whole campus. On the wireless side, check the client timeline for a successful 802.1X exchange and a successful roam, and re-read the Roaming and Time to Connect SLE classifiers filtered to the affected building. Confirm that the DHCP pool utilization has fallen and that Marvis no longer lists the DHCP action. Do not declare success from the SLE alone; a synthetic pass plus a real client reconnect is stronger evidence.