Re: Poor 5Ghz throughput - 9800 / 17.9.4a / 1800-series APs - Page 5

Stuart Patton · ‎11-16-2023

Hi,

Per the title, I've got an issue with 5Ghz clients that have good signal strength because they are sat almost underneath the AP (1832 APs) yet but struggling to get more than 1Mbps throughput. I can see the channel utilisation is over 50% but zero TX/RX, which I assume is a measurement of wifi frames in the channel? We have sub 1ms latency from WLC to the AP on the wired network.

I'm not sure if this has only happened since upgrading to 17.9.4a from 17.9.3 (only done to close IOS XE HTTPS vuln). Out of curiosity, would upgrading WLC and APs cause all APs to change channel or do they remember their last channel and use it post upgrade? Reason for asking is that I have the same issue on multiple APs, which we managed to fix by manually changing the channel.

From what I can understand from the output below, there are no 5Ghz wifi interferers, RSSI is good and SNR is excellent. Does this mean it's likely to be a non-wifi interferer?

We do have Ekahau Pro and a Sidekick, so we can try to identify get to this location and scan the 5Ghz bands to see if we can see an interferer.

MA-WLC-HA#show ap name MGH.1.27.AP24 auto-rf dot11 5ghz
###################################################################

Number of Slots : 2
AP Name : MGH.1.27.AP24
MAC Address : 501c.b0b1.b3a0
Ethernet MAC Address : 501c.b0b0.5368
Slot ID : 1
Radio Type : 802.11ac
Subband Type : All

Noise Information
Noise Profile : Passed
Channel 36 : -102 dBm
Channel 40 : -102 dBm
Channel 44 : -102 dBm
Channel 48 : -102 dBm
Channel 52 : -103 dBm
Channel 56 : -102 dBm
Channel 60 : -103 dBm
Channel 64 : -102 dBm
Channel 100 : -102 dBm
Channel 104 : -102 dBm
Channel 108 : -102 dBm
Channel 112 : -102 dBm
Channel 116 : -100 dBm
Channel 132 : -100 dBm
Channel 136 : -101 dBm
Channel 140 : -101 dBm

Interference Information
Interference Profile : Passed
Channel 36 : -128 dBm @ 0% busy
Channel 40 : -128 dBm @ 0% busy
Channel 44 : -128 dBm @ 0% busy
Channel 48 : -128 dBm @ 0% busy
Channel 52 : -128 dBm @ 0% busy
Channel 56 : -128 dBm @ 0% busy
Channel 60 : -128 dBm @ 0% busy
Channel 64 : -128 dBm @ 0% busy
Channel 100 : -128 dBm @ 0% busy
Channel 104 : -128 dBm @ 0% busy
Channel 108 : -128 dBm @ 0% busy
Channel 112 : -128 dBm @ 0% busy
Channel 116 : -128 dBm @ 0% busy
Channel 132 : -128 dBm @ 0% busy
Channel 136 : -128 dBm @ 0% busy
Channel 140 : -128 dBm @ 0% busy

Rogue Histogram (20/40/80)
Channel 36 : 0/ 0/ 0
Channel 40 : 0/ 0/ 0
Channel 44 : 0/ 0/ 0
Channel 48 : 0/ 0/ 0
Channel 52 : 0/ 0/ 0
Channel 56 : 0/ 0/ 0
Channel 60 : 0/ 0/ 0
Channel 64 : 0/ 0/ 0
Channel 100 : 0/ 0/ 0
Channel 104 : 0/ 0/ 0
Channel 108 : 0/ 0/ 0
Channel 112 : 0/ 0/ 0
Channel 116 : 0/ 0/ 0
Channel 132 : 0/ 0/ 0
Channel 136 : 0/ 0/ 0
Channel 140 : 0/ 0/ 0

Load Information
Load Profile : Passed
Receive Utilization : 0%
Transmit Utilization : 0%
Channel Utilization : 55%
Attached Clients : 7 clients

Coverage Information
Coverage Profile : Passed
Failed Clients : 0 clients

Client Signal Strengths
RSSI -100 dBm : 0 clients
RSSI -92 dBm : 0 clients
RSSI -84 dBm : 0 clients
RSSI -76 dBm : 0 clients
RSSI -68 dBm : 0 clients
RSSI -60 dBm : 2 clients
RSSI -52 dBm : 5 clients

