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

[adrian_feudale]

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!

[michael_brado]

Yes, put your background scanning back to the default 20sec.

[david_black_594]

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.

[michael_brado]

ACK, all RF environments vary, and "your mileage may vary".  I'm glad you understand your feature setting effects!

[john_d]

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. 

[adrian_feudale]

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?