Wireless Access

Hello together,

 

today I discovered an issue with the automatic channel assignement of my aruba infrastructure, where many 5 GHz radios are going offline for a time of 30 - 45 minutes. I discovered the issue during a site survey with Ekahau, where half of my infrastructure (20 of 30 APs in one building) didn't show me a 5 GHz channel. The behavior was checked in one building with 30 APs, which were installed by me around 2 months ago.

 

I checked the behavior for affected APs on my controller via "show ap arm history ap-name <AP Name>". You can see the output at the attachement.

 

The AP seems to decides for a new channel all the time and sometimes turns it's radio off, when the RF density of neighbors seems high enough.

Is this really the excepted behavior of ARM?

 

The first site survey was done at the building when I turned all radios online manually. There were many overlapping channels at the time, because ARM needed more time to adjust the channel selection.

Right now, the result seems really problematic to me. The building is missing signal when radios turn of at the same time, even if neighbors adjust the transmit power.

 

RF settings are configured as following:

Country code:

Germany

Assigned and fixed channel bandwidth:

40 MHz

Used Channels:

UNII-2: Channels 52-56, 60-64

UNII-2 Extended: 100-104, 108-112, 132-136

Excluded Channels:

UNII-1: All excluded on purpose

UNII-2 Extended: DFS channels 116-120,124-128

 

A few words to my topology:

I have a master-standby topology, to which two local controllers are attached. One of the local controllers is used for a pool of AP-315 access points, that connect to the local controller via LMS IP. The second local controller is defined as secondary LMS.

 

Hardware specifications:

Master: Aruba7240 - Firmware 6.5.0.4_58404

Standby: Aruba7240 - Firmware 6.5.0.4_58404

Locals: Aruba7240XM - Firmware 6.5.0.4_58404

 

Used APs:

30x Aruba AP-315 in this building

 

Could someone give me a hint what is wrong here? We will migrate to AOS 8.3 in future and probably Airmatch will fix this, but right now ARM is needed.

 

Thanks a lot and have a great day.

Check if there’s any RADAR events in the logs:
https://community.arubanetworks.com/t5/Controller-Based-WLANs/How-can-I-find-any-past-radar-events-from-controller-logs/ta-p/291933

Or if you have ARM mode aware on the radio 5 GHz



Thank you

Victor Fabian

Pardon typos sent from Mobile

Those R flags mean radar.  Access points must vacate those channels immediately when the access point observes radar activity on those channels.  Uncheck those channels in your 40mhz regulatory domain.

Few things on this..

 

First, it looks like you disabled ARM to pick channel 36-48, which are the only non-DFS channels. Please include those in your channel plan as APs can move to those channels freely in case of a radar-detect. For DFS channels, the AP should monitor the channel for some time before it can select and use it. In general, it even makes sense to get a base coverage on your APs with non-DFS channels 36-48 and fill up the rest with DFS channels.

 

Then, I would upgrade the firmware as your current firmware is 20 months old and newer release have improvements in the actual radar detection (reduce false positives). A firmware upgrade could reduce the number of Radar events.

 

Third, if you can move to 20 MHz channels, you reduce the chance that a radar pulse hits your channel.

 

Finally, what is not completely clear to me is if you let ARM auto assign channels or you manually configured a static channel per AP. In the case of static configuration, the AP has no choice other than to go offline and wait till the channel is clean again. With the automatic assignment, the AP can move to another channel. As the AP in the log does switch channels, you are probably fine on that setting.