nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

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

unknown

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!

Find more posts tagged with

Accepted answers

All comments

unknown

Deactivate Channelfly, it's works for me

unknown

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.

david_black_594

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

unknown

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!!

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.

unknown

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.

david_black_594

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).