- Cisco Community
- Technology and Support
- Wireless - Mobility
- Wireless
- Re: Poor 5Ghz throughput - 9800 / 17.9.4a / 1800-series APs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
Poor 5Ghz throughput - 9800 / 17.9.4a / 1800-series APs
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
11-16-2023 02:21 AM - edited 12-18-2023 02:56 AM
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
- Labels:
-
Catalyst Wireless Controllers
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-17-2023 09:47 AM
Has anyone else seen an improvement with APSP8 applied? I've been seeing high utilization on 5ghz with 1815w units and applied APSP8 this morning. APs are all updated and rejoined but still seeing the high utilization.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-28-2023 04:52 AM - edited 12-28-2023 05:32 AM
Bit of an update....Unfortunately we didn't get permission to go from 17.9.4a APSP 6 to APSP 8 until last night. APSP 8 was applied with a "one shot" upgrade and the WLC reported it completed successfully without impact.
Afterwards, the initial signs were not looking good - we were still showing high channel utilisation, so I would concur with @jason that it is not fixed. However, on digging a bit further, I spotted the CAPWAP uptimes for the APs was about two weeks, which does not correlate with them upgrading.
A "show ap image" on the WLC is showing 17.9.4.208 as the primary image and 17.9.4.201 as the backup image but SSHing to an AP I've confirmed it's definitely still running 17.9.4.201 (APSP 6) with 17.9.4.208 (APSP
We've been going back and forth with our TAC engineer and he has reproduced the behaviour with the APs not rebooting in the lab, and will be reporting back to engineering/BU.
At the moment we are resetting selected APs to resolve the issue, but we'll reset all of them again tonight to ensure everything is upgraded and I'll be doing periodic "show ap auto-rf dot11 5ghz | i Channel Utilization" to see if the issue comes back.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-28-2023 05:15 PM
@Stuart Patton wrote:
he has reproduced the behaviour with the APs not rebooting in the lab
Cisco's "quality control" doing a bang up job, as usual.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-28-2023 07:31 PM - edited 12-29-2023 06:07 AM
@Stuart Patton wrote:A "show ap image" on the WLC is showing 17.9.4.208 as the primary image and 17.9.4.201 as the backup image but SSHing to an AP I've confirmed it's definitely still running 17.9.4.201 (APSP 6) with 17.9.4.208 (APSP
as the backup image. I've then rebooted the AP and when it completed it was showing 17.9.4.208 as the running image with 17.9.4.201 as the backup image, and (hurrah) channel utilisation back to single figure percentages.
Did you do a Commit after activating APSP8? When I installed it, I did not look for the running version once APSP8 activation was complete, but the APs did seem to reboot after the commit for me. This was my first APSP, so I assumed that was normal. Anyway, they are currently running 17.9.4.208 per CLI, no manual reboots needed.
My upgrade path was different; I went from 17.9.4 with no patches to 17.9.4a then APSP8. So, maybe the issue for you was either not committing or a bug caused by your specific upgrade path (APSP6 to APSP8). Since TAC reproduced it, it's probably the latter (unless by some chance they also didn't commit), but just thought I'd mention what I noticed.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-18-2023 01:03 AM
We were going to look at applying APSP 8 tonight or tomorrow, notwithstanding how close we are to the holidays. I wonder if the piece in the workaround for CSCwh75431 means you still have to factory reset the AP after APSP 8?
Our partner were engaging TAC as of Friday, but I'm beginning to think we be looking at reverting to 17.9.3 with the SMU to fix the IOS XE vulnerability. Either way, if an upgrade/downgrade then requires a factory reset of the APs, I'm going to be pi**ed - we literally have hundreds at one campus and we are a 24x7x365 operation.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-18-2023 02:08 AM
I'd be very surprised if you have to factory reset the APs after fix is deployed, but worth confirming with TAC anyway,
Please click Helpful if this post helped you and Select as Solution (drop down menu at top right of this reply) if this answered your query.
------------------------------
TAC recommended codes for AireOS WLC's and TAC recommended codes for 9800 WLC's
Best Practices for AireOS WLC's, Best Practices for 9800 WLC's and Cisco Wireless compatibility matrix
Check your 9800 WLC config with Wireless Config Analyzer using "show tech wireless" output or "config paging disable" then "show run-config" output on AireOS and use Wireless Debug Analyzer to analyze your WLC client debugs
Field Notice: FN63942 APs and WLCs Fail to Create CAPWAP Connections Due to Certificate Expiration
Field Notice: FN72424 Later Versions of WiFi 6 APs Fail to Join WLC - Software Upgrade Required
Field Notice: FN72524 IOS APs stuck in downloading state after 4 Dec 2022 due to Certificate Expired
- Fixed in 8.10.196.0, latest 9800 releases, 8.5.182.12 (8.5.182.13 for 3504) and 8.5.182.109 (IRCM, 8.5.182.111 for 3504)
Field Notice: FN70479 AP Fails to Join or Joins with 1 Radio due to Country Mismatch, RMA needed
How to avoid boot loop due to corrupted image on Wave 2 and Catalyst 11ax Access Points (CSCvx32806)
Field Notice: FN74035 - Wave2 APs DFS May Not Detect Radar After Channel Availability Check Time
Leo's list of bugs affecting 2800/3800/4800/1560 APs
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-18-2023 01:56 AM
In case TAC browse the forums:
MA-WLC-HA#show ap image | i MGH.1.27.AP24
MGH.1.27.AP24 17.9.4.201 17.9.4.27 None 0.0.0.0 N/A 0 N/A
MA-WLC-HA#
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 : -101 dBm
Channel 40 : -102 dBm
Channel 44 : -101 dBm
Channel 48 : -101 dBm
Channel 52 : -102 dBm
Channel 56 : -102 dBm
Channel 60 : -102 dBm
Channel 64 : -102 dBm
Channel 100 : -101 dBm
Channel 104 : -101 dBm
Channel 108 : -101 dBm
Channel 112 : -102 dBm
Channel 116 : -100 dBm
Channel 132 : -102 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 : 1%
Channel Utilization : 58%
Attached Clients : 3 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 : 0 clients
RSSI -52 dBm : 3 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 : 0 clients
SNR 45 dB : 3 clients
Nearby APs
AP 501c.b0b1.566f slot 1 : 0 dBm on (132, 20 MHz) (10.90.160.116)
AP 501c.b0b1.b6ef slot 1 : -16 dBm on (100, 20 MHz) (10.90.160.116)
AP 501c.b0b1.bd2f slot 1 : -18 dBm on ( 36, 20 MHz) (10.90.160.116)
AP 501c.b0b1.9daf slot 1 : -36 dBm on ( 64, 20 MHz) (10.90.160.116)
AP 501c.b0b1.618f slot 1 : -55 dBm on ( 36, 20 MHz) (10.90.160.116)
AP 501c.b0b1.a2ef slot 1 : -57 dBm on ( 44, 20 MHz) (10.90.160.116)
AP 501c.b0b1.ac8f slot 1 : -67 dBm on (104, 20 MHz) (10.90.160.116)
AP 501c.b0b1.bc2f slot 1 : -69 dBm on ( 64, 20 MHz) (10.90.160.116)
AP 501c.b0b1.ba0f slot 1 : -73 dBm on ( 36, 20 MHz) (10.90.160.116)
AP 501c.b0b1.9d4f slot 1 : -85 dBm on ( 64, 20 MHz) (10.90.160.116)
AP 501c.b0b1.b68f slot 1 : -85 dBm on ( 56, 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 : 12/14/2023 20:35:04
Recommended Best Channel : 116
RF Parameter Recommendations
Power Level : 7
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-29-2023 04:55 PM
I just checked in DNA and found one of the APs having the issue so that I could check version number in case a reboot would fix it. It shows it is properly on 17.9.4.208
Looking at the DNA history for the AP, there are times on different channels when it shows low utilization. DNA shows matching interference that matches exactly the 5ghz utilization. I'm not seeing any rogues on that channel, however, there two current neighbors on the same channel due to the high density in this particular building I'm looking at. I restarted the neighboring APs and monitored the 5ghz stats on the AP I was examining.. the busy % only went down a few from 81 to the high 70s (the two neighbors never disappeared off the neighbor list for some reason but I commanded a reset from the WLC to each and they definitely disappeared off of it for a while).
Here is a sample output... this is an 1815w so I'm assuming some of this may be limited since it doesn't have Clean Air.
MCE-WLC9800-T#show ap name Nutt-320D auto-rf dot11 5ghz
###################################################################
Number of Slots : 2
AP Name : Nutt-320D
MAC Address : 2cf8.9bde.de40
Ethernet MAC Address : 2cf8.9bb6.7648
Slot ID : 1
Radio Type : 802.11ac
Subband Type : All
Noise Information
Noise Profile : Passed
Channel 36 : -99 dBm
Channel 40 : -99 dBm
Channel 44 : -99 dBm
Channel 48 : -99 dBm
Channel 52 : -98 dBm
Channel 56 : -98 dBm
Channel 60 : -98 dBm
Channel 64 : -98 dBm
Channel 100 : -99 dBm
Channel 104 : -99 dBm
Channel 108 : -100 dBm
Channel 112 : -98 dBm
Channel 116 : -99 dBm
Channel 120 : -99 dBm
Channel 124 : -93 dBm
Channel 128 : -99 dBm
Channel 132 : -100 dBm
Channel 136 : -99 dBm
Channel 140 : -100 dBm
Channel 144 : -101 dBm
Channel 149 : -100 dBm
Channel 153 : -101 dBm
Channel 157 : -101 dBm
Channel 161 : -101 dBm
Channel 165 : -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 120 : -128 dBm @ 0% busy
Channel 124 : -128 dBm @ 0% busy
Channel 128 : -128 dBm @ 0% busy
Channel 132 : -128 dBm @ 0% busy
Channel 136 : -128 dBm @ 0% busy
Channel 140 : -128 dBm @ 0% busy
Channel 144 : -128 dBm @ 0% busy
Channel 149 : -128 dBm @ 0% busy
Channel 153 : -128 dBm @ 0% busy
Channel 157 : -128 dBm @ 0% busy
Channel 161 : -128 dBm @ 0% busy
Channel 165 : -128 dBm @ 0% busy
Rogue Histogram (20/40/80)
Channel 36 : 1/ 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 120 : 0/ 0/ 0
Channel 124 : 0/ 0/ 0
Channel 128 : 0/ 0/ 0
Channel 132 : 0/ 0/ 0
Channel 136 : 0/ 0/ 0
Channel 140 : 0/ 0/ 0
Channel 144 : 0/ 0/ 0
Channel 149 : 0/ 0/ 0
Channel 153 : 0/ 0/ 0
Channel 157 : 0/ 0/ 0
Channel 161 : 0/ 0/ 0
Channel 165 : 0/ 0/ 0
Load Information
Load Profile : Passed
Receive Utilization : 0%
Transmit Utilization : 0%
Channel Utilization : 80%
Attached Clients : 0 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 : 0 clients
RSSI -52 dBm : 0 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 : 0 clients
SNR 45 dB : 0 clients
Nearby APs
AP 2cf8.9bde.fb4f slot 1 : -45 dBm on ( 44, 20 MHz) (172.16.68.20)
AP 2cf8.9bdf.010f slot 1 : -54 dBm on ( 60, 20 MHz) (172.16.68.20)
AP 2cf8.9bde.e96f slot 1 : -55 dBm on (104, 20 MHz) (172.16.68.20)
AP 2cf8.9bde.e60f slot 1 : -56 dBm on (149, 20 MHz) (172.16.68.20)
AP 2cf8.9bc6.8f2f slot 1 : -68 dBm on (108, 20 MHz) (172.16.68.20)
AP 2cf8.9bde.dd0f slot 1 : -68 dBm on (165, 20 MHz) (172.16.68.20)
AP 2cf8.9bde.e52f slot 1 : -71 dBm on ( 64, 20 MHz) (172.16.68.20)
AP 2cf8.9bde.f8cf slot 1 : -72 dBm on ( 56, 20 MHz) (172.16.68.20)
AP 2cf8.9bab.accf slot 1 : -73 dBm on (108, 20 MHz) (172.16.68.20)
AP 2cf8.9bdf.030f slot 1 : -73 dBm on (149, 20 MHz) (172.16.68.20)
AP 2cf8.9b95.a3cf slot 1 : -74 dBm on ( 36, 20 MHz) (172.16.68.20)
AP 2cf8.9bdf.026f slot 1 : -75 dBm on (165, 20 MHz) (172.16.68.20)
Radar Information
Channel changes due to radar : 0
Channel Assignment Information via DCA
Current Channel Average Energy : -69 dBm
Previous Channel Average Energy : -42 dBm
Channel Change Count : 54
Last Channel Change Time : 12/29/2023 10:52:43
Recommended Best Channel : 108
RF Parameter Recommendations
Power Level : 7
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.On a side note, I've also noticed some (not this one) of these APs are showing extremely low neighbor signals like the first one in @Stuart Patton 's post. Sometimes I'll see neighbors on 5ghz indicating something ridiculously low such as -4 down to 0 db for a neighbor in a room down the hall when both APs are set down to power level 7 or 8. Meanwhile some much closer neighbors may not show at all. I don't know if this is related in any way but channel utilization is obviously still showing high on some of these units regardless of the neighbor db reported.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-02-2024 12:55 AM
Hi Jason,
I agree that post APSP 8 we are still seeing a handful of APs that still appear to have the issue. It's massively improved since APSP 6 (probably 20-30% of circa 450 APs affected) whereas now it's probably no more than 5% of APs, however since the reboot of all the APs on Thursday evening to upgrade them to APSP 8 the actual number has reduced further so possibly RRM is playing a part?!? Whether it's the same bug as CSCwh75431 or a new bug with the same symptoms, I don't know. Interestingly, the utilisation figure on those affected (last week) was higher than we'd seen on APSP 6 (normally 40-60% on affected APs) whereas on APSP 8 I've seen 70-80%, which seems similar to the output you posted above.
I did advise our TAC engineer last week that we were seeing the utilisation problem and they've got some further steps they want us to carry out, but that will need an AP in sniffer mode so won't happen for a few days until we can get to site.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-11-2024 07:42 AM - edited 01-11-2024 07:46 AM
We are seeing the same thing on a larger campus with 1815's. Updated to APSP8 (SSH'd to the APs and verified that APs showing high utilization, are indeed running 17.9.4.208) and the problem still exists.
Anyone come up with a resolution? I can also reiterate that it is not across ALL 1815's anymore, so it improved, but it is still happening across maybe 75% of them.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-11-2024 07:55 AM - edited 01-11-2024 07:55 AM
We have configured an AP in sniffer mode and found a candidate AP that is still showing the issue on 208 and will be providing captures to TAC early next week.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-11-2024 07:55 AM
TAC responded yesterday and indicated they agreed it is likely a software issue but that the 1815w is already out of software maintenance support so the software team will not be able to look at it further.
I've asked to escalate the case and engaged with our sales engineer who is looking into it now as well.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-11-2024 08:14 AM
A very unfortunate response from TAC, re: EOL. RF performance was great on 17.9.3, but we had a lot of 1815 crashes. This APSP8 fixed the 1815 AP crashes, but breaks RF and causes this false high channel utilization. They broke it, but wont fix it..?
Could you PM me the case number you have for this? We will ask our SE to also escalate and push for a fix too.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-11-2024 01:47 PM
@Jason Salmans wrote:
but that the 1815w is already out of software maintenance support so the software team will not be able to look at it further.
What a convenient excuse.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-12-2024 06:32 AM
I got a reply from the escalation request. They're not refusing to look at it further as much as just saying that TAC can't diagnose it and will have to assist with collection and then present the data to the development group to see if they're able to fix it or not. They did advise that we may need our account team involved which I have already done. They've also asked for some additional CLI and over-the-air captures so I'll have to work on that as I can.
Another important note.. they indicated APSP 8 was for 1830 and 1850 series APs and that, because the 1815w uses a different chipset, the APSP would not have solved the issue for that model which is why we're still seeing the issue.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide
