Wireless Access

Hello,

Today I encountered this article which states the following:

"ClientMatch leverages industry standards to accomplish its monitoring and control functions, including the 802.11k and the 802.11v standards. As a result, IT is assured of interoperability with no additional overhead."

Earlier this week, I wrote a separate forum post (here) in regards to 802.11k and other "client assisting" roaming protocols. Unfortunately, in my research, I found that there are clients out there that don't support 802.11k and these other protocols, and may actually have more trouble if those features are enabled.

The first article I linked to is the first time I've encountered any mention of a relationship between 802.11k, 802.11v, and ClientMatch. Previously, I've only heard that a forceful DEAUTH is used by ClientMatch to move clients off an AP.

There is no mention in the User Guide of exactly how ClientMatch accomplishes its tasks. It seems to me that these features are configured independently and operate independently.

Can anyone with inside information please shed light on whether there actually is interaction between 802.11k, 802.11v, and ClientMatch? If so, how does that relationship work? If there is a relationship, that means there could be a driver dependancy on using ClientMatch, which is not how ClientMatch is marketed.

Thanks a lot,

Tim

Hello Tim

I wrote an overview about roaming a while ago.

Read it and it migh asnwer some of your question

I hope it helps you

http://community.arubanetworks.com/t5/Unified-Wired-Wireless-Access/Technote-Wireless-Roaming-amp-Clientmatch-July-MHC/td-p/188308

Cheers

Carlos

Also here is a explanaiton of how clientmatch works which a read a while ago.  I had it on my favorites :)

http://www.wifikiwi.com/cwap/a-sticky-problem-wi-fi-clients-that-wont-roam/

Here is a indeep explanation of how clientmatch works

http://www.google.com/patents/US20130036188?dq=aruba+networks&hl=en&sa=X&ei=NsGcUeq7CbDl4AP2nIDwDg&ved=0CGMQ6AEwBg

Cheers

Carlos

Here's my own personal cheat sheet: 

802.11r = "fast roaming" (does handshake in advance, before switching.)

802.11k = "APs tell clients best AP" (If 1 AP has full signal strength but 50 clients connected, and another AP has 40% signal strength but 0 clients connected, it'll steer the client to the 40% signal strength AP.)

802.11v = "prevents sticky clients" There are sticky clients who like to stay connected to a 10% signal strength that's getting 500kb of bandwidth when a full strength AP is right next to them. (for clients with newer drivers who understand the standard it'll suggest they leave this AP and switch to a better one when the bandwidth gets low.) (for clients with older drivers who don't understand the standard, it'll kick them off/forcibly disassociate them if they're at a low bandwidth/signal strength threshold for a long amount of time. Which helps facilitate them connecting to the better AP right next to them. 

neochris,

Your cheatsheet is right.  The only issue with these extensions is that sometimes when you turn on 802.11r some clients have problems or do not like to associate with it on.  Some clients fix that issue with later versions of drivers.  Others have no issue and leverage 802.11r.  The problem is, that it is hard to keep up with which clients and which versions that applies to, so it is much better to leave it off across the board unless you can test all of the specific clients and client driver versions that you will be using.

UPDATE 6/2018 -  The updated RF and Roaming Optimization Validated Reference Design Guide (VRD) has been published and has updated recommendations about enabling 802.11v, k and r in user networks.  The VRD can be found here: http://community.arubanetworks.com/t5/Validated-Reference-Design/RF-and-Roaming-Optimization-for-Aruba-802-11ac-Networks/ta-p/432994

802.11k does equal tell clients the best AP, but....not all clients leverage all of the parameters or require enabling or disabling QuietIE for it to work:  http://community.arubanetworks.com/t5/Wireless-Access/802-11ac-clients-Intel-Dual-Band-Wireless-AC-7260-are-unable-to/td-p/188122/page/2

Lastly, 802.11v can "push" a client to different access points.  When clientmatch attempts to load balance or steer a client to a band, it can use 802.11v to "push" the bssid it wants it to connect to.  Unfortunately, some clients actually advertise that they support 802.11v (hello chromecast), but don't actually do anything when they receive a transition frame from the AP.

Long story short, 802.11v is probably  the only protocol that you can enable blindly without testing anything.  If you turn on 802.11k, you need to experiment with the Quiet IE parameter, otherwise some Intel Clients will not be able to connect.  Lastly, 802.11r is a wildcard and some older clients might have problems even associating with it enabled.  The strategy should be to get all clients associated with nothing enabled and slowly enable protocols with your tested clients.  Ideally, you can disable all, and just use the power of the AP and supported rates of the AP to influence WLANs with many different types of clients.  You could also setup a specific SSID with extensions enabled for clients that supports each extension.

I can tell you for a fact that ClientMatch does not require 11k/11v, because we use it in production

and can see the steering events/etc.  Everything I've seen states 11k/v/r will be used if it is enabled and the client supports it, but if not, deauths are used.

Example:

http://www.airheads.eu/t5/Unified-Wired-Wireless-Access/Client-Match/td-p/77618/page/2