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

  • 1
  • Question
  • Updated 2 months 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 months 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

  • 72 Posts
  • 40 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 Adrian Feudale

Adrian Feudale

  • 5 Posts
  • 0 Reply Likes
Thanks David!

- The two floors are about 7,000 sq feet each and there are 2 x R600's on each floor (floors are separated by another floor in-between not occupied by the client).  

- They are open concept with mostly cubicles + offices with open doors

- One main WLAN and one guest WLAN (which doesn't see much traffic)

- There are a bunch of other neighbouring networks outside the office, generally low RSSI, but I haven't checked on the new v10 firmware (can't find where that module is now!)

- Yes, turned off ChannelFly last week, but no real improvement

- Other things I came across were to turn off automatic power adjustment across all AP's (under Self-Healing) and just let each AP manage it's own power & also turned off client load balancing

- A Ruckus engineer set the Channels to specific ones only last year (i.e. 1,6,11) and I just re-enabled *all* channels again now - not sure if that's ideal or not.

- Rogue detection is set for SSID spoofing, same-network and MAC spoofing only

- 802.11r is off

- Proxy ARP is enabled

- OFDM only is enabled

Will look into those other options (band steering, channel width and BSS minrate) if they still have issues.

Any other things you can suggest?  Or do you think more AP's are needed?

Thanks again!!
(Edited)
Photo of Michael Brado

Michael Brado, Official Rep

  • 3029 Posts
  • 428 Reply Likes
Yes, put your background scanning back to the default 20sec.
Photo of David Black

David Black

  • 72 Posts
  • 40 Reply Likes
I don’t know about going back to 20 seconds... That will really increase channel changes particularly in the 2.4 band. On the 5GHz band there are, thankfully, 802.11h channel switch announcements from the AP so that a client knows what’s about to happen, where to go, and is able to resume its connection with minimal downtime. On the 2.4 band there’s no such thing. From a client’s perspective, the AP just disappeared without warning and the client is abruptly disconnected. Our default setting is 3600 seconds. In high density environments, we go 4-8 times that, and in extreme cases we set static channels. While auto channel can be helpful in dealing with changes in the environment, it can also be a case of the cure being worse than the disease.
(Edited)
Photo of Michael Brado

Michael Brado, Official Rep

  • 3029 Posts
  • 428 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

  • 539 Posts
  • 156 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

  • 72 Posts
  • 40 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

  • 337 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

  • 72 Posts
  • 40 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)