Q: How to configure clustering of 8.x Aruba Mobility Controllers?
ASE Link: Go to the solution
A: Summary
Clustering is a new feature introduced in AOS 8.0 that enables seamless roaming of clients between APs, hitless client failover and load balancing of users across Mobility Controllers in the the cluster.
This solution provides the configuration required to create a cluster of Mobility Controllers that are managed by the same Mobility Master.
This solution uses the terms "Mobility Controller" (MC) and "Managed Devices" (MD) interchangeably. Both these terms refer to controllers in the AOS 8.0 context (hardware or virtual) that are managed by the MM.
About clustering
AOS 8.0 introduces the concept of AP Anchor Controllers (AAC) and User Anchor Controllers (UAC), as described below. Clustering in AOS 8.0 provides the following benefits:
- Seamless roaming of clients: When MDs are part of a cluster, each client that connects to the network always terminates on a dedicated MD, referred to as User Anchor Controller (or UAC), irrespective of what AP they are connected to. The AP that a client is connected to builds a dynamic tunnel back to the UAC. When the client roams from AP1 to AP2, AP1 tears down the dynamic tunnel and AP2 builds a similar tunnel back to the UAC. Since the client always connects back to the same UAC that maintains the client state and sessions, the user does not experience any network drops during roaming.
- Hitless failover:
- Hitless AP failover: When MDs are part of a cluster, APs that come up will connect to their LMS IP (i.e. one of the cluster members), called the Active AP Anchor Controller (or A-AAC). The AP builds a standby tunnel to a Standby AAC (or S-AAC) that is selected by the cluster leader. When the A-AAC goes down, the AP seamlessly fails over to the S-AAC. This is similar to how AP Fast Failover (HA) works in AOS 6.x.
- Hitless client failover: When MDs are part of a cluster, high value client sessions (such as voice, video, FTP, SSH etc.) are synchronized between active and standby members of a cluster, thereby making the client failover seamless. When a client joins the cluster, it always terminates on a dedicated MD in the cluster called Active User Anchor Controller (or A-UAC). The cluster leader then selects a Standby UAC (S-UAC) from the cluster. Since the client L2 state and high value client sessions are maintained between A-UAC and S-UAC, if the A-UAC goes down, the client is able to failover to the S-UAC without the user noticing any loss in connectivity.
- User load balancing: Clients are evenly load balanced among cluster members, based on the platform capacity of cluster members and the configured load-balancing threshold.
Minimum Software Version Required
AOS 8.0.0
Minimum Networking requirements
- All cluster members are time synchronized. It is recommended that an NTP server is configured for that cluster.
- It is strongly recommended that only controllers of the same model are members of a cluster.
clustering guidelines
- The Mobility Master cannot be part of a cluster. Only MDs make up a cluster.
- For the 72xx controller model, you can add up to 12 members per cluster.
- For the 70xx controller model, you can add up to 4 members per cluster.
- For the VMC model, you can add up to 4 members per cluster.
- If you have RAPs in your deployment, you can add up to 4 members per cluster, irrespective of the controller model.
- When MDs are added to a cluster, a cluster leader is chosen based on configured priority, platform value and MAC address. This solution assumes default 'configured priority', i.e., priority is not explicitly configured for any cluster member in this solution. So the leader election will primarily be based on the platform value and MAC address.
Ap boot process
When an AP initially boots up in an AOS 8.0 deployment:
- It learns about 'aruba-master' (or a list of aruba-masters) via DNS, DHCP, ADP or static configuration on the AP. It is recommended that VRRP is configured between the cluster members and 'aruba-master' is the cluster VIP.
- If 'aruba-master' is not reachable, the AP will try to contact the next 'aruba-master' (if one is available), that could be a VIP from a different cluster.
- The AP contacts the cluster VIP and receives its configuration, including LMS and Backup LMS IP.
- The AP then terminates on the LMS IP (i.e. one of the cluster members), which is the AP's A-AAC.
- The cluster leader selects a S-AAC from the cluster to which the AP will build a standby tunnel.
Identifying group and device nodes
- When prompted for IP Address and Device Node in this ASE solution, the easiest way to get them is via the show switches debug and the show configuration node-hierarchy commands.
- You can also look up these values from the UI as shown below. The Managed Network > poc > 00:0b:86:bb:cd:47 path corresponds to /md/poc/00:0b:86:bb:cd:47, i.e the device node. Under this node, the IP address can be obtained by navigating to Dashboard > Controller.
Platform(s) Tested
Aruba Mobility Master running AOS 8.0.1.0, build 56862
7030 running AOS 8.0.1.0, build 56862
7024 running AOS 8.0.1.0, build 56862
Licenses
No special license required for the Clustering feature itself.
Standard MM, AP and PEFNG licenses are applicable for the Mobility Master, Access Points and firewall policies, respectively.
References
To learn more about clustering in AOS 8.0, please refer to the following resources.