Evaluating High Collision Issues

[tandrews1]

I've looked through most of the available documentation I can find here including the Radio Frequency Interference Troubleshooting Guide (https://thehivecommunity.aerohive.com/s/article/Radio-Frequency-Interference-Troubleshooting?t=1545053626774). But am still perplexed by what I am seeing in some of our environments. I have policies set up that use the recommendations in the aforementioned guide, but I still see high collision issues across the enterprise.

I'm looking at a 250 in an elementary building right now. Summary State=High Collision. This AP was alerting earlier today and the teacher reported poor performance with a cart of Chromebooks. As this is a new building I had not made any adjustments yet, but in this area I applied radio policies to three APs in close proximity that have rectified similar issues in other buildings.

I also noted that one AP was definitely a bit too loud on 2.4 so I turned down the power. Now, looking at acsp neighbors the loudest I see is -67 on channel 6 on an AP two rooms away with that radio cranked down to 4. Nothing on 5ghz worse than -75.

Band steering is enabled, but all of these devices associate on 5ghz naturally. I see very little 2.4 activity.

So right now I have two clients associated. Both on wifi1.1. I cleared counters on wifi0 and wifi1 and let it go for 3 minutes. Then I show wifi0 _count and see:

0% rx retry rate

10833 rx CRC errors

85% rx CRC rate

And show int wifi1 _count:

3% rx retry rate

104 rx CRC errors

14% rx CRC rate

And now show int wifi0 and wifi1 show a summary state of "High Collision".

I'm baffled.

[w1f1n00b]

I've seen reboot resolve strange issues on several occasions typically with ap230's but this could be anecdotal as many of my sites have a majority of that model. I've never been able to get to the bottom of it as I'm typically trying to get things working as a higher priority to solving the underlying issue unfortunately. I've seen strangeness like this all the way up to 10.0r7a.

[jose_gonzalez]

6.5r11 on AP220 and 6.5r12 on AP330. We are running on on-premise HM Classic latest revision. The max code version we can go up to is 8.2 code. We tested 8.2 code and determined that it is 'heavier' (higher CPU usage) than 6.5 code. 6.5 code outperforms 8.2 codes in high density environments. Our Aerohive representatives tell us that 10.x code runs more efficiently, but currently we can not test it - as we need HM NG.

As far as APs having to be rebooted to get clients to authenticate, no that does not occur in our environment. Many years ago, with older 6.5 code there was DHCP issues that prevented clients from authenticating until the AP was rebooted. I also remember weirdness with clients not being able to get to the gateway with Proxy ARP enabled. Rebooting the AP worked around that, however the solution was disabling proxy ARP. I recommend disabling proxy ARP, if enabled.

[sderikonja1]

Jose,

What HiveOS version and what management platform? Do you ever get reports that clients cannot associate until an AP is restarted?

[jose_gonzalez]

I have been looking into this in a school district. During the day & night, checking high schools with over 100 APs in a one-to-one environment, I see the high collision rates on the 2.4ng wifi0 interface. I have recorded once over 99% of the radios at specific campus / point in time with wifi0 at 'high collision'. As Sam Pirok stated due to >10% CRC RX errors. Sound the alarm bells, NOT!

I did some testing, I logged at night when no one is at the campuses, with no clients connected to the APs, cleared the counters, still high RX CRC. No problem, it's probably radio interference, 3 channels, 1 to 1 environment - so I turned all down all the 2.4 radios power to level 5, to my surprise no difference. I've tried other things, such as increase the minimum SSID data rate to 18Mbps, enable high density radio settings, deny 802.11B clients, suppress beacon responses to low SNR clients. Nothing made a difference. Now here's the kicker, take that same campus with 90%+ 2.4Ghz radios in high collision rates, with 1000+ clients connected campus wide and look at the per client state using 'show station' - and behold 11.53% clients show high collision, 8.09% fair, 80.38% good overall.

Point I'm making is not fret over this statistic, use 'show station' to see individual client performance, as I noted the CRC RX error counters runs even without any clients connected, building unoccupied. If someone complains of poor performance don't forget your basics, any slowness by a end user will be reported as wireless. If they are running a Windows PC - the slowness is more likely be operating system related, hard disk usage and or CPU usage at 100%. Don't just take the end users account as firsthand, investigate. On the wireless - if you are running AP230 / AP330 disable QoS policies to save CPU power, using CLI supplicant 'no qos enable no-prompt'. On the Radio profiles disable background scanning if any clients are connected.

[w1f1n00b]

I'm curious if you ever got to the bottom of this, as I'm also dealing with similar issues. Here are some of the numbers I'm seeing. - https://thehivecommunity.aerohive.com/s/question/0D50c00007R9NzSCAV/ap550-high-rx-crc-rate-42-on-onl...