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.
monitor client health
Following anomalies can trigger a client move,
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