For my first technical deep dive let’s get into controller redundancy. During this post I will define the different types of redundancy in the Aruba system. Please no controller vs controller-less rants!
Let’s begin by defining redundancy. According to Wikipedia, redundancy is the duplication of critical components or functions of a system with the intention of increasing reliability of the system. Unfortunately redundancy is left off a lot of wireless network designs due to cost. In today’s mobility first environments redundancy needs to be implemented properly to ensure the reliability of the mission critical WLAN.
In Aruba world we have four levels of controller redundancy:
1) Fully redundant – includes both master and local redundancy
2) Redundancy aggregation – local redundancy
3) Hot Standby – Local access points fail-over to Master
4) No Redundancy – self-explanatory (far too common)
Master Redundancy:
The first controller redundancy model we will look at is Master redundancy. The master controller is the control plane of the centralized WLAN. The master controller is responsible for handling the global configuration of the WLAN system, location tracking, IDS event correlation and alerting. The first question we should ask ourselves is what happens if the master controller is unavailable? If the master becomes unavailable all master functions are lost (configuration, location tracking, and IDS) but the WLAN itself will continue to function. New and existing clients will still be able to access the WLAN while the master controller is down.
To provide redundancy for the master controller we will setup a master/standby relationship with two controllers. The Standby Master is a hot standby controller. The Standby Master will not terminate AP sessions while it is the backup unit. Updates on the state of the network are sent from the active Master to the Backup. The two controllers sync the databases (WMS and local user) at a configured interval (typically 30 minutes).
VRRP (Virtual Router Redundancy Protocol) is used as the redundancy mechanism between the two controllers. VRRP requires Layer2 adjacency. The two master controllers will use a shared VRRP interface address. The VRRP address is used by local controllers, access points, and mobility access switches to discover the master controller on the network. The VRRP address can also be used by network administrators to access the management interface for the current master controller.
Local Redundancy:
Next we will look at Local Controller Redundancy. The Local Controllers in an Aruba WLAN are responsible for AP termination, user authentication, and policy enforcement. If a local controller fails and there is no backup the WLAN will become unavailable.
Local controllers have three methods for redundancy
Active-Active
- two locals share a set of APs, divide the load, acts as a backup for each other
- if the two controllers are L2 adjacent, run two instances of VRRP with each controller acting as a primary for one instance and backup for the other instance
- if the two controllers are not L2 adjacent then you will need to setup a LMS/Backup LMS IP address in the AP System Profile
- You can also combine VRRP and LMS/Backup LMS for a more robust redundancy design, the VRRP addresses can be used as the LMS/Backup LMS IP addresses
Active-Standby
- similar to Active-Active except one controller sits idle while the primary controller supports the full loads of APs and users
- this model has a larger failure domain (increases latency because the full load must failover to the backup
- typically this model utilizes the LMS/Backup LMS configuration
- you could also use a single VRRP instance if the controllers are L2 adjacent
Many to One
- typically used in remote networks where branch offices have local mobility controllers but redundancy onsite is not feasible
- a large controller is deployed as the +1 controller at the data center
- failure typically occurs across a WAN link
- preemption should be enabled in this scenario due to the possible delay introduced by failing over to a remote site
No Redundancy
- if the local goes down, no users can connect
- Any AMs associated go down
Now that we know the different types of redundancy options we need to be aware of a few rules to ensure our network stays up according to plan. There are four major rules in dealing with controller redundancy:
- Make sure the redundant controller can support the additional AP load during a failover event
- Make sure the same VLANs exist on both controllers and that named VLANs are mapped on the redundant controller
- Make sure the controllers are running the same OS version
- Make sure the redundant controller has the same license features enable and ensure you have enough license capacity to support the additional AP load during a failover event (AOS 6.3 will address this previous limitation)
In my next post I will begin configuring each of the different redundancy methods.