ZD1200 and 4 x R600 AP's - frequent disconnects and complaints.

  • 1
  • Question
  • Updated 2 weeks ago
  • Acknowledged
We have a client with a ZD1200 and 4 x R600 AP's.  2 x R600's on each of two floors.

Latest firmware on ZD and AP's with a Ruckus support subscription.

The ISP is 1Gbps Fibre.  It is a private company with about 150 users connected every day.  Most of them are stationary and not too many visitors jumping on the WiFi.

There have been complaints recently about poor performance, disconnects, etc.

Have looked at various things such as channel changes, background scanning, channel fly, power output, etc. but nothing has really resolved it.

The activity logs show up clean.

Where is the best place to start to diagnose & resolve this issue?

Many thanks in advance!
Photo of Adrian Feudale

Adrian Feudale

  • 5 Posts
  • 0 Reply Likes

Posted 2 weeks ago

  • 1
Photo of Alan Daniel Chavira

Alan Daniel Chavira

  • 6 Posts
  • 1 Reply Like
Deactivate Channelfly, it's works for me
Photo of Adrian Feudale

Adrian Feudale

  • 2 Posts
  • 0 Reply Likes
Thanks for the fast reply Alan!  Yes, that was one of the first things I did - went from Channel Fly to Background Scanning with a scan time of about 3 hours.  I tried a shorter timeframe first, but I believe it made it worse.
Photo of David Black

David Black

  • 66 Posts
  • 37 Reply Likes
I can't say for sure until we know
- the size and general description of the floors (mostly cubes, mostly offices, etc),
- number of WLANs in the air
- number of neighboring networks and the RSSI levels. 
With 75 users/floor, the floors are probably 10-15,000, maybe more.  If so, you don't have enough APs and transmit power is probably too hot. 
I agree with Alan - never use Channel Fly.  Other things to try:
OFDM only
BSS minrate to 12
Enable proxy arp
Disable 802.11r
Disable rogue detection (unless you really use monitor it and use it)
Keep the number of WLANs as low as possible (2-3) 
Channel width 20 on 2.4 and auto on 5
Possibly consider enabling band steering
(Edited)
Photo of Michael Brado

Michael Brado, Official Rep

  • 2955 Posts
  • 414 Reply Likes
ACK, all RF environments vary, and "your mileage may vary".  I'm glad you understand your feature setting effects!
Photo of John D

John D, AlphaDog

  • 529 Posts
  • 151 Reply Likes
Note that 20s per background scan is not saying 20s per channel switch in Background Scanning mode...

The seconds per scan is the amount of time between the AP taking a radio off-channel to sample a different channel for a split second. Background scanning is scanning one channel at a time every 20s by default. On 2.4GHz there's 3 channels that background scanning cares about (1, 6, and 11) so every minute or so it would build up a sample of each channel, but on 5GHz there are 25 channels. If you set background scanning interval to 3 hours that's 3 days to scan all of 5GHz for a single data point... Background Scanning is just going to make ill-informed channel decisions.

The general reason for increasing the background scanning interval is to serve extreme high capacity environments (where you can't afford the minuscule capacity loss during the time the radio goes off-channel to scan) or VOIP (where the brief period of scan time means dropped/garbled audio). If you plan on letting background scanning automatically set channels, I'd go with what Michael said -- set background scanning to 20s or 30s, not longer. Background scans themselves do not cause clients to disconnect.


To rule out the effect of channel changes I would suggest using a fully manually assigned channel plan for now. 
Photo of Adrian Feudale

Adrian Feudale

  • 5 Posts
  • 0 Reply Likes
Thanks John!  That's what I gathered from reading the docs as well - 20s is not the channel change interval, but just how often it scans the environment.  If we went with a manually assigned channel plan, how would you suggest determining the channels?
Photo of David Black

David Black

  • 66 Posts
  • 37 Reply Likes
With only 2 APs per floor, and 2 non-contiguous floors, you're mostly concerned about neighboring networks.  You can sometimes get lucky doing 2 tests with free tools.  Test #1 - using an analyzer, stand near the first AP and see what's in the air.  Sort the list by RSSI, hottest at the top, and study the display for a few minutes and see if one channel looks better than the others.  There will be a lot of fluctuations and there will be no clear winner; just pick the one that's not quite as hot as the other two.  The networks will come and go and shift around depending on the tool you're using and it's ability to deal with stuck beacons.  Test #2 - sort by channel and count number of APs on each channel (ignore APs that are weaker than -80).  For example, suppose channel 1 had only one AP but it was at -60dBm, channel 6 had 3 APs at -65, and channel 11 had 7 APs at -72.  Assuming that the volume of traffic is roughly the same on all the neighboring APs, a good choice might be channel 1.  Although it is the strongest interferer signal strength wise, your'e only sharing the channel with that one other AP.  If you pick channel 11, the weakest RSSI, then you share the airtime with 7 other APs.  Compare the results of the two tests.  There will not be a perfect answer, just pick the channel with the fewest APs and hopefully the weakest RSSIs.  Then go to the next AP and do the same except do not re use whatever you picked for the first AP.  The problem with this free-tool approach is that you're not measuring the volume of traffic on each channel.  On the above example, suppose the one AP on channel 1 is super busy and the 7 APs on channel 11 are used very lightly.  Then a better choice might be 11.  Unless you have a tool that can analyze traffic, you may need to experiment by running a week on your first choice and then try your second choice.  If you need an analyzer to see the APs, channels, and RSSI levels, you can use WiFi Analyzer if you have an Android phone, or Metageek InSSIDer on a laptop.  If you want something that will also analyze traffic, then that will cost some money.  I use AirMagnet WiFi Analyzer, Metageek EyePA, and Metageek Chanalyzer. 
(Edited)
Photo of Adrian Feudale

Adrian Feudale

  • 5 Posts
  • 0 Reply Likes
Whoa! Thanks David!  Now that is some great info I can use!  Fantastic! :)
Photo of Jeronimo

Jeronimo

  • 335 Posts
  • 40 Reply Likes
Could you share support_log of one of APs?

If not permmit, confirm number of deauth packet on support log.

If there are many packet about deauth, nearby it may wips.

And  check airtime using get airtime wifi0 / get airtime wifi1.

If high, Something might be causing the interference such as wips, bluetooth, many neighbor APs and so on.

In my experience, wips was one of the causes of high airtime even without many deauth packet.




Photo of David Black

David Black

  • 66 Posts
  • 37 Reply Likes
Jeronimo is right.  There is a lot of good info the AP support logs.  Seach for "athstats" and check the histograms for PHY errors and airtime stats.  Also search for "stuck beacon" and see how frequently those occur.

As for background scanning interval...  It's correct that channel changes do not occur every 20 seconds or whatever the scan interval is, and that the off channel scans don't cause disconnects, but channel changes in the 2.4 band cause problems.  Depending on the enviornment, setting to 20 seconds will cause channel changes as often as every few minutes which contributes to the chaos that never ever stops. Setting static channels is almost always the best answer. In the 5GHz band, channel changes generally aren’t an issue as long as clients support CSA (which almost all do nowadays). 
 


(Edited)