How monitor Cisco AP load?

[Charlie Grey]

Question posted by 1 customer i dunno how to ans.

controller is C9800 wlc.

is there any way or how to monitor an AP load and get notify before clients wifi connections performance start going south??

[marce1000]

  - Checkout these commands (CLI) : show ap dot11 5ghz load-info
                                                                  show ap dot11 24ghz load-info
                                                                  show ap dot11 6ghz load-info

                    >...get notify before clients wifi connections performance start going south
         -           That is far from exactly defined and differs depending on many concrete parameters , 

 M.

[Flavio Miranda]

@Charlie Grey 

 If you have Catalyst Center or any other monitoring tool, I believe so. Only with the WLC 9800 I believe not.

[Leo Laohoo]

Yes and no. 

Yes, there is a way but it is not as expensive as the Cisco solution. 

One way is to get a "network sensor".  The Cisco solution was using a 1800S but it was very expensive because it requires DNAC and (the associated cost of) DNAC was the only reason why the 1800S failed as a product. 

Other vendors like Aruba has a network sensor that joins the WiFi and does regular "checks" to see how good (or bad) the WiFi "experience" is.  

[eglinsky2012]

In addition to the Aruba network sensor, check out Wyebot. They are a bit pricier than the Aruba sensors, but offer much more detailed information. 7Signal is another popular one.

Another helpful CLI command is: show ap summary load-info

That will show each AP's client count and channel utilization per radio. FYI, it takes a few minutes to run if you have some thousands of APs joined.

If you want to filter that to look for specific APs:

show ap summary load-info | include Clients|apname

...where apname is a set of characters that each of the APs you're looking for have in common, such as a building or room number.

In the GUI, you can get helpful information from Monitoring > Wireless > AP Statistics (for 360 overview), or Radio Statistics (for more details)

[Rich R]

I use sh ap summ load-info | inc <apnames>|AP Name|Utilisation|---- to give the full column headers because it's a double row header.

Note that it gives a total AP client count and a client count per radio slot but there's a cosmetic bug that the individual radio counts frequently don't add up to the total count.

We are currently using this to detect a problem we're seeing quite frequently on 17.12.4 where the AP just stops taking connections on the 5GHz radio.  We look for APs with clients on 2.4 but zero on 5GHz as possibly affected and then reload as needed (reload fixes the problem until next failure). As far as the AP and WLC are concerned the radio is still up and "working".  There are no logs to indicate a failure but 5GHz clients just cannot connect.  TAC case ongoing and currently making no progress ...

[marce1000]

 - @Rich R  >... but 5GHz clients just cannot connect.  TAC case ongoing and currently making no progress ...
                            One test you can then execute , for instance :
                           issue this command first on the AP not taking 5Ghz connections :
                           show  ap client-trace events mac aa:bb:cc:01:02:03 
    (the latter mac address must of course be changed accordingly to that of the particular client used for testing).

      Then during the connecting process (and later) follow up on the outputs shown or check the logs on the AP

  M.

[Rich R]

@marce1000 we have already done all the AP client debugs TAC asked for - they show NOTHING!  It's a completely silent/invisible failure.  The fact that the debugs/logs show nothing has had the TAC engineers confused - I've had to explain the issue multiple times.
Now they're asking for OTA captures so we're planning to get an engineer to customer site to get the OTA next time an AP fails but so far customer has been insisting on rapid reloads to restore service because it's a WiFi-first environment with very demanding users.

[marce1000]

   @Rich R  (wrote) >.                 ..Now they're asking for OTA captures ..
                              It's probably useful to also try to examine the spectrum health around those APs
                             (even on 5Ghz). 

  M.

[Rich R]

It's nothing to do with "spectrum health".

They were working (apart from other bugs) on 17.9.4. 
The 5 GHz failures have started since 17.12.4.

[mcarive]

Rich, 

If you want it for reference, our current TAC case is 698063033. The OTA's I took show that the APs are sending out beacons, but there is no communication with clients. I have provided these to TAC. As you may have observed, clients just move on to the next available responding AP. I use a combination of the "Client Count" network heatmap in DNAC along with the "No Activity on 5GHz" alert from DNAC being sent to syslog to try to catch and reset the offending radios.  

-Matt

[Rich R]

Excellent thanks Matt.

Ours is 697988162.  I'll pass your SR number to our TAC engineer and hopefully they can work on it together.

We are not using DNAC so we've written our own exception report to look for these.

Rich

[Rich R]

After a lot of stalling and timewasting TAC have finally told us this is being caused by https://bst.cloudapps.cisco.com/bugsearch/bug/CSCwk12169 and will apparently be fixed in 17.12.5 and 17.15.2.  We have asked for an APSP for 17.12.4 asap.  Would be good if others can escalate for the same.
Interestingly it supposedly affects 9105, 9115 and 9120 (bug was opened for 9120 originally) but we have only seen it affect 9105 so far.

[Rich R]

TAC have now confirmed CSCwk12169 will be fixed in 17.12.4 APSP4 currently planned to be released 11 November.

[Rich R]

APSP4 was deployed and within 24 hours we already had 4 APs affected again so we can now conclude that CSCwk12169 has not fixed the issue for 9105 APs!  TAC getting back to developers ...

Follow my updates on this at https://community.cisco.com/t5/wireless/cscwk48338-ax-ap-doesn-t-accept-clients/m-p/5224149/highlight/true#M277712