Deploying APs over high latency (>100ms) links

[datacore_itg]

After a successful and well received deployment of Ruckus (ZD1100 and 7372s) in our headquarter office, we are considering deploying APs across our worldwide office locations. Ideally management would be through the existing ZD in our US-FL office. Several offices are in the EMEA (Europe) region and one in APAC with average latency of 120-160ms to the EMEA offices and upwards of 200ms to the APAC office. All sites are connected via layer 3 VPN tunnels with sufficient throughput. Each site has local firewall/gateway to the internet (APs will have local internet access).

I've seen several references that <100ms is recommended, but have also seen accounts where successful deployment occurred over much higher latency.  Does anyone have experience deploying over high(ish) latency links and what advice would you give in this scenario?
Thanks!

[dionis_taveras]

DCSW, the ZD is meant mostly for an enterprise deployment in campus or similar.  In order to better scale and expand your deployment, I would highly recommend a virtual SmartZone controller.  This will allow you to have all your offices managed and controlled from a single location, I've successfully managed APs located in Hong Kong from my vSZ cluster located in Florida, US with no issues and with very good accuracy.

Of course, as with any very far away deployment, you have to consider keep alive time outs and may want to increase those a  bit just in case, but it works great with default settings for me.

In addition, you can essentially create what would be an enterprise controller (a zone) for each office, each can contain the same configuration, or can be different, up to how you want to deploy it.  And since you are not tunneling the user traffic back to the controller, you will be using very low overhead on the remotely managed controller.  The SmartZone controls the APs using SSH and not LWAPP which can be more resource heavy and thus potentially cause a bit more of a problem.

However, this is not to say that you can not use the ZD for this deployment, I simply would recommend the vSZ instead for scalability factors as well as ease of management, configuration and maintenance.

Hope this helps.

Regards,

[seanmuir]

You may come across an issue on remote AP's when AP’s are stuck in a provisioning loop.

This can be caused by one of the 2 following issues:

1.       MTU

Solution:

Set the LWAPP MTU to 1250

2.       QoS settings on ZD

ruckus> en
ruckus# config
You have all rights in this mode.
ruckus(config)# system
ruckus(config-sys)# qos
ruckus(config-sys-qos)# show
System QoS:
ToS DATA TUNNEL = 0xA0
ToS CTRL TUNNEL = 0xA0
ToS Classification-Voice = 0xE0 0xC0 0xB8
ToS Classification-Video = 0xA0 0x80
ToS Classification-Data = 0x0
ToS Classification-Background = 0x0
Tx fail threshold = 50
heuristics inter-packet-gap Video = 0  65
heuristicsinter-packet-gap Voice = 15 275
heuristics packet-length Video = 1000  1518
heuristics packet-length Voice = 70 400
heuristics classification Video = 50000
heuristics classification Voice = 600
heuristics no classification Video = 500000
heuristics no classification Voice = 10000

Solution:

The values highlighted need to be set are per the below:

ToS DATA TUNNEL = 0x00
ToS CTRL TUNNEL = 0x00

This can be done using this command:

ruckus# set_qos sys tunnel-tos-val data 0x00 

and

ruckus# set_qos sys tunnel-tos-val ctrl 0x00

It is mainly caused when 3rd party switches can have traffic marked differently and prevent the AP from taking their config.

[datacore_itg]

Thank you for the responses. I wondered if anything could be 'relaxed' in the CLI to allow longer latency between controller and AP so this may help us as we explore this.

Regarding vSZ, if I understand correctly, the vSZ is just a VM (or clustered VMs at one site) which does largely the same thing as a ZoneDirector appliance, no? What makes is better at managing distant APs?
Thanks!

[max_o_driscoll]

Zone creation for each location as Dionis mentioned. So separate configuration for Offices in UK, Ukraine, Bhutan, Malaysia and USA for instance. That way testing and region/country/office specific settings would not impact on each other. Could be quite a life saver. 
Using a ZD it will be much harder to keep each apart without some very creative management.
Just hours of operation (via scheduler) due to time zones will be a headache to sort out.
Just a thought.