Higher Education

We have a very stock client-match config.  However, investigating a handful of performance complaints I noticed that client-match is aggressively trying (and mostly failing) to push users to either 5ghz or to another AP.  The best commands I've found to investigate this are:

show ap arm client-match summary
show ap arm client-match history client-mac <mac-address>

I had to run

clear ap arm client-match summary

 as it seems like the counters are never reset so I had data from years ago.

For example:

Client Match Summary 
---------------------
MAC                SM (T/S)  LM (T/S)  BM (T/S)  MU (T/S)  VoM (T/S)  Moves (T/S)  Last Move (Time/Rsn/Dur))          Device Type  11v Moves
---                --------  --------  --------  --------  ---------  -----------  -------------------------          -----------  ---------
e4:2b:34:94:c6:e6  15/0      0/0       27/4      0/0       0/0        42/4         Aug 25 12:54:35 2020/Sticky/X      iPhone       41/11/1/0/0/0/0/15/1/0/13/0

In the last ~20hrs Aruba tried to push this iPhone to a new AP 15 times and tried to push it to 5ghz 27 times and only succeeded 4 times. The last 5 times were all within 10mins of each other.  

As I understand how all this active handling works is the AP actually disassociates the client from the AP to try to convince it to move (to either the new frequency or new AP).  Such an aggressive and repetitive model for client-match *has* to be having a negative effect on clients.  

Does anyone else see something similar? Does anyone think I'm missing something and it's not a problem?

Just looking at your data.  "Sticky" means that there is an AP that should be seen by the client much stronger.  That could indicate that the power on your APs are so high that clients are holding onto them, OR a client cannot see an AP that it is closest to.  For a client to generally be considered for a sticky move, it should be seen X db greater by the closer AP than the one that it is on...

If an AP was simply moving a client from 2.4ghz to 5ghz, it would always be to the same AP.

About client match, in environments where clients are highly  mobile, there will be quite a few tries, but the client could have moved on.

Take a snapshot of the transmit power of the 5ghz radio AP that the client was on and the transmit power of the 5ghz radio that ClientMatch was sending the client to and determine if it is too high.  Typically you would want to match the transmit power of your APs to your  EDIT clients, so that they can roam gracefully and end up on the right access point for where they are physically located.

With thousands of APs and users it is impossible to find a client/ap combination when it is happening.  So we haven't been able to figure out any way of "live" troubleshooting.  This is all after-the-fact analysis, thus getting any information from the client device, that the controllers/aps don't already log, has proven impossible.

I totally appreciate the whole "it's too random to capture live" aspect. 

I will add to this thread that we had done a great deal of work to fine-tune client match to not be too aggressive while still benefiting where appropriate. Appropriate disclaimer is that what I have below worked for us; use at your own discretion, but please don't use if you don't understand what's being changed exactly. (In other words, don't yell at me if things break from this!)

A couple other things first though... First, from the MM, using "show ap virtual-beacon-report client-mac <mac>" gives good insight to the varying RSSI each radio hears a particular client. So, if your poor-experience-user is recurrently experiencing issues in the same place, run that command on them (live) periodically and see how their world sees them. Second, keep in mind that I've found that the AP radios see a signal strength of a client close to 10dB better than that same client hears the radio. (e.g., radio sees macbookpro @ -56dB but the macbookpro sees the radio @ -66dB).

Here's what we're using:

Standard deployments:

cm-unst-ageout-intvl days 0 hours 2
cm-band-g-max-signal 10
cm-band-a-min-signal 70
cm-lb-thresh 50
cm-lb-client-thresh 50
cm-lb-snr-thresh 25
cm-lb-signal-delta 3

Dense deployments (e.g., classrooms/auditoriums):

    cm-unst-ageout-intvl days 0 hours 2            

    cm-band-g-max-signal 10

    cm-band-a-min-signal 70

    cm-sticky-snr 22

    cm-sticky-snr-delta 6

    cm-lb-thresh 50

    cm-lb-client-thresh 50

    cm-lb-snr-thresh 25

    cm-lb-signal-delta 3

Client Match can be a little hard to troubleshoot, but if you choose parameters suited to your coverage quality it's not that hard to make work pretty well.  If band steering is failing a lot it may be because your 5GHz signal is too weak for the clients' liking.  We don't steer a client to a 5GHz radio unless the signal strength is at least -60dBm.  When we used the default settings (-70 I think) we had many failed band steers.  We have far fewer now.

PS - Keep in mind that many drivers look for a signal >-70, but the radios and antennas in the phones aren't as good as the ones in the APs.  If the AP thinks the signal is -65, an iPhone probably thinks it's -72.  It won't want to go there, and if it goes it won't want to stay there.  Hence the cycle of steer, move, move-back, steer-again.