Edited on 23 Feb 2021 to add backwards compatibility and AP Batch Provisioning.
Ever since joining CommScope RUCKUS 15 months ago I feel like I have been drinking through a fire hose. There has been so much to learn, and so much to re-learn. After spending so much time doing things one way, you either forget there is a different way, or don’t even realize there is a different way. What you are going to read next falls into the category of didn’t realize there was another way. This other way is the idea that I could run multiple generations of APs on the same controller, at the same time, and they would all work, and they would all work great!
Sound like something interesting and that you would like to be able to do? Stick with me while I walk you through the steps.
Before joining CommScope RUCKUS I had taken some Wi-Fi classes and the instructors talking non-stop about the RUCKUS products so I wanted to get my hands on some gear just so I could figure out WHY these instructors were so smitten with using them. Given the chance I acquired a well -used ZoneDirector 1100 (ZD1100) and some ZoneFlex 7982 APs. Unfortunately, the ZD1100 had some problems and without a controller I didn’t think there was any reason to even try to mess with the APs. I know better now but that’s a whole different series of posts that I will finish eventually.
After joining the company my inventory of RUCKUS APs expanded to include an R610 (802.11ac Wave 2) and then an R750 (802.11ax) in order to test drive and experiment with. In my thinking, this was really a lot of work. I now had APs that covered 802.11n/ac/ax (or Wi-Fi 4 through 6) and the idea of trying to figure out code versions and all that mess that would work for all 3 generations of APs sounded daunting and no fun. It was about this time that I also received a SmartZone 104 (SZ104) controller for another project I was working on. The resulting list of hardware I had to work with was this:
- Controller = SmartZone 104 (SZ104) Appliance
- AP – ZF7982 – 802.11n, 3×3:3
- AP – R610 – 802.11ac Wave 2, 3×3:3
- AP – R750 – 802.11ax, 4×4:4
- One overworked blogger who has a little bit of a lazy streak tucked in there somewhere
As any Wi-Fi engineer knows, all of this equipment runs on versions of code, to include the overworked blogger. The key is to find a version that code that works across the entire lot. Given that the blogger runs on coffee and bitterness and that doesn’t work for the rest of the list, I had my work cut out for me.
It what became a crucial step in my process was the realization that the SZ100 controller I had in my lab was shipped to me with code version 18.104.22.168.759. This is important to the end goal, so don’t ever discount older versions of code, especially if you want to run multiple versions of code on the same controller. You see, that version of code on the SmartZone platform is the version of code needed for 802.11n APs, like the stack of ZF7982’s I had sitting on the floor. Since I also wanted to run my shiny new R750 on this as well, I did need newer code on the SZ as well. What followed was a day of code upgrades that followed this progression, and the progression is key so don’t skip this.
22.214.171.124.759 –> 126.96.36.199.595 –> 188.8.131.52.698 –> 184.108.40.206.1038
This set up is critical because in the SmartZone (SZ) Operating System it holds each firmware as you upgrade and makes it available for use on the system. If your goal is to run multiple generations of APs on a single controller at the same time, you are going to need multiple versions of code. The secret is to make sure that each version of AP you want to run is supported by one of the versions of code in your progression chain AND that each progression is supported as a valid upgrade path. Skipping versions of code when updating any IT systems and not following the recommended upgrade path can result in numerous problems, so don’t ever do that!
Now, if you are already running 5.2.1 and you realize that there are APs you need to support that won’t work on newer firmware and you need to use older code (like a coworker recently discovered) don’t despair. I didn’t know this would work until yesterday (22 Feb 2021) which is why it wasn’t originally included. Included with each major firmware release there are AP patches versions that can be added to a SmartZone for previous code! Simply find the AP patch version that supports the older APs in question, add it to the controller, and then build a zone as is described next. At this point I don’t know if the engineers could make it more flexible for customers if they tried. Who know, maybe we should challenge them with some scenarios I haven’t thought of!
It’s great that we now have 4 versions of code available on the SZ, but what do we do with it? If you have experience on the SZ OS, you can probably skip ahead a paragraph or two. If you didn’t know about the SmartZone OS, the next 2 paragraphs contain an incredibly simplified explanation that might only be slightly correct.
SmartZone comes in 2 flavors really; a High Scale and an Essentials version. Both are available as either a physical appliance or as a virtual platform that can be hosted locally in your data center or in Public Cloud. They essentially operate the same way but with a couple of MAJOR differences. Essentials is really for the single organization that only needs really big scaling and single team administration. High-Scale is meant for massively large scope and scale where multi-tenant administration is needed. The other big difference is in how the multi-tenant administration is handled.
In the “smaller” Essentials controller platform, like the SZ100 appliance I have, there is but one “Domain” that all the APs and WLANs live under, broken up into what is known as “Zones” and then within the Zones are “AP Groups”. In the larger High-Scale platform, there are multiple Domains that are then broken down the same way. What makes the High Scale platform multi-tenant is that credentials and administration can be divided up between the Domains. While a system administrator can see everything (maybe?) within all the domains, a domain administrator can only see, and only knows about, their individual domain. They have no access or visibility into other domains and therefor can’t make any changes. You can click here for a more in depth look at the SmartZone written by someone who knows more than I do. While the approach I’m about to explain will work for either platform, what you are going to see is only for a single domain. Back to the original program!
Now that we have the code, we need to build the Zones for our different models of APs. Building a new zone is quite simple, really. From the main menu bar on the left, select “Access Points –> Access Points” then click on the domain, and then click the green plus just above that. Since this is an Essentials version, Zone is already selected. Give it a name and then in the first configuration step, hit the drop down and assign it one of the versions of firmware that you upgraded the SZ through during the set up. There is a lot of other things to configure within the Zone but the critical piece is that AP firmware selection in the first option. Repeat these steps for the other zones you need to create, selecting the firmware needed for each model of AP. In the end you should have a Zone created for each model of AP you want to run, and each of those zones must have firmware that supports your APs in question.
The next step in the process is getting the APs to actually associate to the controller. Since the controller is running multiple versions of code, the AP attempting to join needs to see a version of code it likes, or the join process stops. My original attempt at this is a 2 part step and requires work on both the controller and the DHCP server for your network. After publishing this, I was informed there is indeed another way, and depending on the scenario, might be even easier. Read all the way through, and then decide which method works best for you.
METHOD 1: First up is the controller configuration since we are already here. Select “System –> AP Settings –> AP Registration –> Create.” This allows you to create rules that will automatically assign APs to the proper Zone created earlier based on the APs given IP address. Word of caution here; if an 802.11n AP ends up with an IP address in the registration rule for a newer AP zone, it will never join the controller since it doesn’t support the firmware for that zone! You resulting rules should look a little something like this:
The last step is to create some configurations on your DHCP server that will ensure that your APs are assigned the proper IP address in the proper IP range so they get assigned to the proper zone on the controller. While this is a little bit of a leg work to make this happen, it’s certainly simpler and cheaper than needing a whole separate controller to keep some older APs running for a while longer. Organizations always have those weird, one-off locations that while they need Wi-Fi coverage, they don’t need it so much they make the cut for purchasing new AP’s. Wi-Fi professionals always brag that some areas are served perfectly fine with 11n APs, it’s just always been such a pain to keep them running from a controller perspective that they are usually yanked out and sent to e-waste, making us all cry.
This step, while simple, takes time. Most modern DHCP servers, even ISP provided routers for your home network, provide a method in which a given MAC address of a device can be reserved a specific IP address. If your network configurations don’t allow for a whole subnet just to run a handful of IPs (but it might) the reserved IP address is the way to go. Enter the MAC address of the AP in question, assign it an IP address that fits in the IP address range configured on the SZ in the last step, and click save.
METHOD 2: As I indicated, after publishing this blog I was informed there is another method to accomplish this same task. It’s built in to the SmartZone and is really handy if you happen to know the MAC address of the APs in question, like an inventory report or something like that. From the “Access Points” menu locate the “More” button located above the AP inventory section (not the one above the Domain/Zone window, however that is interesting to look at as well) and click on it.
In the drop down that appears click on the link for “Export All Batch Provisioning APs” and the file that is downloaded from the SmartZone is a csv that you can then open. Open up the csv and fill in the columns as required. Don’t modify the column headers but fill in the information that you want below it, one AP per line. At a minimum I suggest the “AP Mac Addr” & “Zone Name” (required) but since you are here you might as well add an AP name to help out later. Save the file somewhere that you can find later, return to the SmartZone, click the More button above the APs, and select “Import Batch Provisioning APs” and select your file. Similar to the AP rules discussed in Method 1, the MAC address of the AP determines what zone it is automatically pointed to when it joins but without needing to know anything about the IP range or any work needing to be done on a DHCP server.
Along with these 2 methods there is apparently a third method you can use. Even as I am writing this update my team members are pinging me saying “You should also mention this, and that, and then there is this other thing you should talk about.” Something about using AP Tags (no idea on that one yet) and then some other tools built for jobs like this. No idea really. Every time I think I learn something about the RUCKUS SmartZone, someone else comes along as goes “Oh yea, you didn’t mention …” and it is always something new to learn! To everyone else that likes to use AP Tags, I’m not saying it’s not a valid or a good way, I just haven’t learned about that. Yet!
OK, off my soapbox, back to your APs.
That’s it! You’re done! Plug in the old, the really old, and the new APs you have for your network and watch them come online. Each is assigned to their zone to get the firmware required for their model, and they just work.
Some of you may be thinking “but what happens when a new version of code comes out to fix issues with those great 11ax APs? Will that new code be pushed to every zone?” The answer is it won’t. As new patches and code versions come online, each Zone can be upgraded individually from the other Zones. Need a specific patch on a specific Zone because that is the only area affected? Upgrade just that 11ax zone and leave the rest alone. With the flexibility of the zones, and how they can be managed, there are a lot of possibilities for your organization to plan their network. Build staging zones for the code versions just to get APs online, and then move the AP from the 11ax staging zone to an 11ax production zone. Want to sanity check a code version before pushing to production? Upgrade the staging zone and test there. That code version doesn’t work out for you? Just downgrade that zone back to the original version, or the version before that.
The bottom line here is the flexibility offered by the SmartZone’s ability to run multiple versions of firmware to handle multiple areas of requirements is really outstanding. When I spoke of a different way of doing business, a way that I never thought was even possible before joining CommScope RUCKUS, this is what I meant. There is a different way to run your networks, be they physical appliances or virtual machines in your data center, or a virtual machine on Public cloud. CommScope RUCKUS offers other options as well, if that is where you are headed, but that is for that series of posts that I am still working on.
Maybe one day they will see the light of day…
If I get more coffee…
I would be interested to hear about your experience with the SmartZone OS so if you want to chat, drop me a note in the comments below!