By: Structured Wireless & Mobility Engineers Jed Rabe, CWNE, ACDX, ACMPv8, and Don Wright, ACDX, ACMP, CWDP, CWNA, MGCA —

Clients rely on the team at Structured to plan, deploy and support their wireless infrastructure — especially when that technology is from Aruba Networks. Improvements in the Wi-Fi standard, LPWAN, and indoor tracking and wayfinding are driving change, and so many of our clients are interested in installing a brand-new Aruba wireless network or are looking to upgrade to the latest ArubaOS (AOS) architecture. In either case, we often are asked some common questions:

• What are the key features introduced with ArubaOS 8 (AOS 8)?
• What are the new Mobility Master Licenses for?
• Do all of our licenses transfer to the new architecture?
• Does the AOS 8 architecture still support our current hardware?
• What does the migration process between ArubaOS 6 (AOS 6) and AOS 8 look like?

We aim to address each of these questions to help you feel more comfortable with the latest AOS architecture and to get the most from your wireless infrastructure.

What are the key features introduced with AOS 8?

When AOS 8 was introduced, it was described as a completely new architecture. This description is true. The Aruba operating system was designed from the ground up. You will find some similarities in the GUI and the command line, but there were significant changes that make this new architecture far superior in regard to scalability and redundancy. Below are the key features introduced with ArubaOS 8:

• Mobility Master VM or Hardware Appliance
• Hierarchical Configuration
• Controller Clustering
• Live Upgrade and Seamless Failover
• AirMatch
• MultiZone AP
• Virtual Mobility Controller

The first change you will see is that the master role has been removed from the physical controller and has been moved to a VM or hardware appliance called the Mobility Master. The Mobility Master is where all of the configuration is performed. It is also responsible for the licensing server, radio resource management, and cluster management, among other tasks.

The configuration is now done hierarchically. The root of the configuration is done within the network management level. It is recommended that no customer configuration is created at this level. From there, engineers are able to create a configuration hierarchy from regions, to campuses, to sites, and then to individual nodes. This hierarchy can be designed however the environment requires. The important thing to note is that all common/shared configuration is created in the upper layers of the hierarchy which is then inherited by the lower nodes. The site-specific configuration can then be used to override any of the inherited configuration.

A great example of this is a named VLAN that exists on every network within the organization — the Guest VLAN, for example. The VLAN ID may be different across the different sites. Therefore, the named VLAN can be created at a higher configuration tree and inherited by all the sites. Each site can then override the named VLAN by applying the specific VLAN ID for that location. This makes the configuration highly scalable and easier to manage in larger networks.

Controller Clustering is perhaps the most exciting feature in the AOS 8 architecture. Now, instead of having master-master or master-local environments, all of the controllers have been renamed as “managed devices.” Controllers can be clustered together for full redundancy and true hitless fault tolerance. Within a cluster, all of the APs AND all wireless clients are load-balanced across the controllers.

Each AP and wireless client is assigned a primary controller and a secondary controller. All of their traffic is shared between the primary and secondary controller. If the primary controller should fail, the secondary controller takes over without the AP or client dropping any traffic. This also introduces the live upgrade feature of the AOS 8 architecture.

As long as the wireless network was designed with enough APs for RF redundancy, then the controller clusters can be upgraded during production hours. This is possible by the cluster leader moving APs and wireless clients from one controller to another cluster member. The cluster member that now has zero APs and clients is upgraded to the latest firmware code release. The cluster leader then selects APs to be migrated back to the freshly upgraded controller. Before doing so, the APs will be pre-loaded with the new firmware and then migrated to the controller. This reduces the number of reboots required for the APs to upgrade. The cluster leader will select APs that are not neighbors in order to reduce the impact of those APs rebooting. As long as there is enough RF redundancy designed into the environment, none of the clients will know that this upgrade is in progress. The cluster will continue this process until all controllers in the cluster have been upgraded and will then rebalance the AP and wireless client load between the cluster members.

The next improved new feature is the radio resource management (RRM) process. Anyone who is familiar with Aruba Networks knows how ARM (Adaptive Radio Management) works. Aruba Networks has now introduced a new RRM process called AirMatch. This new process works by having the APs and controllers report RF events within the environment to the Mobility Master within a 24-hour period. The Mobility Master uses all of the data collected to calculate new radio transmit powers and channel assignments. These assignments are applied once per day in order to reduce the “ripple” effect that was experienced by ARM. ARM is only used by standalone controllers. AirMatch is only available with a Mobility Master. It is found that AirMatch provides greater stability within a wireless environment.

The MultiZone feature allows an AP to terminate its GRE tunnels to two different controllers that are in different configuration domains. This allows a multi-tenant environment, such as an airport, to allow other businesses to utilize the airport’s APs to provide wireless access on their SSIDs. This sounds like a great idea, but — in reality — it is difficult to accomplish as the tenants will need to have their own controllers, licenses, and collaboration with the main facility.

A more practical example of MultiZone is the ability to create an airgap between a corporate network and a guest network. An enterprise can have its Mobility Master and primary controllers within its trusted zone and another standalone controller in the DMZ. All guest network functions would live on the controller in the DMZ terminating the guest SSID tunnels there. Ultimately, this creates another layer of security for that organization.

