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; } } }

Hosting solution

unknown

Hi !

We are a MSP company that have customers with all from 1 - 300 users.
We want to build a Wlan Hosting/Carrier solution where we have a vscg in our datacenter and and manage accesspoints at multiple customers from this central controller.

I want to be able to stage the accesspoints at our office and make them 100% done so we then just need to physically mount them at the customer.

I want that all AP ́s that I stage or put in a zone would get the external dns adress to our vscg so that I dont need to ssh to every AP and put it in manually.

Is this possible ?

An other question, the list of ports that the guide tells you to open is pretty long, which are the most important for basic ap-controller communication no radius and stuff ?

Thanks in advance!

/Henrik

Find more posts tagged with

Accepted answers

All comments

dionis_taveras

Hello Henrik and welcome to the Ruckus forum.

This is certainly possible and something that is being used today by other carriers.

Assuming you control and own the DNS server which these APs would look to in order to resolve DNS queries. If this is the case, all you have to do is set an A record in your DNS server to resolve the word "RuckusController" to the IP of the controller itself you want the APs to reach.

The APs will query your DNS server for RuckusController.domain.com (domain.com being your dns suffix or domain) and get the IP from your DNS server. They will then attempt to register to that controller directly.

At that point, you need at least the following ports:

TCP ports:

Port 21 = FTP Com port

Port range 16384-65000 (configurable in vSCG) = FTP Passive port range

Port 443 = https port for AP to vSCG Registration

Port 22 = SSH Tunnel from AP to SCG

Port 91 = AP and vSCG firmware update and other uses port

Optional TCP Ports:

Port 8443 = Used for vSCG WebUI access from remote (if needed, this may not be necessary if you are using a 3 interface configuration and using VPN to connect to management interface)

Port 7443 = Port used by SWIPE (not required if you are not using SWIPE to provision APs onsite)

UDP Ports:

Port 12223 = LWAP communication port for APs not running vSCG firmware to communicate with vSCG and get upgraded (using passive FTP ports mentioned above)

Hope this helps.

Regards,

unknown

Hi !

This looks greate ! Thanks alot for a quick and good answer!
I will try this !

unknown

Hi Alpha,

I thought you had to use a special DHCP option code 43 to point the AP's to the vSCG. Not just a DNS entry. Assuming all on same LAN as vSCG. Once complete you can move it to another LAN, i.e remote site

As out the box the AP's will not be in a managed mode and on wrong firmware. You have to issue a SSH command. to set the vSCG or Director server IP

As your method is same as Ubiquiti, except that points to A record for the "unifi" name.

So like the sound of that.

Richy

dionis_taveras

Richy, not at all.

DHCP Option 43 is one of multiple ways to get an AP to discover the controller address when talking about the vSCG (now called vSZ). You can of course use that, however, for the problem at hand in this case, it would not be a suitable solution since DHCP may not be something that he can control or configure.

The AP will get DNS servers via DHCP and then attempt to resolve RuckusController and obtain the controller IP this way.

You are correct on APs potentially having different firmware or incompatible firmware with the vSCG, this is why I recommended that ports 12223 and 21 as well as the passive FTP port range be open. This will ensure that any AP, regardless of firmware version from Ruckus (ZoneDirector or SCG, or 9.x or 2/3.x) can still be discovered and auto upgraded to the correct version of firmware. The vSCG will do this automatically for you.

Henrik, one thing I forgot to mention, if you are APs are in an older version of firmware, you will need to enable the LWAPPtoSCG built in tool. You can do this at setup, or after setup.

Here are the commands to enable it once setup is complete or for an already running version. Otherwise, you can do it during setup by simply selecting to auto upgrade APs running zonedirector code.

configure

lwapp2scg

policy accept-all

Regards,

D

unknown

Hi

Thanks for the information and the tips !

I now have a working AP that is on a different subnet than it was staged on and it works as intended.

Greate forum !

/Henrik

eizens_putnins

Hello,
This is really solution you want to use. Works perfectly, can't compare with anything from other vendors at all.
Want to comment, that there is no actually much difference between using DHCP option or DNS - in both cases you have to use controlled environment, because if DHCP gives ISP (or for example google 8.8.8.8 DNS), creating A record on your DNS will do nothing for you. Anyway, any service provider normally has own DHCP/DNS infrastructure, so probably you configure both...
Also I had experience that AP delivered with some versions of firmware failed to upgrade to vSCG firmware and connect even after setting vSCG IP. In this case manual upgrade to any vSCG firmware version was needed. Another (automated) workaround is to connect this APs to ZD with recent firmware for auto-upgrade to 9.9 or up and than factory reset and connect them to vSCG for discovery using DHCP or DNS, this worked for me 100%.
Anyway, for small amount of APs just using SSH to set vSCG IP is foolproof method, and you can make batch file for it (using multiple IPs to configure multiple APs) if you like.
Additional comment -- don't enable mesh for AP profile in staging zone, otherwise you will be unable to move it to any other zone until disabling mesh, and you don't want it.
Hope this helps.
Eizens

dionis_taveras

To start, I really like this forum, all the answers are just great and participation is awesome. Thanks all for contributing.

To Eizen,

You have some very valid points here. However, for the question at hand, he is staging this at his office and doesn't want to ssh to the AP and provision them.

In his case, DNS makes sense and it's easy enough to not have to worry about DHCP option 43 and sub options (3 and 6) which could be more complex based on which DHCP server is being used.

The DNS method, combined with the autoupgrade mechanism embedded on the vSCG from factory in versions 2.5 and newer, allows him to put any AP, from any version of code (including those of ZD 9.x and new universal code for all APs which starts at 100.x) into the SCG automatically. I can help with how to make this automatic process work if needed, but it is there and ready to be used 🙂

New APs never come with mesh enabled by default, so no worries there either.

Now, on a side note, as a managed service provider, it would be easier for them to have DHCP configured on the routers onsite with a template configuration for AP management IPs and provide a DNS that, may be, centralized behind their datacenter where an A record is then configured for it or local at the customer premise or somewhere else.

This means, that they don't have to even pre-stage the APs, they could even go as far as creating rules based on AP management subnets and have the APs auto-move to the zone they want the AP to be based on the subnet they used for management IPs at this customer location, regardless of who the ISP is. The APs are behind NAT and the router/gateway/firewall is providing the AP with the DNS server they should use which could be anything the MSP chooses it to be. We have provisioning rules embedded into the vSCG that allows for very advanced automation of AP provisioning.

There are many methods to making the AP provisioning automatic and making so that you don't have to touch them or worry about what firmware they use out of the box.

We have made this process very easy for our customers 🙂

Or for people like Eizen and I who like to do things the old fashion way for quick tasks, you can use plain old ssh on a shell script with an ftp server and upgrade them using some sort of staging process, up to you 🙂 (I am part of this team for small deployments, but part of the automated process for MSP/ISP and large or many small re-occurring common day to day deployments)

Cheers!