Wireless Access

Reply
Contributor I

Complaints after upgrade from 6.4.4.9 to 6.5.0.3

We recently upgraded our 7210 controller from 6.4.4.9 to 6.5.0.3. We have mostly AP-205s in place, with some 93-Hs and a few other one offs.  We are starting to receive complaints from students in dorm areas with the 205s about wireless issues.  In some cases, we've seen that they are attached to an AP on another floor or farther away than one very close to their room.  In other cases, we are starting to troubleshoot what look like garden variety signal / power / other issues that we've gone through in the past when tweaking the placement of APs.

 

Has anyone moved from 6.4 to 6.5 and experienced any issues?  No APs were added or moved during this upgrade, so we're starting to walk through normal troubleshooting procedures to see what we can figure out.  Thanks.

 

Re: Complaints after upgrade from 6.4.4.9 to 6.5.0.3

You could start looking at a couple of things:

- controller dashboard to have an idea if you guys have Aps reporting RF High utilization

- RF Management / ARM settings and what are the power levels set for 2.4 and 5

- 80 Mhz should be disabled under ARM

Please take a look at the RF and Roaming optimization VRD for 802.11ac
https://community.arubanetworks.com/t5/Validated-Reference-Design/RF-and-Roaming-Optimization-for-Aruba-802-11ac-Networks/ta-p/227716
Thank you

Victor Fabian
Lead Mobility Engineer @ Integration Partners
AMFX | ACMX | ACDX | ACCX | CWAP | CWDP | CWNA

Re: Complaints after upgrade from 6.4.4.9 to 6.5.0.3

Do you guys have in the same RF domain a mixture of 93H/205H ?
Thank you

Victor Fabian
Lead Mobility Engineer @ Integration Partners
AMFX | ACMX | ACDX | ACCX | CWAP | CWDP | CWNA
Contributor I

Re: Complaints after upgrade from 6.4.4.9 to 6.5.0.3

The 205s are not H models, just plain 205s.  The 93H models are used in some one off areas, such as a room off on its own away from the normal dorm halls where we have the 205s.

Re: Complaints after upgrade from 6.4.4.9 to 6.5.0.3

My apologies , the reason I asked is because either 205/205H are 802.11ac and if you mixed them with 93H (802.11n) in the same RF domain then you need to disabled VHT under HT-SSID-PROFILE and under ARM PROFILE
Thank you

Victor Fabian
Lead Mobility Engineer @ Integration Partners
AMFX | ACMX | ACDX | ACCX | CWAP | CWDP | CWNA
Guru Elite

Re: Complaints after upgrade from 6.4.4.9 to 6.5.0.3


jwhitaker@transy.edu wrote:

We recently upgraded our 7210 controller from 6.4.4.9 to 6.5.0.3. We have mostly AP-205s in place, with some 93-Hs and a few other one offs.  We are starting to receive complaints from students in dorm areas with the 205s about wireless issues.  In some cases, we've seen that they are attached to an AP on another floor or farther away than one very close to their room.  In other cases, we are starting to troubleshoot what look like garden variety signal / power / other issues that we've gone through in the past when tweaking the placement of APs.

 

Has anyone moved from 6.4 to 6.5 and experienced any issues?  No APs were added or moved during this upgrade, so we're starting to walk through normal troubleshooting procedures to see what we can figure out.  Thanks.

 


First look at the Channel Utilization for APs on the dashboard to understand how your network is doing.  Channel Utilization above 5% or more at midnight is not a good start.  That would indicate that the power on your access points are too high, causing clients to hold onto APs that they should not be on.  If it is above 40-50% during the day in sparse locations, you need to lower the power, cut rates, drop broadcasts or remove lower rates on all of your SSIDs to get the utilization down.

 

To take it a step further type "show ap arm state ap-name <name of ap>" to see how many APs each AP with a problem can see.  If an AP can see another AP on the same channel with an SNR of over 20, you will have cochannel interference that will affect your customer's performance.

 

I feel more people complain when you tell them that you have upgraded.  Look into the issues above first to cover your bases..



Colin Joseph
Aruba Customer Engineering

Looking for an Answer? Search the Community Knowledge Base Here: Community Knowledge Base

Frequent Contributor I

Re: Complaints after upgrade from 6.4.4.9 to 6.5.0.3

Hi Jason,

I don't want to lead you down the wrong path, but we upgraded to 6.5.0.3 back in November and recently came across an issue where a small population of AP-225s are resetting their 2.4GHz radios every 2 seconds - resulting in the SSID not being broadcasted on the 2.4GHz band - although the 5GHz SSID continues to function. I noticed this behavior back in December on one of our ticket-scanner AP where the manager said he could see it on his iPhone but not on the scanners -> when I saw his iPhone I immediately recognized the "5GHz delay" on the SSID. I rebooted the AP-225 and the problem went away. Only recently did I realize we may have a larger scale issue - my co-worker submitted a post after I discovered a 205H AP with about 13,000 radio resets in an area where a large population of APs only have maybe 10-15 at most - http://community.arubanetworks.com/t5/Wireless-Access/Problem-with-radio-resets-quot-BIG-Hammer-quot/m-p/285325


We haven’t had any reports beyond 1 or 2 about there being an issue as it appears a large amount of students are connecting to the 5Ghz radio – I was actually impressed that our 2.4 and 5 counts were 20% to 80%.

