Clustering of Mobility Controllers Create

a cluster of Mobility Controllers in an

AOS 8.x deployment

Summary

Clustering is a new feature introduced in AOS 8 that enables:

1. Seamless roaming of clients between APs

2. Seamless client failover in the event of a connectivity failure to the active controller.
3. Load balancing of clients across controllers that are cluster members.

This solution provides the configuration required to create a cluster of MCs that are
managed by the same Mobility Master.

ACRONYMS USED IN THIS SOLUTION

● MM - Mobility Master
● MC - Mobility Controller
● VMC - Virtual Mobility Controller (x86 based)
● MD - Managed Device (Mobility Controller managed by a Mobility Master)
● AAC - AP Anchor Controller
● A-AAC - Active AAC
● S-AAC - Standby AAC
● UAC - User Anchor Controller
● A-UAC - Active UAC
● S-UAC - Standby UAC
● CoA - Change of Authorization
● AP - Access Point
● AOS - Aruba Operating System

About clustering

​ rubaOS 8 introduces the concept of AP Anchor Controllers (AAC) and User Anchor
A
Controllers (UAC), as described below. Clustering in AOS 8 provides the following benefits:

1. Seamless roaming of clients: When MCs are part of a cluster, each client that
connects to the network always terminates on a dedicated MC, 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.

2. Seamless failover:
 ● Seamless AP failover: When MCs 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.

● Seamless client failover: When MCs 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 MC 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 connectivity to the A-UAC is lost, the
client is able to failover to the S-UAC without the user noticing a connection drop for
high value sessions.

If you want certain applications to be classified as 'high value', you could mark them as 'high
priority' in the session ACL.

3. 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.

4. Cluster VRRP: The cluster members can be in a configured VRRP group for L2
Cluster. This VRRP group is configured manually in addition to the cluster
configuration.
● Cluster VRRP VRID must be between 1-219.

5. Authorization server interaction (RADIUS CoA): To authenticate new users, the

A-UAC may forward authentication requests to an external RADIUS server with the
A-UAC's IP as the NAS-IP. The external RADIUS server sets this NAS-IP (i.e.
A-UAC's IP) in its client database. The NAS-IP is used later to change the state or
attributes of the client. However, if the client changes its UAC, the authorization
server is not updated and hence cannot send CoA updates to the client. To resolve
this issue, VIP and VLAN are configured in each node in the cluster.
● VRID 220 and higher is used by cluster members for VRRP-IP for purposes
of authorization server interaction (RADIUS CoA).
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.
● For seamless client failover, ensure that all the members in a cluster are
L2-connected, i.e. the same user VLANs exist on all controllers (certain VLANs such
as management VLAN can be marked as excluded VLANs).

clustering guidelines

● The Mobility Master cannot be part of a cluster. Only MCs make up a cluster.
● For the 72xx and VMC controller models, you can add up to 12 members per
cluster.
● For the 70xx controller model, you can add up to 4 members per cluster.
● It is strongly recommended that only controllers of the same model are
members of a cluster. Do not mix hardware and VMC in a cluster.
● If you have RAPs in your deployment, you can add up to 4 members per
cluster, irrespective of the controller model.
● When MCs are added to a cluster, a cluster leader is chosen based on
configured priority, platform type and MAC address. This solution assumes default
'configured priority', i.e., priority is not explicitly configured for any cluster member. So
the leader election will primarily be based on the platform type and MAC address.

Ap boot process
When your AP boots up:

1. It should discover '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 so that 'aruba-master' points to the cluster VIP.
2. If 'aruba-master' is not reachable, the AP will try and contact the next 'aruba-master'
(if one is available), that could be a VIP from a different cluster.
3. The AP contacts the cluster VIP and receives the A-AAC.
4. The cluster leader also selects a S-AAC to which the AP will build a standby tunnel.

Note:

● An LMS IP does not need to be configured if you have only one cluster. As long as
cluster "AP load balancing" is enabled, the cluster leader will take the responsibility of
selecting the A-AAC for the AP.
● If you have more than one cluster, then it may make sense to configure, say,
"Cluster1 VIP" as the LMS IP and "Cluster2 VIP" as BLMS IP. In this case, if all the
cluster members in Cluster1 become unreachable, the AP can use the Backup LMS
IP to failover to Cluster2.
● For very large AP deployments with many clusters, a separate controller can be used
as the initial termination point (aruba-master) for APs. From here, the APs can be
redirected to different clusters as needed.

Platform(s) Tested

1. 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
 2. Aruba Virtual Mobility Master running AOS 8.1.0.3 build 61578
○ VMC running AOS 8.1.0.3 build 61578

Licenses

No special license required for the clustering feature itself.

Standard MM-VA, MC-VA, AP and PEFNG licenses are applicable for the Mobility Master,
VMC, Access Points and firewall policies, respectively.

References

To learn more about clustering in AOS 8, please refer to the following resources.

● ArubaOS 8 User Guide

COMMUNITY

https://community.arubanetworks.com/t5/Aruba-Solution-Exchange/Clustering-of-Mobility-Co
ntrollers/ta-p/282686
Create a cluster profile

configure terminal

#Group-level configuration

cd /md/ArubaMC_CSB

lc-cluster group-profile arubamc_csb_cluster

write memory

Configure Cluster VRRP and CoA VRRP

Create a cluster of Managed Devices

#Device-level configuration

#Cluster Member #1

cd ArubaMC_CSB1

lc-cluster group-membership arubamc_csb_cluster

lc-cluster exclude-vlan 1

write memory

vrrp 32

ip address 172.25.32.20

authentication L30n1s4

preempt delay 60

priority 255

advertise 1

vlan 32
no shutdown

write memory

#Cluster Member #2

cd ArubaMC_CSB2

lc-cluster group-membership arubamc_csb_cluster

lc-cluster exclude-vlan 1

write memory

vrrp 32

ip address 172.25.32.20

authentication L30n1s4

preempt delay 60

priority 250

advertise 1

vlan 32

no shutdown

write memory

#Group-level configuration

cd /md/ArubaMC_CSB

lc-cluster group-profile "arubamc_csb_cluster"

controller 172.25.32.19 priority 128 mcast-vlan 0 vrrp-ip 172.25.32.22 vrrp-vlan 32 group 0

rap-public-ip 0.0.0.0

controller 172.25.32.21 priority 128 mcast-vlan 0 vrrp-ip 172.25.32.23 vrrp-vlan 32 group 0

rap-public-ip 0.0.0.0
redundancy

active-ap-lb

write memory

show lc-cluster group-profile arubamc_csb_cluster