Wireless Access

i was Just Wondering  Technically How will AP instruct User to connect to Other AP ?

will user be de-associated from First one  ( AP will send his Message ) ?  if so what gurantees that user will connect after that to the best/needed one ? 

will user be de-associated from First one

Yes

if so what gurantees that user will connect after that to the best/needed one ? All ap's gathering info and sending it to the controller , then the controller... (read the yellow marked lines)

Just the best AP will answer to the client probe requests. (as far as i aware)

If the client is sticky (does not roam on its own to better AP), then the AP will send the client a deauth message thus encouraging it to reassociate to an AP with better RSSI.

I have at least one documented case where Client Match deauthed a client while on a Lync call.  I would think that should not happen, right?

The client could get deauth when on Lync call, because client-match does not check. Based on my knowledge, there are plans to enhance this in the future.

Till then, you could perhaps reduce the client match sticky client aggressiveness. Following KB article demonstrates how:

https://arubanetworkskb.secure.force.com/pkb/articles/FAQ/Client-Match-configuration-related-to-Sticky-Clients-AOS-6-3-and-above

---

@payal wrote:

The client could get deauth when on Lync call, because client-match does not check. Based on my knowledge, there are plans to enhance this in the future.

 

Till then, you could perhaps reduce the client match sticky client aggressiveness. Following KB article demonstrates how:

https://arubanetworkskb.secure.force.com/pkb/articles/FAQ/Client-Match-configuration-related-to-Sticky-Clients-AOS-6-3-and-above

---

Thanks Payal.

I take issue with the fact that Client Match would attempt to deauth a client with an active call.  This was clearly detrimental to the phone call my peer was on, so I don't see why Client Match would behave this way.  I can't say that Client Match has caused more issues than this one, but it's certainly piqued my curiosity.

Sorry, not at all trying to hi-jack the thread, but I wanted to follow-up on the question I had asked since I was able to confirm the Client Match behavior when on a Lync call.  I spoke to a Lync engineer at HQ, and confirmed Payal is correct.  Client Match will attempt to move a client regardless of a call being active.  The idea being that if the conditions are bad enough, the call may be suffering, thus Client Match kicks and moves the client which will hopefully improve the call quality.

As a follow-up to my previous replies, Aruba has enhanced ClientMatch so it does not move a client while a call is active.  Precisely what I was saying should not happen a year ago! :)  This enhancement was added in 6.4.3.1:

Multi-Media Sync-Up
Client Match offers a tighter integration with multiple media-aware ALGs to provide better call quality for
programs like Lync and Facetime. With Client Match’s ability to understand various media protocols, clients are not steered to different APs in the middle of an active media session. When the AP learns that the client is in a call, it will not attempt to steer the client to another AP until the controller indicates that the call has ended, allowing calls to run more smoothly without any disruptions to the
ongoing media flow.