You could do a few quick samples on your AP-205 by running the following command and looking at "Total Radio Resets". However, some resets are due to interference as cjoseph as mentioned in our other posts - should compare similar models - 225 with a 225, 205 with a 205, and vice-versa.

 

show ap debug radio-stats ap-name <ap-name> radio 1

The big indicator is checking the driver-log and seeing BIG-hammer!!! reset over and over. A few 225s are generating these logs continuously.

show ap debug driver-log ap-name <ap-name>

[6333581.707517] chan dur      ibss           obss           interf       time
[6333581.707527] wl1: fatal error, reinitializing
[6333581.707538] wl1: wlc_reset: !!!BIG-hammer!!!
[6333581.762945] wl1 bmac set short slot 1, wl status 1
[6333581.793808] wl1: ap watchdog handler error
[6333583.707497] wl1: bcn inactivity detected HAMMERING
[6333583.707509] wl1: txbcnfrm 0 prev txbcnfrm 0 txbcn inactivity 2 timeout 2
[6333583.707521]
[6333583.707523] chan dur      ibss           obss           interf       time
[6333583.707533] wl1: fatal error, reinitializing
[6333583.707544] wl1: wlc_reset: !!!BIG-hammer!!!
[6333583.732442] stats > 100: ccastats_us: 8532, acc->statss_ms: 2
[6333583.763051] wl1 bmac set short slot 1, wl status 1
[6333583.793901] wl1: ap watchdog handler error
[6333585.707497] wl1: bcn inactivity detected HAMMERING
[6333585.707508] wl1: txbcnfrm 0 prev txbcnfrm 0 txbcn inactivity 2 timeout 2
[6333585.707520]
[6333585.707523] chan dur      ibss           obss           interf       time
[6333585.707533] wl1: fatal error, reinitializing
[6333585.707544] wl1: wlc_reset: !!!BIG-hammer!!!
[6333585.762967] wl1 bmac set short slot 1, wl status 1
[6333585.793819] wl1: ap watchdog handler error
[6333587.707005] wl1: bcn inactivity detected HAMMERING
[6333587.707017] wl1: txbcnfrm 0 prev txbcnfrm 0 txbcn inactivity 2 timeout 2
[6333587.707029]
[6333587.707031] chan dur      ibss           obss           interf       time
[6333587.707042] wl1: fatal error, reinitializing
[6333587.707052] wl1: wlc_reset: !!!BIG-hammer!!!
[6333587.762456] wl1 bmac set short slot 1, wl status 1
[6333587.793287] wl1: ap watchdog handler error
[6333589.707497] wl1: bcn inactivity detected HAMMERING
[6333589.707508] wl1: txbcnfrm 0 prev txbcnfrm 0 txbcn inactivity 2 timeout 2

Something of interest is that we don't have these problems on our 205Hs besides just the single outlier. This problem is largely noticeable in our 4th residence hall which is composed almost entirely of 205s - you actually led me to run the radio-stats command on our 233 APs and I only found maybe 4 or 5 that had the expected 10-15 counts. Now these stats could be normally considered all the home-devices that get brought into the rooms - but it's definitely an oddidity.

Finding out if your APs are exhibiting this issue is easier with a syslog server and setting the AP System Profile Driver Log to debugging (I tried the other levels one by one but didn't get the results till I reached debugging) -> note this is going to send a large amount of logs to your syslog server than normal. I consulted with our syslog admin prior to enabling this level and left it on for about 30 minutes to an hour. You should probably open a TAC case to be safe.

If you have splunk I could share the query our syslog admin created for us that has helped see where we have potential problems. We have a TAC case opened from last week and just yesterday they gathered some more logs to send to the development team.

Guru Elite

Re: Complaints after upgrade from 6.4.4.9 to 6.5.0.3

There are so many variables, you should start by opening a TAC case...



Colin Joseph
Aruba Customer Engineering

Looking for an Answer? Search the Community Knowledge Base Here: Community Knowledge Base

Frequent Contributor I

Re: Complaints after upgrade from 6.4.4.9 to 6.5.0.3

:-) I'm laughing right now because "There are so many variables" are the exact words I tell folks every day and is very true. It's definitely been a great learning experience.


#AirheadsMobile
Guru Elite

Re: Complaints after upgrade from 6.4.4.9 to 6.5.0.3

On a wired network, most devices perform uniformly.  That is not the case for a wireless network, so care must be taken to design it.  A wired network is not necessarily shared, so the performance of some devices do not determine the overall performance of the network.  In wireless, the bandwidth is shared among devices as well as among any type of energy that manages to appear on that band, so that creates many variables.  It is however possible to design a wireless network that takes all of those variables into account and make it perform like it should.  Nobody should just take wireless out the box, put it out there and expect it to perform well.  It should be designed, and periodically reviewed to ensure it is performing as expected.  In small networks, it is not especially hard to do.  In larger networks, where the feedback loop between consumers of the network and designers of the network, it is particularly difficult.  With all that being said, it is possible to tune the network synthetically and statistically to provide the best performance, even without alot of feedback.  I detail much of this at this link here:

 

http://community.arubanetworks.com/t5/Technology-Blog/Removing-the-Bottleneck-in-Wireless/ba-p/77978



Colin Joseph
Aruba Customer Engineering

Looking for an Answer? Search the Community Knowledge Base Here: Community Knowledge Base

Search Airheads
cancel
Showing results for 
Search instead for 
Did you mean: