Four-Second Voice Gaps When Handsets Cross Controllers
A distribution centre has 300 APs on two Mobility Controllers in one cluster, all on one large VLAN, using WPA2-Enterprise with PEAP-MSCHAPv2. Picker handsets report four to six second audio gaps when users walk between aisles served by different controllers. The gap is around 600 ms when they move between APs on the same controller. Captures show a full EAP exchange, including a new TLS handshake, every time the longer gap occurs, and the handset keeps its IP address throughout. 802.11r is not configured. OKC is enabled on both controllers. The handset model is known to support PMK caching but not fast BSS transition.
1. Explain what the capture proves, and why the same-controller roam behaves differently from the cross-controller roam.
Read the worked answer
The capture is the key evidence: a full EAP exchange with a new TLS handshake means the PMK was not reused, so the client performed a fresh 802.1X authentication, not a cached-key roam.
Why the two cases differ:
- Within one controller, the PMKSA cache is local to the authenticator and the data path is short. Even a full EAP round trip lands around 600 ms, which matches the observation.
- Across controllers, the client's data path is anchored at the home agent while the new AP is served by the foreign controller. If the client does not offer a PMKID the target AP can use, or the key is not available there, the client runs a complete 802.1X again. Four to six seconds is longer than a normal EAP exchange, so also look for EAP retransmissions or RADIUS timeouts on the second controller.
- The client keeps its IP, so this is an L2 roam and not a DHCP or subnet-change problem; that rules out VLAN mismatch as the cause.
Checks: client stats and roam timeline on both controllers, RADIUS server logs counting authentications per MAC, and whether the handset actually sends a PMKID at association. If the RADIUS log shows two authentications per roam, the cache is not being used end to end.
2. What would you change, in what order, and what are the risks of each change?
Read the worked answer
Cheapest and least risky first:
- Prove the two controllers are in the same mobility domain with identical VAP and AAA profiles and the same RADIUS server group. A profile or server-group difference silently forces re-authentication, and this is a common cause.
- Verify OKC end to end on the handset: the vendor-side PMK caching setting must be enabled, and the client must offer a PMKID. If the handset does not do it, no controller setting will fix it.
- Check RADIUS latency and retransmits. A four to six second gap looks like an EAP timeout rather than a handshake delay; fixing the RADIUS path may be the entire fix.
- Consider 802.11r. It would reduce the handshake to tens of milliseconds, but these handsets do not support FT. Enabling it as FT-only would break them. If you enable it, keep normal WPA2-Enterprise authentication available for non-FT clients and test on the actual fleet before rolling out.
- Reduce dependence on roaming: ClientMatch and adequate AP density shrink the overlap zone where roams happen.
The durable fix for voice is a handset that supports 11r. That is a procurement decision, and it is the only option that reliably lands under 150 ms.
3. How would you prove the fix worked, and what simple metric would you hand to operations?
Read the worked answer
Measure the actual roam gap, not the average user experience.
- Capture over the air at the handset, filtered to the roam, and timestamp it against controller client stats and RADIUS logs.
- Define the metric precisely: the interval from the last data frame on the old AP to the first data frame on the new AP.
- Test in the real overlap zone, around the corner where cells meet, with the real traffic pattern, and repeat at least 20 times before declaring it fixed.
Targets: under 150 ms for voice with 11r; under 200 ms if you are relying on OKC and a cached PMK; anything over 500 ms will be audible to a picker.
For operations, give two numbers they can watch without a protocol analyser:
- Roam gap per handset per shift, sampled from controller client stats.
- RADIUS authentications per MAC per hour. If that count is above one, key caching is still not working, and you have an early warning before the pickers start complaining.