A final, highly compelling feature is the Virtual Mobility Controller (VMC). Aruba has introduced a fully virtualized controller that runs on VMware, Microsoft Hyper-V, and KVM hypervisors. The VMC provides environments with a lot of flexibility by eliminating the need for additional hardware. However, the VMC does have additional required per-AP licensing to permit the termination of APs. Aruba has great documentation on the installation requirements, sizing guides, and licensing.

The new AOS 8 architecture provides many new features that make a wireless network more scalable, easier to manage, redundant, and more secure.

What are the new Mobility Master licenses for?

With the new Mobility Master comes another license. The license is called the “MM-VA-XX” or “MM-HW-XX”, depending whether you purchase the virtual appliance or hardware appliance. This license entitles you to manage each mobility controller and AP in your environment. If your Mobility Master is a virtual appliance, this is a per-device license that is sold in blocks of 50, 500, 1K, 5K, and 10K licenses. If you opt for a hardware appliance, then the MM licenses are built into the appliance that supports 1K, 5K, or 10K devices. In most cases, a virtual Mobility Master is deployed. This allows the environment to be more flexible and leverage the redundancy built into virtual environments. A second mobility master VM can be created for redundancy without any additional cost.

Do all of our licenses transfer to the new architecture?

The short answer is YES! All of your AP, PEF, RFProtect and VIA licenses can be migrated to the new AOS 8 architecture. At this time, you are able to migrate all of your licenses without losing functionality of your current AOS 6 deployment. This provides you with the ability to stand up the AOS 8 environment, test its functionality, and then migrate all of your controllers and APs at your convenience.

Does the AOS 8 architecture still support our current hardware?

The Aruba AOS 8 architecture only supports the latest 7000 and 7200 series controllers. Any controller older than that will require a hardware refresh. Also, as new firmware releases become available, older AP models will become unsupported. It is always important review the latest firmware release notes to determine if the AP models in your environment are supported.

Another important thing to note is that newer AP models, such as the new 802.11ax access points, are only supported on the AOS 8 architecture. If you are looking to implement new APs, it is a great time to start looking at upgrading to the AOS 8 architecture.

What does the migration process between AOS 6 and AOS 8 look like?

The migration process from AOS 6 to AOS 8 is fairly straightforward. Currently, there are two methods to migrate to the new architecture.

The first (and most recommended) migration method is to stand up a new Mobility Master and carefully plan the configuration hierarchy. It is important to consider the potential for adding new sites and hardware in the future. Once a plan for the configuration hierarchy is identified, it is best to work with Aruba Technical Support to migrate the AP, PEF, and RFProtect licenses to the Mobility Master. The next step is to identify which configurations are shared across all sites and make sure that configuration is added to the upper level hierarchy. This could be similar VLAN names, SSIDs, AP groups, etc. Then, work your way down the hierarchy to each node (i.e. Mobility Controller). Once the configuration is in place, either a net-new mobility controller or a secondary controller can be migrated to the AOS 8 architecture along with a single AP to test the configuration. Thorough configuration testing is recommended. After successful testing, migrate all of the APs to the AOS 8 architecture and allow the environment to run in this state for a day or two to ensure normal functionality. The last step would be to migrate the Mobility Master from the AOS 6 environment to the new AOS 8 environment.

The second method is using the migration tool that Aruba Networks provides. This, too, is a VM that connects to your current controllers, extracts the configuration, and then migrates that configuration to the Mobility Master — which must be already set up and running on your network. This method is effective — but not always the best way to migrate — because old, unnecessary configuration content also will be ported. This method also doesn’t take into account the appropriate hierarchical configuration. Therefore, this method is not preferred by Structured’s engineers.

When done properly, the migration process is straightforward and requires very little downtime. Typically, the whole process can be accomplished in three to four days depending on the complexity of the WLAN environment.

Conclusion

The latest ArubaOS architecture brings a lot of exciting new features to an already solid wireless network solution. The AOS 8 architecture enhances scalability, redundancy, security and ease of management over AOS 6. With the advancements in wireless networking, migrating to AOS 8 is key as the AOS 6 architecture won’t support WPA3 or 802.11ax.

For more information on ArubaOS 8 or the migration process, please contact Structured. Our wireless and mobility networking team, which has performed numerous migrations and new installations in every kind of environment, stands ready to assist. We have the skills and expertise to assist your team with a successful AOS 8 migration or net-new installation.

Jed Rabe recently obtained his Certified Wireless Network Expert certification, a prestigious expert-level certification within the wireless networking professional community. In order to obtain this certification, Jed needed to first obtain the CWNA, CWSP, CWDP, and CWAP certifications; publish a number of articles; receive peer recognition and recommendation; and then be approved by the CWNE board. This certification recognizes that Jed is a wireless network professional that understands wireless administration, security, design, and analysis principles at an expert level. 

Don Wright is a highly certified network and wireless engineer with more than 25 years of experience in designing, installing, troubleshooting and maintaining WLAN systems. With a keen eye for detail and a unique understanding of how business and technology intersect and impact one another, Don specializes in Large Public Venue (LPV) and high-density wireless deployments. His skill in resolving high-profile issues, paired with his passion for providing superior customer service and support, make him an invaluable resource for Structured and its clients.