Client Signal to Noise Ratios
SNR 0 dB : 0 clients
SNR 5 dB : 0 clients
SNR 10 dB : 0 clients
SNR 15 dB : 0 clients
SNR 20 dB : 0 clients
SNR 25 dB : 0 clients
SNR 30 dB : 0 clients
SNR 35 dB : 0 clients
SNR 40 dB : 1 clients
SNR 45 dB : 6 clients

Nearby APs
AP 501c.b0b1.9daf slot 1 : -34 dBm on ( 64, 20 MHz) (10.90.160.116)
AP 501c.b0b1.a2ef slot 1 : -53 dBm on (140, 20 MHz) (10.90.160.116)
AP 501c.b0b1.bd2f slot 1 : -54 dBm on ( 36, 20 MHz) (10.90.160.116)
AP 501c.b0b1.9d4f slot 1 : -76 dBm on ( 64, 20 MHz) (10.90.160.116)
AP 501c.b0b1.b78f slot 1 : -79 dBm on (100, 20 MHz) (10.90.160.116)
AP 501c.b0b1.ba0f slot 1 : -82 dBm on ( 48, 20 MHz) (10.90.160.116)
AP 501c.b0b1.bc2f slot 1 : -82 dBm on ( 64, 20 MHz) (10.90.160.116)

Radar Information
Channel changes due to radar : 0

Channel Assignment Information via DCA
Current Channel Average Energy : -86 dBm
Previous Channel Average Energy : -86 dBm
Channel Change Count : 0
Last Channel Change Time : 11/02/2023 23:14:35
Recommended Best Channel : 132

RF Parameter Recommendations
Power Level : 6
RTS/CTS Threshold : 2347
Fragmentation Threshold : 2346
Antenna Pattern : 0

Persistent Interference Devices
Class Type Channel DC (%%) RSSI (dBm) Last Update Time
------------------------- ------- ------ --------- ----------------
All third party trademarks are the property of their respective owners.

MA-WLC-HA#show ap name MGH.1.27.AP24 neighbor summary
BSSID Channel Channel-width Slot RSSI Last-Heard SSID Neighbour
--------------------------------------------------------------------------------------------------------------------------------------- ----------------------------------------
b095.7582.a5ca 3 40 Mhz 0 -88 11/16/2023 09:32:27 TP-Link_A5CA FALSE

MA-WLC-HA#

Thanks,

Stuart

t-nitta · ‎03-02-2024

Recent bugs on AP1815s in this thread seem to be summarized in CSCwi92439. A few days ago, CSCwi92439 was made available to customers.

My system is running Mobility Express 8.10. I informed TAC that installing 8.10.190.0 to care of FN74035 caused issue CSCwi92439 symptoms.

I'm waiting to fix for "Aireos", but it will probably be fixed later in my system than everyone else. First of all, I hope that your (IOS based) systems will return to normal.

Ben Crissman · ‎03-08-2024

I ran into a similar but different issue on 9130 AP's. We had high utilization on 5 GHz. The trigger in my case was limited to these conditions.
17.9.4a APSP8, Zero wait DFS enabled. 40Mhz channel, Channel change or radio crash. once this happened i started to see high utilization in 5 Ghz. Clients reported poor connectivity. DNAC would showed constant poor roams. Client devices ended up bouncing between AP's.

To fix the state I disabled Zero wait DFS (and possibly force a channel change).
https://bst.cisco.com/bugsearch/bug/CSCwi96176?rfs=qvlogin

Jason Salmans · ‎03-08-2024

I have asked for an APSP for the 1815w on 17.9.4 and TAC is checking with the BU engineers working on this bug to determine if they'll do that or not.

My understanding is that 17.9.6 isn't estimated to be released until sometime in the Fall but 17.12.3 may be any time now. I certainly don't want to wait until September to fix this issue, especially if we feel it's impacting clients (at the very least we know RRM isn't making good decisions because of it), so if the APSP doesn't happen for some reason then I may be looking to move to 17.12.3.

Jason Salmans · ‎03-11-2024

One of the owners of another one of my cases who has some knowledge about this issue indicated they believe there may be an APSP already in the works for 17.9.5.

Leo Laohoo · ‎03-11-2024

@Jason Salmans wrote:
TAC is checking with the BU engineers working on this bug to determine if they'll do that or not.

