ā01-17-2019 01:20 AM - edited ā07-05-2021 09:42 AM
Hello,
I noticed some strange behavior yesterday on our 5520 controllers running version 8.5.135 and was wondering if this was 'working as designed' or rather a bug.
While troubleshooting a coverage issue, I noticed a lot of our APs were using a channel width of 20Mhz on the 802.11a radio while they were actually configured to use a width of 40Mhz (outputs attached).
Now the strange thing is, except for our BER site (which is configured to use 20Mhz), all other AP groups and RF profiles are set to 40Mhz. Even the global default 802.11a settings are set to 40Mhz so I have no clue why some APs changed to 20Mhz.
I checked again this morning and to my surprise, all the APs were broadcasting on 40mhz again. It turns out that all the wrongly 20Mhz APs received a simultaneous DCA channel update around 16:00 yesterday.
Is there any possible reason why those APs would change to 20Mhz or is this just another bug?
ā01-17-2019 04:50 AM - edited ā01-17-2019 05:01 AM
this is by design.
your global channel setting is "dynamic assignment" (see "*" behind channel)
so the WLC can dynamically chose the 20MHz channel or select 2x20MHz channels to form a 40MHz channel set.
clients are assigned 20 or 40 MHz channel on request.
so most likely on the AP's involved there are NO clients that are 40MHz capable or have requested 40MHz bandwith
By the way
802.11ac allows per-frame channel width and bandwidth signaling.
ā01-17-2019 06:36 AM - edited ā01-17-2019 06:40 AM
Do you perhaps have some documentation on this because I find that bit difficult to believe?
If I configure 40Mhz in the global 802.11a settings and also in the RF-profiles attached to those APs, you're saying they still might fall back to 20Mhz? Also how do you explain each 20Mhz AP went back to 40Mhz after the exact same DCA channel update, that doesn't make much sense either.
I've added another output of the current channel widths and all of them are still in 40Mhz. (BER RF profile is set to 20mhz so those are normal)
ā01-17-2019 06:55 AM - edited ā01-17-2019 07:04 AM
you will find some documentation here look at the section Dynamic Bandwidth SelectionāDBS (page-11)
it shows output from the command debug airwave-director channel enable where channel and bandwith are dynamically assigned
here the Cisco's introduction of DBS
ā01-17-2019 11:17 PM - edited ā01-17-2019 11:31 PM
Thank you for that link, that was a very interesting read!
However, if I understand correctly from below link, you have to select the 'best' option to enable DBS. This means that in our environment, DBS should not be enabled as most of our global settings and RF profiles have been set fixed to 40MHz.
Edit: For example, attached a pic of the current 802.11a bandwidth config for our ANT APs.
ā01-18-2019 12:16 AM
the AP's serving channels 52 - 140 can be influenced by the DFS compliance mechanism!
but I also see a change from (44, 48) to (44)
48 is at the border of the dfs range , so it may be included by dfs to avoid interference
Dynamic Frequency Selection (DFS) is created to increase the availability and usability of channels in the 5 GHz spectrum. Depending on regulatory domain, this can be from 4 to 12 additional channels. More channels imply more capacity. The DFS function detects radar signals and moves AP channel on valid detection, thus ensuring primary spectrum users (weather radar, military radar, and so on) that there will not be interference from the access point. DFS avoidance of radar also helps to prevent the AP from suffering from interference The DFS requirements also designates a Master AP as a monitor for the group that will steer clients away as well. Traditionally, there are some misgivings in North America about using DFS channels, but, there are only eight non DFS channels (each channel is 20 MHz wide). In the ETSI regulatory domain (Europe), there are only four non DFS channels and have been using DFS channels successfully for many years.
ā06-26-2024 07:26 AM
I noticed this too, but on 9800 WLC with 17.9.5 . It seems like this happens when event driven RRM is enabled. Then that "emergency" channel change doesn't seem to respect the usual configuration when it comes to channel width. If someone can test and confirm this, it would be appreciated.
ā06-26-2024 10:53 PM
@Oscar Olsson you are correct. Whenever a DFS event is detected, the AP swap the channel but it keeps the channel width configured @20MHz until a new DCA calculation happen and the channel is re-configured as per the RF profile assigned to it.
ā06-27-2024 01:36 AM
Interesting! The consequence is that many devices won't use that AP at all as they usually prefer AP's that have a higher channel width. So effectively, event-driven RRM disables that AP for many clients because they choose to roam to another AP with worse RSSI only because it has a higher channel width. Example: https://support.apple.com/en-us/102127
What's also unclear is if this behavior would be different if client scan reports would be enabled on the SSID - and I assume that would need to be "on" when the client roams as well? See below.
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