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