APSP is one of the selling points for upgrading to IOS-XE, therefore, I really do not comprehend the hesitation &/or reluctance to release an APSP by the WNBU developers.

patoberli · ‎03-11-2024

I seem to have the 1815 issue also on 17.9.4a APSP6, although the bug states that only APSP8 is affected (17.9.4.208, while APSP6 = 17.9.4.201).

Has 17.9.5 solved it for you and the 1830 models?

Stuart Patton · ‎03-14-2024

We have not yet tried 17.9.5 but since the initial issue that I started this thread for, we've experienced an issue with AP joins (1832, 9105AX and 9120AX) after SSO switchover (separate TAC case) and possibly a memory leak on 17.9.4a with APSP 8 so I think we will almost certainly be trying 17.9.5 as soon as TAC decide that's the way forward.

Jason Salmans · ‎03-21-2024

I checked software downloads today and it looks like 17.9.5 now has an APSP that may fix our issue:
https://software.cisco.com/download/home/286321396/type/286325254/release/17.9.5

APSP release notes:
https://www.cisco.com/web/software/286325254/167761/Public_Release_Notes_9800_APSP_17_9_5.pdf

APSP Resolved Caveats:
CSCwj17587 APSP1 17.9.5 to fix for all AP COS
AP Platforms: All COS APs
APSP version: 17.9.5.201
CSCwi72191 Updating of ipv6 routes on COS AP when AP moves from one vlan to another
CSCwi88967 AP9120 randomly disconnecting from the WLC
CSCwi92439 AP1815s are reporting high channel utilization in 5Ghz.
CSCwi64652 AX APs do not reset BLE interface after 100 attempts
CSCwi95945 Not plumbing GTK to driver when GTK rekey ( Further fix for CSCwi19481)

Barring any show-stoping Open Caveats, I plan to upgrade to 17.9.5 from 17.9.4 and apply this APSP tomorrow night.

Stuart Patton · ‎03-22-2024

For info, since moving to 17.9.4a + APSP 8, TAC think we may have hit this bug regarding the AP join issue I mentioned above https://bst.cloudapps.cisco.com/bugsearch/bug/CSCwi04855

TAC case SR 696877222 refers

Jason Salmans · ‎03-23-2024

We applied 17.9.5 and APSP 1 this morning... DNA Network health is showing MUCH better (was in the 70% range before and is now upper 90% with minimal users on campus). When looking at it previously, this issue was definitely dragging the score down so maybe we're good now.

eglinsky2012 · ‎03-25-2024

Thanks for the update, Jason. Have you received any feedback from users or other metrics on performance besides reported channel utilization?

Bug CSCwi92439 states there's an AireOS fix as well, 8.10.190.8, which I'll plan to obtain from TAC.

Jason Salmans · ‎03-25-2024

I don't think we have so far. We only had a few tickets open for issues in these residence halls anyway. By and large, we've had problems with students these days simply ignoring the problem or finding a workaround (mobile phone hotspot) instead of reaching out for assistance to our on-campus IT helpdesk. The current generation in college just seems adverse to using traditional methods of reporting these issues or just don't necessarily want to take the time to do so.

Leo Laohoo · ‎03-25-2024

@Jason Salmans wrote:
The current generation in college just seems adverse to using traditional methods of reporting these issues or just don't necessarily want to take the time to do so.

If the process does not include TokTik, then it is not gonna happen. (joke)

t-nitta · ‎03-26-2024

My system has been updated to Mobility Express 8.10.190.9. Channel utilization at startup is about the same as the previous symptom-free version. We are currently observing RRM performance.

Updates for Mobility Express, only an AP running the ME master controller failed to pre-download using the GUI. So this AP had to be updated using the CUI. I've notified TAC of this as SR 697067712.

t-nitta · ‎03-27-2024

> My system has been updated to Mobility Express 8.10.190.9.

My system has two Mobility Express systems.

In the first system, there were fifty-five AP1815 units, and six units showed high utilization. Of these, the interference of three AP1815Ws was using 124ch may be a my site-specific problem.

In the second system, there were forty AP1815 units, and three units showed High Utilization. One of these AP1815I unit had high utilization on a specific channel [36ch].

RRM could not resolve the above high utilization. However, I was able to suppress any high utilization by manualy changing the channel, so it's unlikely to be a big problem like it was with AireOS 8.10.190.0.

I plan to continue using Mobility Express 8.10.190.9 for a while.