Posting this here as an FYI: https://bst.cloudapps.cisco.com/bugsearch/bug/CSCwm31864
The symptom we've seen is clients unable to connect to a specific AP, so they connect to faraway APs instead, or their connection drops when they attempt to roam to an affected AP. Only 2800/3800 series, not 9100 series, it seems. We first noticed the symptoms early this semester when on 17.9.5/APSP5 and still do on 17.12.4/APSP2.
Out of 3,000 of our 2800/3800s, we've had about a dozen repeat offenders identified by end user complaints. We hadn't gotten any complaints for a couple weeks. Yesterday I found a way to "monitor" for the issue via CLI and found half a dozen that were at 75% memory utilization or higher, and we rebooted them. Today there are 4 more.
My way to "monitor" it involves two steps. First, in the AP join profile, under AP > AP Statistics, enable "Monitor real time statistics" and "trigger alarm for AP". There's also an option to (automatically?) reload the AP, which I've opted not to use. You can customize the alarm %; I stuck with the default 75%.
Then, in the CLI, run the following command exactly, without removing any of the spaces, and remove any line breaks your browser adds; this is all on one line:
show ap config general | i AP Name|Memory alarm status : Active|CPU alarm status : Active
Here it is in "code sample" form if that displays better:
show ap config general | i AP Name|Memory alarm status : Active|CPU alarm status : Active
Optionally, issue a "terminal length 0" before the above command to avoid having to hit the space bar dozens of times to scroll through all your APs.
The resulting output is a list of all the AP names, and if a particular AP is in memory and/or CPU alarm status, a line will appear for that as well. If anyone knows of a better way to do this without DNAC, I'm open to suggestions. I'm told DNAC will reveal that information, but we don't have it yet.
We have a team of Cisco employees, from TAC to the BU to developers and others, working on this and a few other issues, and we're told a fix has been prepared that we'll be receiving soon in the form of an escalation APSP. Hopefully it will be incorporated soon into a public APSP. Meanwhile, I check daily for APs in alarm state and reboot them.
