DHCP/NAT functionality on SZ-managed APs and DPs (data planes) allows customers to reduce costs and complexity by removing the need for DHCP server/NAT router to provide IP addresses to clients. 

Three general DHCP scenarios are supported:

• SMB Single AP: DHCP is running on a single AP only. This AP also functions as the Gateway AP.
• SMB Multiple APs (<12): DHCP service is running on all APs, among which two of the APs will be Gateway APs. These two Gateway APs will provide the IP addresses as well as Internet connectivity to the clients via NAT.
• Enterprise (>12): For Enterprise sites, an additional on-site vSZ-D will be deployed at the remote site which will assume the responsibilities of performing DHCP/NAT functions. Therefore, DHCP/NAT service will not be running on any APs (they will serve clients only), while the DHCP/NAT services are provided by the onsite vSZ-D.

Login to the vSZ and Navigate to Services and Profiles then DHCP & NAT. Locate the domain under the organisation pane, then expand the required domain and highlight the zone you wish to configure your DHCP service. There will be an option to Enable DHCP Service. Enable this, to be directed through a configuration wizard.

Select the appropriate Base Settings. The options are Single AP (1), Multiple APs (<12), or Hierarchal APs (>12). For the purpose of this KB we will only be looking at Single AP or Multiple AP scenarios as Hierarchal will require a data plane. Click Next to continue.

Create a DHCP Pool by clicking on the +. A new page will pop up. Simply enter the required information and click OK. Repeat more networks if necessary. Once done, highlight and move the Pools from Available Pools to Selected Pools and click Next to continue.

On the next page, select your Gateway AP(s). The options are either Automatic or Manual. If you are selecting Manual, you will need to move AP(s) similar to moving the Pool(s) in the previous step and select a Primary and Secondary AP. Click Next to continue.

Review your configuration and click OK to confirm.

Configure your WLANs now as you normally would, however, ensure that under Advanced Options that your Access VLAN is set as per your DHCP profile. 

Perform testing to ensure all is working as expected.

To prevent the two network users from being able to communicate with one another you must now create L3 Access Control profile(s). This will look something like the following:

Action: Block

Source Network Address/Subnet Mask 

Destination Network Address/Subnet Mask

So for example, if we want to block communication between our Private and Guest wireless networks we will need to create two rules and affix these to the respective WLAN.

Block Guest on Private

Action: Block

Source 192.168.66.0/24

Destination 192.168.99.0/24

Block Private on Guest

Action: Block

Source 192.168.99.0/24

Destination 192.168.66.0/24

Navigate to Firewall then L3 Access Control, highlight the appropriate domain then click Create. A new page will pop up. Provide a Name and Description and create a rule by clicking Create. Add a Description, under Access select Block from the drop-down. Enter the Source and Destination Network Address and Subnet Mask. Set the Direction to Dual. Create profiles for any necessary networks.

Apply these to your WLANs by navigating to Wireless LANs, highlight and configure your WLAN, scroll down to Firewall and select the tickbox for Enable WLAN specific. Under the L3 Access Control Policy use the dropdown to select the appropriate profile. Repeat for all necessary WLANs.

Perform testing to ensure all is working as expected.

Notes

Some clients do not roam even if they are physically moved to a new location. Not all clients have roaming aggressiveness setting to fine-tune roaming. Apple devices are reported to cling to the AP they first learn an SSID on.

In a multi-AP environment, a client will always be looking for the best AP to connect to. It will remain connected to its current AP and roam to an adjacent AP once the signal level falls below a certain threshold. This behavior ensures best possible performance at all times.

To achieve this, a client must be doing background scanning to learn about its environment. Frequency of this background scan can determine the roaming behavior. Certain clients such as Windows clients allow roaming aggressiveness to be tweaked. "High" setting will make the client to perform background scanning more often to learn about available APs to connect. While the "Low" setting will make the client do less frequent scanning. This setting can be found under the wireless adapter properties.

Unfortunately, this tweaking is not readily available for all client types. For example, various smartphones and Apple clients do not provide this setting to encourage roaming.

For these types of clients, it is obvious to look towards infrastructure for help. Ruckus has added firmware support to disconnect a client if its signal falls below the user-definable threshold. This feature is called SmartRoam. With this feature, there will be an explicit disassociate message to kick off the client.

This is a per-SSID setting as illustrated above. "smart-roam" parameter takes values from 1 to 10.
These are called roam factors, and they map to an RSSI value in dB as per the list below:

The configuration can be changed from the CLI of the SmartZone.

config
domain "Domain Name"
zone "Zone Name"
wlan "WLAN Name"
roam
roam-factor 2.4g x
roam
roam-factor 5g x

Red writing indicates a value that will be unique to your configuration. Note also that the quotes are required for parameters within a partner domain.

Additionally, if you enable DB Persistence event 209/218 on the vSZ you can see the system logs (events) for roaming activity.

Some clients do not roam even if they are physically moved to a new location. Not all clients have roaming aggressiveness setting to fine-tune roaming. Apple devices are reported to cling to the AP they first learn an SSID on.

In a multi-AP environment, a client will always be looking for the best AP to connect to. It will remain connected to its current AP and roam to an adjacent AP once the signal level falls below a certain threshold. This behavior ensures best possible performance at all times.

To achieve this, a client must be doing background scanning to learn about its environment. Frequency of this background scan can determine the roaming behavior. Certain clients such as Windows clients allow roaming aggressiveness to be tweaked. "High" setting will make the client to perform background scanning more often to learn about available APs to connect. While the "Low" setting will make the client do less frequent scanning. This setting can be found under the wireless adapter properties.

Unfortunately, this tweaking is not readily available for all client types. For example, various smartphones and Apple clients do not provide this setting to encourage roaming.

For these types of clients, it is obvious to look towards infrastructure for help. Ruckus has added firmware support to disconnect a client if its signal falls below the user-definable threshold. This feature is called SmartRoam. With this feature, there will be an explicit disassociate message to kick off the client.

This is a per-SSID setting as illustrated above. "smart-roam" parameter takes values from 1 to 10.
These are called roam factors, and they map to an RSSI value in dB as per the list below:

The configuration can be changed from the CLI of the SmartZone.

config
domain "Domain Name"
zone "Zone Name"
wlan "WLAN Name"
roam
roam-factor 2.4g x
roam
roam-factor 5g x

Red writing indicates a value that will be unique to your configuration. Note also that the quotes are required for parameters within a partner domain.

x Defines the roam factor in the table above i.e. 1-10.

Remember to ensure configuration is saved.

Additionally, if you enable DB Persistence event 209/218 on the vSZ you can see the system logs (events) for roaming activity.