Wireless Access

Have a site that has 121 Access Points across 3 buildings. Have 1 building with 49 access points. This 1 building the clients loose connectivity at random. Sitting with a  group of IT folks and the system will start to loose packts to WAN and WLAN controller.  WLAN controller is located in diffrent building. However all wired clients still stay connected. 

Auth via Radius and PSK. Both on 2.4 and 5ghz. I have attached a screen shoot from wifi explorer whch seems weird with how the SSID single just dropps out at random. 

 you can see the other SSIDs doing the same thing. 

The signal would drop out at random due to collisions from too much coverage.  If your laptop misses a beacon, due to a collision, your client software might show it as a dropout.  I would check to see if you have most of the problems on the 2.4ghz band or the 5ghz  band.  If it is the 2.4ghz band, I would suggest you try to reduce the ARM Max-Transmit-Power by 3 and try to test again.

You can also take a look at the Dashboard and see what is the RF utilization of all of your APs on the 2.4ghz, and the 5ghz band separately to see if that is the case..

Thanks Colin,

This happens both on 2.4 and 5ghz. I want to start leaning twards RF interference. But after running an Ekahau survey on the site things seem to look good. I am going to check the ARM Transmit Power. 

Ekahau just shows coverage.  It does not show RF utilization.  The controller dashboard will show that...

Thank you all for the sugguestions. Couple things to add. This is what the client sees that is connectied to the SSID when the random "AP"? issue occurs. 

64 bytes from 10.1.224.1: icmp_seq=3007 ttl=255 time=2.511 ms
64 bytes from 10.1.224.1: icmp_seq=3008 ttl=255 time=2.085 ms
64 bytes from 10.1.224.1: icmp_seq=3009 ttl=255 time=1.595 ms
64 bytes from 10.1.224.1: icmp_seq=3010 ttl=255 time=4.193 ms
64 bytes from 10.1.224.1: icmp_seq=3011 ttl=255 time=3.291 ms
64 bytes from 10.1.224.1: icmp_seq=3012 ttl=255 time=2.658 ms
Request timeout for icmp_seq 3013
Request timeout for icmp_seq 3014
Request timeout for icmp_seq 3015
Request timeout for icmp_seq 3016
Request timeout for icmp_seq 3017
Request timeout for icmp_seq 3018
Request timeout for icmp_seq 3019
Request timeout for icmp_seq 3020
Request timeout for icmp_seq 3021
Request timeout for icmp_seq 3022
Request timeout for icmp_seq 3023
Request timeout for icmp_seq 3024
Request timeout for icmp_seq 3025
Request timeout for icmp_seq 3026
64 bytes from 10.1.224.1: icmp_seq=3015 ttl=255 time=12986.041 ms
64 bytes from 10.1.224.1: icmp_seq=3016 ttl=255 time=11983.303 ms
64 bytes from 10.1.224.1: icmp_seq=3017 ttl=255 time=10978.048 ms
64 bytes from 10.1.224.1: icmp_seq=3018 ttl=255 time=9974.616 ms
64 bytes from 10.1.224.1: icmp_seq=3019 ttl=255 time=8969.438 ms
64 bytes from 10.1.224.1: icmp_seq=3020 ttl=255 time=7965.455 ms
64 bytes from 10.1.224.1: icmp_seq=3021 ttl=255 time=6960.637 ms
64 bytes from 10.1.224.1: icmp_seq=3022 ttl=255 time=5958.693 ms
64 bytes from 10.1.224.1: icmp_seq=3023 ttl=255 time=4952.066 ms
64 bytes from 10.1.224.1: icmp_seq=3024 ttl=255 time=3948.472 ms
64 bytes from 10.1.224.1: icmp_seq=3025 ttl=255 time=2948.174 ms
64 bytes from 10.1.224.1: icmp_seq=3026 ttl=255 time=1947.539 ms
64 bytes from 10.1.224.1: icmp_seq=3027 ttl=255 time=946.697 ms
64 bytes from 10.1.224.1: icmp_seq=3028 ttl=255 time=1.530 ms
64 bytes from 10.1.224.1: icmp_seq=3029 ttl=255 time=2.251 ms
64 bytes from 10.1.224.1: icmp_seq=3030 ttl=255 time=7.684 ms
64 bytes from 10.1.224.1: icmp_seq=3031 ttl=255 time=4.360 ms
64 bytes from 10.1.224.1: icmp_seq=3032 ttl=255 time=2.555 ms
64 bytes from 10.1.224.1: icmp_seq=3033 ttl=255 time=1.831 ms

I feel that this is an AP issue not Client or RF. Looking at the coparison of these two snapshots of wifi explorer signal strength recorded or time. 

Good view

Good View working Network

Bad View problem network.

Bad View Network.

Do you have Drop Broadcast and Unknown multicast configured on all of your Virtual APs?  Uncontrolled broadcast traffic can also periodically generate the situation you are describing.

Could it be that you have high DFS radar detection? From the screenshot, it looks like all the APs in one area picked the same channel which is not expected and a disaster for overall performance.

Please check why the APs are all picking the same channel. If all APs are on the same channel and there is a radar/DFS event, the APs stop broadcasting till they have found a new channel. DFS events are clearly logged in the controller logs.

In parallel make sure there is an Aruba support case opened to find and solve the issue.

Thank you for the suggestions and ideas to look at. I dont have the expereince you all have so this is all good feed back. 

I have attached some txt files that have been pulled promptly after the clients experience the packet loss as described above. 

Thank you Guys

Attachment(s)

RBNA_WirelessClient_Issues.txt   4 KB 1 version

WirelessIssues_ClientData.txt   19 KB 1 version

I cannot find a reason for your issues in these logs (that mostly show client info, less AP info). Please consult the Aruba TAC as they have the proper troubleshooting skills to find the root cause for your APs dropping off.

On your client try to disable any form of battery saving/energy efficiency as on some chipsets/drivers that causes issues. To be honest, most times it just results in poor performance rather than SSID dropping from the air, checking does not hurt.