Controller Based WLANs

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

by on ‎06-26-2014 02:53 PM

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


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.