Wireless Access

Hi experts,

Wondering this question, and I have read some documents, but most of them just say "client is steered or moved to the best AP", like this one:

Not happy with this explanation, I continued searching and found this another explanation:

Point 6 says "AP-1 sends a de-auth to the PC". And here I wonder, if AP-1 sends a de-auth to the client, the client must re-authenticate and re-associate to a new AP, AP-3 in this case, causing disruption.

I understand that if the client supports .11v, the controller can send a BSS transition management request in order to suggest the wireless client another AP, and the steering can be done without disruption. This is the case of the first image above. But if the client doesn't support .11v, a de-auth message must be send to the client, and I understand this causes disruption. This is of the second image above.

Am I right? If not, how is the process performed?

Regards,

Julián

There is nothing more than that.  Either a deauth or a 802.11v transition.

Hi,

So it is true, the RF and Roaming Optimization for Aruba 802.11ac Networks VRD says very clear "802.11v and 802.11k capable clients will usually have a smoother, non-disruptive ClientMatch Steering experience." I thought the ClientMatch's benefits included all client types, like the ClientMatch datasheet says "A standards-based solution that works with all client types; including 802.11abg, 802.11n and 802.11ac clients; there's no need to purchase new clients or install new software". So, ClientMatch would steer your client to a better AP to improve your experience, but if your client doesn't support 802.11v (as many clients), you will suffer a disruption, and if your client supports it, who knows... ClientMatch theoretically improves roaming... What a dissapointment...

Regards,

Julián

Not all devices support 802.11v or 802.11k, so for those clients deauths are used.  Clients that are deauthed typically reconnect in less than a second, so the question is, from the client perspective is that even noticeable as a disruption?  Sending a deauth to a client is a standards-based action.  802.11v is designed to do that steering so, that is also standards-based.

There is also a dampening mechanism within ClientMatch so that it does not occur often for the same client, and clients get added to the unsupported list if it seems that they don't respond too well to deauths or even 802.11v.

In practice most people run Clientmatch without modification and they have no specific issues.  In extreme circumstances TAC will sometimes disable clientmatch during an engagement to isolate specific client behavior.  Clientmatch has been enabled by default in ArubaOS 6.3 and above and by far typically does not require changes.  The transmit power and data rates of access points have a greater effect on initial client roaming decisions.  Client Match typically kicks in minutes after the customer client has already roamed to deal with clients that somehow have roamed inefficiently,  ended up on the 2.4ghz band when they should be on the 5ghz band, or to load balance users.