Controller Based WLANs

How does Sticky client Trigger work with Client Match in ARM 3.0

Article is applicable for 6.2 and Above Aruba OS version, Where ARM 3.0 is implemented

 

Before we try to address the sticky client issue, what we define as a 'Sticky client' is -
Any client device which is stuck with a suboptimal AP is known as a "sticky client".
Prior to the controller applying the logic based on which sticky client issue is addressed,
the sequence of events mentioned below occurs.


1.Aggregate client-view of RF and continuously gather data as well as

  monitor client health

2.Trigger Algorithm match periodically, even after client is associated

  Following anomalies can trigger a client move,

Sticky Client Trigger


3.  Perform steer based on algorithm match

  • Notify all but the candidate AP to restrict association of the client being moved (X).

 

  • This is done by placing Client(X) in a blacklist table maintained by the AP,

                   it occurs on the non-best-match neighbor AP’s for 20 sec (default)

  • The AP blacklist table can hold a maximum of 128 entries per AP

 

  • AP sends a deauth to the client that needs to be moved

 

  • Now, Client’s re-association occurs with only the candidate AP

 

rtaImage (1).png

 

Version History
Revision #:
1 of 1
Last update:
‎06-26-2014 02:53 PM
Updated by:
 
Labels (1)
Contributors
Search Airheads
Showing results for 
Search instead for 
Did you mean: 
Is this a frequent problem?

Request an official Aruba knowledge base article to be written by our experts.