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.

[sderikonja1]

Jose,

Thanks for the info.

[jose_gonzalez]

It was a few year ago, so I am vague on details. It involved the clients showing the wrong MAC address of the default gateway. Verification was done using Wireshark packet capture. It was easy to spot because the clients never received a ARP replies and in the packet details it clearly had the wrong MAC address of the router listed. Proxy ARP is never needed on properly routed network. It is legacy and was originally intended for misconfigured networks.

[sderikonja1]

Jose,

For issues with Proxy-ARP, what kind of troubleshooting and analysis was done to determine that it affected ARP functionality?

[sderikonja1]

Jose,

I have played with Proxy ARP and it did not help resolve the association issue.

When it comes to CPU efficiency I could not tell a difference between 6.x, 8.x or 10.x. What I did observe is a high number of DFS events on 6.x, while 8.4 and 10.x would cause APs to stop moving any traffic on the wired interface. Even the serial console port is rendered unavailable. This applies to both AP230s and AP250s

John,

Not sure if the issue is the same but resulting action certainly is. The priority is after all to ensure clients can connect and take care of daily business. It bothered me though as I could not fix the problem, to at least know about it before the users report the issue, as sometimes it would take several days before they submit a ticket. I setup a Graylog server and started analyzing syslog messages to see if the misbehaving AP can be discovered sooner than later. I have come across a message like "kernel: [wifi]: wl1: 201 rx fifo 0 overflows!". Whenever an interface is generating hundreds of these messages per hour, the AP tends to refuse client association. I have a ticket open with support while I am waiting for another AP to start acting up. Problem is that most of the time I have to reboot the AP and skip troubleshooting for the sake of availability.