3802i dual-band radio locking channel 36

[mmadden11]

Hi,

At a number of our sites, we disable 2.4GHz and have both radios running on 5GHz. Recently we are seeing the dual band radio cycling to channel 36 and locking on there. Eventually all 3802i AP's have the second radio locked to 36 and there is significant Co-channel interference.

Rebooting AP's and restarting the controller has no effect. Has anyone else seen this, or have any ideas?

I am running 8.5.120.0 on a mix of 5520 and 3504 controllers.

[Vengatesa Prasath]

Navigate to WLC gui 

Wireless> 802.11a > RRM > Dynamic Channel Assignment (DCA)

Check the channel assignment leader and Last Auto Channel Assignment field. 

Also check : Wireless> 802.11a > RRM > RF Grouping

Check who is the RF group leader.. 

If possible please share the screenshot. 

Regards,

Vengat 

[mmadden11]

Hi Vengat,

I had reviewed the settings in DCA. I have attached a screenshot, but it shows #36 as disabled so we can keep working without a CCI meltdown. (See Capture_01)

Similarly, for RRM it is still largely running as per the default settings. (See Capture_02)

[mmadden11]

Issue update:

I have been experimenting on separate network elements and I have been able to refine the problem; it is only present on the 5520 controllers. The 3405 are unaffected.

I can disable #36 and everything works like usual. Any ideas?

[Vengatesa Prasath]

Check if those new AP mapped to any specific AP group..

if so, check the Rf profile mapped allows channel 36 on it.  

Regards,

Vengat 

[mmadden11]

Hi Vengat,

I only have a 'default' AP group running, and all AP's are working.

Normally, the RF profile would be set to allow #36 (as per the standard base config) however if I allow it now, all radios in slot 1 on the 3802i AP eventually lock onto that channel with power set to 1 (i.e. the initial boot parameters for the AP).

It is like an instruction is picked up within first 30 minutes of operation (average of 15 minutes) which sets the AP back to a 'startup' process?

I have 5 sites with 30 - 180 AP's on local 5520 controllers all showing this identical error with two different firmware versions of 8.5.105.0 (x2) and 8.5.120.0 (x3). I am working with TAC, but it is not a known fault or bug, so they just tell me to upgrade to a new (ED) code version. I have no faith in this solution, but I will test on one of the sites today.

~Mik

[Freerk Terpstra]

Any results which you can share? I'm wondering if one of the APs "sees" it's RF neighbors once it moved to channel 36. Also, what happens when you initiate a DCA restart?

I have seen some weird issues with 8.5 code recently, so as a start I highly recommend you to use the latest 8.5 MR3 interim as recommend by the escalation guys. I haven't seen this problem myself, however most of our customers are on 8.2.166.0 (MR6) or 8.2.167.7 (MR7 interim). So if you don't rely on specific features from 8.3 or 8.5, it might worth a shot to see what happens with these versions of code on a 5520 installation.

If the issue is reproducible TAC should log a bug for you, you can also ask the engineer to look up bugs CSCvi82284 and CSCve24687 for related debug information.

Keep us posted and good luck!

[MikMadden]

Hi Freerk,

I haven't had much success, and now that I am dealing with ARP problems that stop my users roaming properly, I have just disabled #36 across the board - it still gives me a dozen channels to work with (20MHz) and I will circle back to it later.

Thank you for your advice on the firmware - it looks like I need to progress anyway to resolve other issues.

~Mik

[mmadden11]

Hi,

So a firmware update fixed my ARP problems, but hasn't solved the Channel 36 issue on the B radio.

Has anyone got any ideas?

~Mik

[sbhadrav@cisco.com]

Cisco Bug: CSCve24687 - Channelization issue occurs when Cisco 3802 AP reverts to channel 36 for 75% of APs at a site.
Majority of 3802 APs will be on channel 36 at power level 1 even though many other APs are heard on same channel with high RSSI.