Showing results for 
Search instead for 
Did you mean: 

Best Practice configs for a High Density Deployment?

Contributor III
When using Ruckus APs in a High Density enviroment, some clients refuse to roam when they should and others roam excessively.

What (if anything) would be better than the following config for avoiding roaming issues in a high AP density environment?
..assuming a non-encrypted guest network...

Create 2 WLANs:

wlan public50
ssid public50
description "public 5Ghz SSID"
no band-balancing
no load-balancing
vlan 111
bss-minrate 24
smart-roam 2

wlan public24
ssid public24
description "public 2.4Ghz SSID"
vlan 111
no band-balancing
no load-balancing
bss-minrate 12
smart-roam 1

Create 2 WLAN groups:

wlan-group public24
wlan public24

wlan-group public50
wlan public50

Then assign the WLAN groups to the appropriate radio of each AP.


1) Turn off band-balancing a.k.a. band-steering to prevent an AP from accidentially pushing a 2.4Ghz client to a further-away 2.4Ghz radio instead of the intended local 5Ghz radio.

2) set ofdm-only to prevent old "B-only" clients from dropping the AP to "B-only" mode.

3) set bss-minrate to prevent clients from going to lower speeds. (and encourage them to roam to a nearer AP on their own)

4) set smart-roam (not recommended by Ruckus?) to kick clients off an AP when the AP sees a very poor signal from the client. (and "force" a client to roam)

5) Use different SSIDs for the 2.4Ghz radios vs the 5Ghz radios.
Even though I've already turned off band-steering and load-balancing, the clients may still decide to jump back+forth between 2.4Ghz and 5Ghz radios.
Using a different SSID for each band makes a client less likely to decide to roam between bands.

This still leaves the possibility for 2.4Ghz clients to decide to excessively jump between 2.4Ghz radios.
If you need a way to prevent that kind of roaming, you could take the additional step of assigning a unique SSID/WLAN to each radio on each AP.

If your environment doesn't suffer from excessive roaming, you can add a single "public" SSID that exists on all radios.
End users would then be able to choose the SSID that works best for them.

If anyone has a better solution, please let me know.

Contributor III
I syslog to a linux machine to store logs that I can check for roaming and other problems.
Max O'Driscoll posted good information about syslogging to an external windows server:

In case people have questions about smartroam, I'd suggest checking out this link:

smartroam factors + equivalent db/signal-percentages:
kick-off a client when the dB value is below:
1 5db/ 2%?
2 10db/12%
3 15db/25%
4 17db/30%
5 20db/37%
6 23db/45%
7 27db/54%
8 32db/67%
9 40db/87%
10 60db/99%
These are the dB/signal-percentages you see under the monitor tab when looking at clients.

The "Best practices deployment guide" could be good to know about:

Contributor III
RE: Entering configs via the CLI:
The commands in the initial post can be entered via the ZoneDirector CLI.

To access the CLI, SSH to the IP address of your ZD.

If you don't have an SSH client already, download putty:

To get into configuration mode see the example on page 34 of the CLI User Guide:
(hint: type the word "config")