This is part of a series on the RUCKUS line of controllers. To read the introduction and to find other posts in this series, please see the first blog post which can be found here.
What is RUCKUS SmartZone High Scale?
This post could really be considered a Part 2, if you will, of my previous post on RUCKUS SmartZone Essentials. If you haven’t seen that one, you really should go take a look at it and then come back here for the follow up. I’ll have a link from the bottom of that post back to here to make it easier. I cover a lot of ground on the SZ family in that post that I won’t cover here so seriously, if you didn’t read that, go do that now.
For this post, I am going to take a look at the platform that is designed for the Operators, Service Providers, and I will add in, the REALLY large enterprises. The “products” that we are going to look at today fall into that bottom row of the SZ300 and the vSZ-H.
Very similar to the Essentials version, High Scale is just that, higher scale. Also like the Essentials version, the High Scale comes in 2 different platforms to fit your needs, just bigger. The physical appliance, the SZ300, is a two RU appliance with more of pretty much everything. Virtual is the same thing, requiring more CPU and RAM than the smaller scale Essentials/SZ144 platform.
There are some differences in how to manage a High Scale SZ that I will get into later, but for the most part this can be considered just the high end, “Mother of All Controllers”. From a function perspective it’s the same as Essentials so if you are looking for that info, seriously, go back and read that post first!
When to select RUCKUS SmartZone High Scale
As I suggested above, High Scale is really for those folks looking to get some enormous scale out of their network. The other reason to select this platform is for a feature it has called Multi-Tenancy Control which I will get to in a minute.
What is High Scale when we talk about the number of devices and such? Well, it looks something like this.
Just like the Essentials table (SERIOUSLY?!?!? Go back and read it already!) I included the other options as a way to see how the scales match up and when you might need to make the jump up to a larger platform but I want to take a second to address these numbers.
For each box there is the words “up to” included in it, and for a good reason. For this post I will be using a vSZ-H that I have access to as a CommScope RUCKUS employee (the first time I have needed to do this for this series) and you are going to notice that this controller has a grand total of 11 APs joined, but only 4 online right now. There is also 2 switches joined, neither of which are online. You might be asking at this point why the thing even exists, but it’s there for a cool little feature that I am going to talk about in the configuration section. We don’t need it for the device counts, but it will still work just fine with a handful of devices. We need it to work out and experiment with these extra features so that we can try to talk intelligently about what it these extras can do for you.
Also just like with the Essentials platform, I’m not going to go into the set up and installation. That is again too much for here. Read the guides and follow them to get the platform up and running. As far as the APs, they join the same way but for my example here, I am going to use the method where I hardcode the public IP address for the vSZ-H in the Standalone OS (I should do a post on that…) under Administration –> Management and enter the IP address for the controller I want to use.
You didn’t think I was going to actually tell you the address of the controller I am pointing to, did you? I happen to be using an IP address that is a public IP with the other end configured to accept my AP. I could also use a Fully Qualified Domain Name (FQDN) if the subnet your AP is connected to has DNS configured. Again, read the manuals if this is an approach you want to take.
Configuring RUCKUS SmartZone High Scale
The biggest difference that users will see when logging in to a High Scale controller over an Essentials controller is the number of Domains that are seen on the platform.
On the left is the SmartZone 100 view from the Essentials review, and on the right is the view from the vSZ High Scale that I am using for this review. To protect the innocent, I went ahead and blocked out all the names of the myriad of domains that are running on this controller. To better explain, each domain seen on the right is the equivalent of the single domain that is seen on the left. Each Domain will have its own characteristics and configurations, and can be managed and operated as such. Need 20 domains in a central data center so that each region/campus/building can have their own operation separate from the others? Not a problem. I will show you that in a second!
When an AP is pointed at the controller and joins, it will end up in what is known as the Staging Zone which is very similar to the Default Zone in the Essentials platform. In both instances I show that I have already clicked on the green + sign above the System Domain and created Zones in the case of Essentials and my own Domain (JP_Sol) on the High Scale. I have to do this first while my AP is joining the Staging Zone so I have somewhere to move it so I can put it into operation.
Once the AP is online in the Staging Zone (my trusty R750) I can select my AP and then click on Move which will allow me to move it from here into my Domain and whichever Zone I want it in. Within moments of moving it it will be online and operational. If you took the time to build a WLAN (which I demonstrated in the Essentials post) then you are done and ready to go. Do that a twenty thousand more times and you will have something!
I joke. If you have have that many APs, use some of the automated AP joining tools that I talked about in this post here about not having to manually do this for every AP.
Managing RUCKUS SmartZone High Scale
Other than the enormous amount of APs and switches that this thing can scale up to, there is another feature that is a big deal with the High Scale platform that I have talked about, and it has to do with the multiple domains and a feature called “Multi-Tenancy Control” that I have hinted at, but want to demonstrate now. While this High Scale does everything else that the Essentials does, and what I covered in that previous post that I KNOW you have read by now, this is what makes this one special.
Now, as I am sure you have noticed, the High Scale has a lot of other Domains and Zones that I blacked out to only show the small section that was mine. I was able to see all of these because I logged into the platform as a super administrator that had privileges so see EVERYTHING! I can drill into each domain and see APs, configurations, WLANs, security configurations, pretty much anything and everything you expect a normal super administrator to be able to see. But in the case of a massive network (30,000 APs, 6,000 switches, 300,000 client devices) you might want to have some help managing a network that size.
Maybe, when designed, each Domain is really a region or a state or some other large geographical area. If each area has network administrators tasked with running the network for their region, do they really need to have access to someone else’s? Do they even need to know it exists? I’m sure you can come up with reasons that might be advantageous, but for this demonstration, I am going to pretend that I am a smart network guy that wants to run my own network, but I still want to purchase that service from someone else. I run my network (APs and WLANs) but they will manage the platform for me, and I pay them for that service. Let’s call it a Managed Service Provider, or MSP.
There are 2 ways you can do this in a High Scale SZ. This first method allows for another feature to happen that I will discuss later. There is also a second method that I will show but for this first example the MSP administrator will build me a Domain while they are logged into the platform using their super duper extra admin account.
Once my Domain is there, they can then go build me a log in account for just my domain. Located in the main menu on the left under Administration –> Admin and Roles –> Administrators –> + Create. Fill in the fields as needed (the account name will be the username for the login screen) and create a password for this new administrator. Feel free to fill in the rest of the details as needed and hit OK. For the record, since it might be hard to see, the Account Name for this purpose is “jpalmer” and this is the username I will use to log in to my scaled down account.
Next we need to assign this new user to a group so they have something to log in to. There is a pop up warning telling you this so do it next. From the Administrators window click the tab to the left which is Groups. Click Create and build a user that is only allowed to access their domain. There is a wizard of sorts that will walk you through this process so don’t be afraid to experiment. Domain assignment comes in the middle step and then in the Administrators step the user that you just created can be linked to their domain.
For this example, I created a user group named “Jim Palmer” that is assigned to my domain of “JP_Sol” using the username of “jpalmer” as seen below.
After the MSP administrator has done this, they can send me my new credentials and I am allowed to log in the controller.
The first thing to notice is the lack of the other domains on the left side. I can see my domain and the staging zone, but nothing else. Checking the upper right hand corner you will see that it is still the same platform but instead of the Admin account from before, it’s now my own personal username built in the previous steps. I still have access to all of the other tools and resources and capabilities, but I only know about other potential users because of the common Staging Zone for new APs. I can’t tell how many other APs there are or anything. The same goes for the WLANs and clients. It’s like I have my very own personal SZ, but the provider only has to manage one platform, not one platform for every customer of theirs.
Everything else that I talked about with Essentials is also available so I’m not going to cover that again, just know that it is there. It is a converged network controller so managing APs, WLANs, clients, and switches is all in there, just as before. In fact, while logged in under my single user account, sometimes I forget that I’m on the larger platform since it’s so similar to the Essentials. For users that might get overwhelmed, this is a good way to break them in slowly to the “Mother of All Controllers”!
Now for the second way to provide this type of access but first, a warning.
What I am about to show you can’t exist on the same platform as the feature that I discuss in the Advanced section that follows. Don’t ask me why, I don’t know, and digging into would require more effort than I care to exert on this. Remember, “Less than Complete” is in the title of all of these reviews.
The other way to create a “standalone” domain, if you will, is when you create the domain itself and it is known as a “Partner Domain”. Similar to a standard domain, but flagged during creation so that everyone that might see it has a visual indicator that this is indeed managed by someone else.
Click on the Access Points and then System and then the green + above it to add the domain. Except this time, toggle the line that says “Managed by Partner” before clicking OK. the result is a new domain, as seen on the right, but with a new icon. When looking at all the domains, that white icon is hard to miss, immediately telling anyone that there is something else going on.
After building the Partner Domain, the next step is getting some credentials for it so the “partner” can use it. The way the platform handles this is a little different, so I want to show it to you first.
What you should notice on the right here is in the Administration –> Admin and Roles. When looking at both Groups and Administrators, notice a difference in how they are displayed. Before, there was just the system, now we see that partner domain. While System shows there are 3 different accounts created for the system, the new partner domain doesn’t show any account. The administrative tasks for partners domains are split out and need to be created separately.
Creating the administrators and groups is identical from the previous steps, but just done under the partner domain.
When this user is created, I learned the hard way that to log in using the credentials for this new partner domain, the user name is the Name, as seen above, combined with the Domain, also seen above, using the @ sign. Therefore, when I logged into my new shiny Partner domain, the username was “jpalmer_partner@JP_Partner” and then my password. Don’t be me and give your partners terrible usernames. Or do it, what do I know?
Anyways, the resulting log in screen is very similar as what we saw in the previous step where we created a domain account for a single domain, this is the same type of view, but for the partner domain.
Just as before, the same controller, but with my unique, very long username. Also, I can see the Staging Zone in additional to my domain. The biggest difference between the 2 methods, at least as I see it, boils down to 2 things:
- How the credentials are managed and
- Partner Domains can’t exist on the same controller as MVNO accounts.
Don’t know what an MVNO account is, or not even sure what MVNO is, don’t worry, neither did I.
Advanced RUCKUS SmartZone High Scale
SZ High Scale has all of the advanced features that I talked about in Essentials. Services & Profiles with Hotspot 2.0, Wi-Fi Calling, AAA, WIPS, Bonjour, and Tunnels to name a few. Troubleshooting is still here with Spectrum Analysis and Client Connection tools. Added in is some additional tunneling troubleshooting tools that advanced users will find handy.
Something else that the High Scale edition has over the Essentials is a feature called “Mobile Virtual Network Operator” or MVNO. Funny story about MVNO that I want to tell in the spirit of full disclosure. I asked my team about any features or things I should make sure I call out about the High Scale platform that made it unique, beyond what I have already covered. This first response I got was “MVNO”. They said MVNO to me so many times I had to stop them and say “you do realize I have no idea what means” and the response was this is something that many folks forget or it gets overlooked easily so I’m glad they brought it up. I’m also glad I already covered the Multi-Tenancy Control with creating domain logins because this is similar to that, but even more granular.
Also, this is where that warning from earlier comes in. Partner Domains and MVNO accounts CAN’T exist on the same box at the same time. Ask me how much time I spent figuring that one out! Again, no idea why, it’s just the case. If you find that an MVNO model might be how you want to go, you can’t use partner domains on the same box. Use the first method to assign domain control and don’t use partner domains. It will let you get all the way through the process and then kick it back and give you an error. Again, ask me how I know…
As best I can work out, a common use case I could see for MVNO (at least today with most shopping malls going the way of the dinosaur) is an office building with multiple tenants. Today, that usually means each tenant get’s their own Internet service and fire up their ISP provider router and going to town. The result is an RF nightmare. A reason most tenants give for not wanting to cooperate with a single infrastructure is not wanting to “share” their network with their neighbors. Most assume, incorrectly, that having their own channel means they get better RF performance. While that might true if they happen to be on their own channel, we know that usually isn’t the case.
The other reason is they want to administer their own WLAN. They don’t want anyone else configuring their SSID, setting their passwords, setting up AAA and other security related things. RUCKUS gets this and that is where the MVNO account comes in. An MVNO account on a vSZ-H, as we are going to see here in a second, give the tenant their own log in to the SmartZone, but they can only control their WLANs based on the APs the building administrator gives them access to. They run their own SSID and all the related settings, and the SZ Super Admin can’t see ANYTHING about their SSID! The building administrator runs the infrastructure (AP channels and switch stuff) while the tenant runs their own “network”.
Located under Administration in the left hand menu, below the Admin and Roles entry (which are used to create accounts for individual domains), is where the MVNO section lives. While I called this section the Advanced section, what makes High Scale really unique is the scale, and then what is located here in the Administration section with the different functionalities built in to this platform that allows for multiple ways in which to manage it. Maybe I should have called this section “Advanced Administration” instead.
Of importance here is the Domain Name at the beginning and the Administrator Account Name at the end. Together these make up the username the MVNO administrator will use when they log. This middle section here is where the magic happens. This is where the super administrators assigned the zones in which this particular user will have control over, as well as the WLANs. What makes this set up so unique is the granularity of control this method offers the owner of the platform.
In this example, the “super administrator” of this configuration is assigned the Account Name of “admin” and the Domain Name of “mvnodemo_2”. They are also assigned the Zone of “MVNO Demo 2” and the WLAN that was created for them of “MVNO Demo 2-2”. This is all important and I will show you why.
When the end user browses to the given URL of the High Scale SmartZone and use their assigned to credentials to log in, they need to combine the Account and Domain name with their given password on the WebUI log in screen.
For this demo the username entered will be “admin@mvnodemo_2”. There isn’t a need for a “dot com” or “dot org” or whatever email address that the user enters, the domain is defined in the user creation stage, and the account name becomes the first half of the username. This tells the SZ that the user logging in is using that MVNO domain, and they are logging in under that account created for them. What comes next is pretty cool actually.
Just as with the domain account we looked at earlier, the user is listed as Admin on a High Scale SmartZone. The menu still exists on the left side, but notice what is missing. Nothing about switches, only a single domain, and more importantly, a single zone with a single WLAN. Also notice the lack of the ability to create additional WLANs (that allows the main administrator to keep the number of WLANs per channel down). Where it gets even more interesting is when this is compared to what is really happening here compared to the “unfiltered” view.
The Domain really isn’t called “mvnodemo_2” although you might recognize that from the domain part of username that was used to log in. There are multiple WLAN Groups (WG) under that Zone, but remember in the settings we limited the user to just that one zone and just that one WLAN. There is always the option to expand that user to allow them more access but I limited it to show the effect of the tool.
By changing the username when logging in from “admin@mvnodemo_2” to “admin@mvnodemo” the user will see something totally different.
Notice everything looks very similar except this time, the user is seeing only the Zone and WLAN for MVNO Demo 1 and MVNO Demo 1-1. Neither of the administrators know about each other, neither can control or impact each other, but each network still gets to use the power and features of a top of the line WLAN controller.
I do need to add in some warnings and reminders here though.
- Once the MVNO administrator takes control of their assigned WLAN’s, the super administrators (the one running the APs and switches) are completely locked out. If they forget their credentials, everything has to blown away and recreated.
- MVNO accounts and Partner Domains CAN’T exist on the same SZ at the same time. If granular control over specific WLANs is what you are after, then you can’t have Partner Domains even hinted at. If any, and I mean ANY, MVNO account exists on the SZ, then the creation of the Partner Domain will fail, but only at the end.
- Seeing as this is the “Less than Complete” I don’t know any of the other little gotchas that might exist with Partner Domains or MVNO accounts or whatever. If I did miss something, leave me a comment at the end and we will make sure we have a good warning for others.
RUCKUS SmartZone High Scale Final Thoughts
Of all the RUCKUS platforms, this has been the hardest review to write. This is the one that over a year ago scared me the most, simply because of the different approach to controlling networks and its capability. When this approach and the DataPlane that is coming next is combined, it really allows a network administrator to change their entire approach to managing networks.
I also don’t think this idea is for everyone. I don’t see the average network operator reading this and thinking “Egads! This is what I have been missing in my life!” The scale maybe, but maybe not all these advanced administration capabilities. I can’t even imagine trying to manage a large cluster of High Scale SZ controllers, or even multiple clusters. I think I could do it given some time to wrap my head around it, but still, that is a lot going on there!
The other thing I like about the SmartZone platform in general is the idea that the controller that I get for redundancy can also be used to increase the capacity of the system.
At this point I have reached the end of the controllers I wanted to talk about. I did find out that there is a ZoneDirector that I can experiment with I have to tell you that after 18 months of being a CommScope RUCKUS employee I have yet to ever need to work on one. But, for you, I will take that on and give you my thoughts. What I can tell you is that at first glance, this isn’t even the same ZoneDirector that I was first introduced to all those years ago.