With or Without VIn my previous blog entry, I discussed what is necessary to get BSS Transition Management working with Cisco controller-based Wi-Fi networks. In this entry, I wanted to present a comparison of client behavior when BSS Transition Management is enabled to when it is not enabled.
For you to see 11v frames from your Cisco network, either aggressive load balancing or optimized roaming must be enabled. For this discussion, I will focus on optimized roaming. The optimized roaming engine will keep track of client statistics, such as RSSI and data rate, and disassociate clients that don't meet configurable thresholds. If BSS Transition Management is enabled (at the WLAN level) in combination with optimized roaming, the AP will send a transition request to a client before disassociating it, giving the client time to roam to a better AP. If BSS Transition Management is not enabled, or the client does not support it, the client will simply be disassociated.
Before I dive into the packet captures, we need to discuss a specific detail of optimized roaming: the engine only looks at RSSI of data packets, not management or action. To see optimized roaming work, the client must be moving data.
The test client was my Windows 10 Dell laptop with an integrated Intel 8260 dual-band wireless adapter. The advanced configuration for the adapter has a parameter called "roaming aggressiveness," which has 5 options, from lowest to highest. According to Intel's documentation, the setting "lowest" means the client will not roam unless it loses connectivity. I set roaming aggressiveness to "lowest" for the tests, so the optimized roaming engine would try to get my client to roam before it decided to itself.
The test WLAN had an SSID of Test, 5 GHz only. The WLAN was configured for WPA2-Enterprise with Fast Transition. BSS Transition Management was on for the first test, then turned off for the second.
The test setup was identical to my first post: two APs in local mode and two APs in sniffer mode, watching the same channels as the local mode APs nearest to them.
|Figure 1: Testing setup|
With 11v BSS Transition Management
|Figure 2: Transition Management|
To be honest here, it looks like the client was not happy with the SNR it was seeing from the new AP. There are probe requests/responses on channel 64, which was the channel of the "Back" AP it had been associated to. This could explain why the roam took 50ms.
Without 11v BSS Transition Management
|Figure 3: Abrupt Disassociation|
You can see from figure 3 that it took 800ms for the client to realize what had happened and send out probe requests, then another 90ms to get connected. Total time from disassociation to re-association response is nearly 900ms. Luckily, it was able to re-associate without having to do a complete EAP authentication cycle, otherwise the roam would have taking about a full second.
Comments? Suggestions? Please leave a comment below or reach me on Twitter @GiantsNerd.