Wireless Access

I hope this is in the right forum...

I am running two local M3 controllers with a single M3 as the master.  The master also acts as a secondary LMS for all APs that are spread across the two local controllers.  All controllers are running ArubaOS 5.0.4.1.  We won't be upgrading to 6.1 until January.

Previously, we had a great deal of disconnections and reports of slow connections.  We attributed this to allowing broadcast traffic on our main VAP.  Turning off broadcast traffic alleviated almost all of the reports of disconnections and slow speeds.  This surfaced, however, again today.  The speeds were reported as slow and the users would state that the application they were in (Citrix) was getting disconnected.

The users were located in a room that has approximately 10 APs in the vicinity.  It is a high density area (user wise) and therefore has a higher density of APs.  However, ARM is set to mode-aware so that most of the APs have actually been converted to air monitors on the g radio and only the a radios are actually in use as APs.  We do have band-stearing turned on, so this isn't a problem.

One user in question reported that the wireless icon in her system tray in Windows 7 would get the yellow triangle when she would get disconnected.  I could see significant packet loss by pinging her from my wired workstation.  In order to determine if it was just this user or other users on the AP, I started pings on 3 other users on the same AP and one by one they would all start losing a significant amount of packets - although not all at the same time.

I tried to reboot the AP which would also force the users to a different AP.  The primary complainer did switch to a different AP, but the packet loss continued.  Elsewhere on the wireless network, I started a ping to the Citrix server from my wireless laptop and got relatively no packet loss.  So, it was something in this area.  Unfortunately, this was right before the end of the day, so I didn't get to do two things that I would normally do.  I didn't get to look for interfering APs in the area and I didn't get a chance to perform an rf test.  We have airwave and I could see a good signal quality in airwave.

My question is what other troubleshooting steps and/or CLI commands would you perform to troubleshoot packet loss and frequent to periodic disconnects?

Thanks!

I would start by logging the use.

"logging level debug user-debug <mac>"

a RFT would be helpful. 

Change the policy to stop ARM scanning when seeing Citrix traffic and log the Citrix traffic. 

There is a lot of things that could be causing this.

Here's what I would do (assuming 5.x code or later):

show ap arm neighbors (look for any non-aruba neighbors)

show ap debug radio-stats ap-name someAP radio 0 advanced | include Busy (on a dual-band AP, radio 0 is 5Ghz and radio 1 is 2.4, anything above 20 on this output probably means that there is interference, either by non-802.11 or by other APs)

The user debug is also a great step, though if it is happening to multiple users in the same area, it is probably not specific to a single user. Also, make sure the wireless drivers on the client machines are up to date.

Thanks for the replies.  I will try these out and let you know how they work out.

---

@jcrouch wrote:

Thanks for the replies.  I will try these out and let you know how they work out.

---

Jcrouch,

I see from another thread that you have 6 SSIDs, and that is probably limiting your bandwidth even further, due to the management traffic overhead.  Depending on your environment, you probably cannot merge any of those SSIDs together anytime soon.  Since you are already dropping broadcasts on all your Virtual APs, there are three things that you can do:

- Make sure that Virtual APs that are only supporting clients on one band are ONLY broadcasting on that band.  If you have VOIP devices, for example, that only run on b/g, make sure that the Virtual AP's "Allowed Band"  parameter is ONLY "g" and not "all".  That will ensure that the management traffic from that particular wireless network does not contribute to the congestion on the "a" band.  If you have a guest network, you should experiment with just turning this to g, as well so that your devices running Citrix that are on the "a" band do not have to contend with management traffic from your guest WLAN.

- Use only 20 mhz instead of 40mhz channels for 802.11n on the 802.11a band - By default, only the "a" band uses 40mhz or "bonded" channels.  This provides higher throughput, but limits you to only 4 non-overlapping channels in the 5ghz side.  Since you have a high-density environment, you could gain 4 more channels in the "a" band and ease some contention if you do not bond channels in the "a" band.  This will allow your 802.11n clients in the "a" band to still have a maximum association rate of 130, which is plenty for Citrix, but could ease some of the congestion in a dense environment.  You can change this parameter in the ARM profile.  Go to Configuration> Wireless LAN> AP Configuration.  Edit the AP-Group that your APs are in.  Expand RF Management> Expand 802.11a Radio Profile> Expand ARM Profile.  Change the "Allowed bands for 40MHz channels" parameter in the ARM profile to "none".  Before you make the change, the channels that APs are on would look like "HT:36+", but after, they should look like just "HT:36".  That will let you know that your WLAN is using 802.11n, but not consuming two channels per ap.

- Use the "Local Probe Request Threshold" parameter under the Advanced Tab in the SSID Profile - Many times, in high density environments, clients will stay associated to access points that are very far away from them, because the driver in the client WLAN card believes that the signal is still good.  The biggest issue this creates is that a client that is far from an access point normally associates at a lower rate and transmits more slowly, because of the distance.  This will also degrade the throughput of clients that are closer and associated to the same AP, because they have to wait longer for that client to transmit.  If you change the "Local Probe Request Threshold" to something like 20 or 25 (dB), access points will only accept associations clients that are of a certain signal strength, limiting clients to only choose access points that are better for them.  This parameter is located under the Advanced Tab of the SSID profile.  To edit it, go to Configuration> Wireless LAN> AP Configuration.  Edit the AP-group.  Expand Wireless LAN, Expand Virtual AP, Expand SSID profile under that.   Chose your SSID and go to the Advanced Tab to see the Local Probe Request Threshold parameter.  The parameter is Zero By default.

Thanks cjoseph!  Very good information.  I hadn't thought of limiting the guest SSID to just g.  That is another question I had which was how to help prevent guest traffic from interfering with enterprise traffic - even after we have bandwidth limiting turned on.

I will give these a try.  Again, many thanks!

Jodie

Do we know whether this issue is happening on A band or b/g or both?

If issue is related to RF interference, I would check for

show ap debug client-table ap-name <ap-name on which client is connected>

    Check for Tx retries, SNR

show ap arm rf-summary ap-name <ap-name>

    check for "retry" and "mac-error" fields for channels used by the AP

show ap debug radio stat command mentioned by Zach

show ap monitor ap-list ap-name

    Check for the interferrening APs on the same channel

Make sure your AP is not bootstrapping