Showing results for 
Search instead for 
Did you mean: 

Connect R500 AP to cloud vSZ

New Contributor III
Dear Ruckus users,

I've been working on a vSZ deployment for a while late last year and got it working with a testAP and was very impressed. Now, we've got some projects that will finally utilize our cloud-connected vSZ. However, I cannot seem to get any AP connected anymore. When testing, I did not stick to the rule of documenting everything, so I forgot how I managed to connect an Ruckus AP to our cloudconnected vSZ.

This week I've been searching the net for an answer, but either my AP is bugging out of on me (new R500) or the "guides" are far from complete.

This situation is the following:- vSZ hosted on a vmware platform in the cloud
- vSZ is behind a firewall, but I've opened all necessary ports.
- vSZ was unchanged from our testing period until last night. Last night I decided to upgrade from 3.1.1 to 3.2.1 (patch 3) to try that out.
- AP's are behind a NAT router.
- I've tried firmware versions 9.8.x, 200.x (unleashed, yay!) and 100.1. Currently the AP's are on 100.1

What have i tried:
- Rebooting the vSZ
- Upgrading the vSZ to 3.2.1 to be able to create a GRE tunnel (Ruckus GRE tunnel did not show up in 3.1.1)
- set discovery agent enable
- lwapp2scg > policy accept-all
- DHCP option 43 (which is a bitch on Sonicwall due to Hex config)
- DNS entries for zonedirector.ruckus.local && ruckuscontroller.ruckus.local (if i remember the entry correctly)
- Tried from several different networks
- tried set scg ip     Command is not accepted in 100.1  I remember it working last year, after which I saw the AP showing up on the vSZ shortly after.
- tried set director ip a million times. Until last nights vSZ update it showed the ip (in get director command) as primary, but said the AP was still standalone. After last nights update the AP now shows the following after that command:

 Warning: AP is in ZoneDirector-Managed mode
          Current or latest ZoneDirector: / 00:00:00:00:00:00
          Any configuration changes made in CLI may conflict
          with the ZoneDirector's management and
          will cause undefined results.
rkscli: get director
------ ZoneDirector Info ------
Primary Controller   :
Secondary Controller : n/a
DHCP Opt43 Code      : 3

The information of the most recent Zone Director:
No info

  AP is under management of ZoneDirector: / 00:00:00:00:00:00,
  Currently AP is in state: IMAGE

This morning I set the AP back to factory defaults and started monitoring the network traffic in the firewall, but the packet inspection is kinda basic in the web gui. I could see a lot of DNS requests. After setting the director and rebooting, i saw DNS traffic, LWAPP broadcast in the local domain and after a minute or so i started contacting the vSZ on ports 23233 and after that a lot of FTP traffic back and forth. However, 2 hours later the AP still didn't show up on the vSZ and contacting the AP through SSH still shows the above error.

To me it seems that the AP is clueless where to actually contact the director. I really have no idea any more what to do. I've spent countless hours on troubleshooting this. Anyone who has an idea on how to move forward? Can anyone confirm 100.1.x is even the right SW version for the AP?

EDIT: some of the links i've used:!/4de82f7f008f3cb343977023611036ed552a71ca/page-260569444487667766-how-to-a...

Contributor III
What are the ping results to your vSZ from the AP.

Also can you check the following:
get discovery-agent
If it is disabled you need to enable it:
set discovery-agent enable
You also want to set your NTP server on your AP:
set ntp server
set ntp udate synchronize now
How is your vSZ set up in terms of IP do you have Access and Core separation?

New Contributor III
rkscli: get ntpDevice GMT time   : Fri Aug 12 10:53:57 2016
Active NTP Server :
Backup NTP Server :
NTP Sync Interval : 60 minutes
NTP enabled: yes
rkscli: get discovery-agent
Controller Discovery Agent(LWAPP) is enabled.

I can't ping the vSZ, because of the firewall that sits in front of it. However, the ports are set up like

I do not fully understand the question about access and core.
The way i've configured it now is one network interface with one ip in the local network behind the firewall. The firewall NATs all ports 1:1 on a IPv4 address.

Contributor III
Your network will have management and control IP addresses assigned.

There is an option to split the Core and Access so anything from the Core side uses 1 x GW and anything from Access uses other .

If you dont do this then you need to create static routes between the two of them for the AP's to be able to join as the default GW is usually always the management.

Contributor II
Werme, relax.  This is an easy fix.  Few things, first, it doesn't matter if your firmware is 9.x or 100.x or 3.x, the vSZ with firmware 3.2.1 is able to see all of them and auto convert the AP to 3.2.1 via the LWAPP2SCG process.  To ensure this takes place, you need to enable the script in the back end, AND, you need to open some new ports to get the firmware updated successfully.

Here is what you need to do.

In your firewall, open ports 12223 (UDP) and TCP 21.  This will allow the AP running 100.1 or 9.x to register using LWAPP (which is the older protocol for control between ZD and AP) and download the firmware using port 21 (FTP). 

Next, the AP will upgrade, but only one bank and he needs to upgrade the rest, that process takes place over a new port using HTTPS.  So, on your firewall, open port 11443.  In 3.1, the port is 91, not 11443.  In 3.2.1 we implemented better security for transferring the firmware to the AP via HTTPS..

Third, you need to make sure that the vSZ is able to understand LWAPP and auto upgrade the AP via the built in LWAPP2SCG scripts.  To do this, go in the CLI and verify that it is running by issuing the following command:

show running-config lwapp2scg

A simple, clean and easy config (without passive FTP enabled) should look like this:

 LWAPP2SCG Configuration  


ACL Policy                                                     : Accept all  
Dynamic Data Transmission Port Range     : Not specified
NAT IP Translation in FTP Passive Mode    : No  
ACL APs                                                       :                                            

Send me the output here and I'll let you know if you are good to go or not. 

By default, this script uses passive FTP with ports ranging from 16384-65000.  You can either allow this range via your firewall, or just disable passive FTP mode and allow for only port 21 to be required.  Or, you can change the port range to use via the "config --> lwapp2scg --> pasv-port" commands, issued one by one.

This should take care of your issues. 

New Contributor III
Thanks everyone for the help!

I hope this thread can help others as well, so I'll share the solution that worked in my case.
I was able to resolve it with our distributor and the tip about passive FTP from Dionis.
We configured the passive FTP ports. By default the passive ftp ports are apparently somewhere between 16xxx and 65000 or something, but the firewall didn't allow that. 
We configured the passive ports on the vSZ like this:

vSZ01# show running-config lwapp2scg 

   LWAPP2SCG Configuration   


   ACL Policy                              : Accept all   

   Dynamic Data Transmission Port Range    : Not specified   

   NAT Ip Translation in FTP Passive Mode  : Yes   

   ACL APs                                 :    

vSZ01# config

vSZ01(config)# lwapp2scg 

vSZ01(config-lwapp2scg)# pasv-port 50000 50010

vSZ01(config-lwapp2scg)# exit

Do you want to update this context configuration (or input 'no' to cancel)? [yes/no] yes

vSZ01(config)# exit

vSZ01# show running-config lwapp2scg 

   LWAPP2SCG Configuration   


   ACL Policy                              : Accept all   

   Dynamic Data Transmission Port Range    : 50000-50010   

   NAT Ip Translation in FTP Passive Mode  : Yes   

   ACL APs                                 :    

After that, also configure the firewall rules + NAT.