Wireless Access

Any one can advise what is the recommended HA design of 2 mobility controllers and one mobility master (version 8).

In version 6 i tried master redundancy (active-standby) but in version 8 i can see cluster but when trying master redundancy it is showing (command can be excuted only in mobility master).

If you have a single mobility master, you cannot have master redundancy.  You would need a second MM to establish master redundancy between MMs.  MMs do not terminate access points in ArubaOS 8.

You can establish clustering between the two mobility controllers for controller redundancy, however.

By configuring cluster of 2 MCs ,

- how is configuration synced ?

- what about master redundancy between MCs ? (as i tried to configure it but not possible at this level).

- Is VIP the same as version 6 ?

---

@sultan77 wrote:

By configuring cluster of 2 MCs ,

- how is configuration synced ?

- what about master redundancy between MCs ? (as i tried to configure it but not possible at this level).

- Is VIP the same as version 6 ?

---

If you put both MCs in the same "folder" they will have the same config

You can only have master redundancy between MMs

You can have a VIP like version 6, yes.

So the redundancy options for ArubaOS 8 with a Mobility Master (MM) as the management platform is as follows.

First, the MM is the management platform. It does other tasks such as AirMatch, ClientMatch, AirGroup, etc. But what it does not do is terminate any APs. APs are terminated on Managed Devices (MDs) also known as Mobility Controllers (MCs). 

So you have two options/environments where you may want/need redundancy. First, redundancy for the managment platform, the MM. Second, redundancy for the AP termination, so essentially redundancy of the MCs. Realistically, it is not the MCs that you are providing failover for, it is the APs. If an MC goes down, what happens to the APs, and what happens to the clients connected to the APs.

Redundancy for the MM is fairly simple. You are probably running a virtual MM, so you can simply create a 2nd virtual MM, configure VRRP between the two of them so that they have a Virtual IP (VIP). Do not forget to also enable database synchronization between them. This is part of the VRRP configuration section, but I've seen multiple organizations on large live networks not enable the database synchronizaiotn. BTW, the configuration for this is almost identical to the way it was done in earlier versions of ArubaOS. So that provides redundancy for the MM, but it does nothing for the MCs, APs, or users. So the next step is to provide redundancy for them.

The best way of providing redundancy for the MCs, APs, and users is by configuring a cluster. In the WebUI interface (logged in to the MM because that is the management platform managing all devices on the network), below the Managed Network group node, you should create a group node for your organization (not mandatory, but good practice, as I don't like making any changes at the Managed Network node). Within your organization node, you will likely have your two MCs which are known as device nodes. To start, at the group node above the devices (your organization node in this example), you will need to create a cluster profile. In that cluster profile you will specify both of the MCs as members of the cluster. After that is created, you then need to go to each of the MC device nodes and assign the cluster to the MC. It is essentially that easy.

Something else that can be helpful is to create a VRRP between the two MCs. This will allow you to point the LMS-IP of any of the AP groups you create to one address. ArubaOS 8 will distribute the APs and users across the cluster members, so a single VIP between them is fine.

I hope this helps you understand the environment,

Thanks so much westcott for your answer.

i understood that cluster is the best way to do redundancy between MCs, what would be ip of controller to terminate APs if i have 2 MCs in one cluster ?

And please correct me if i am wrong, doing the configurations in group level of MCs is the same as config sync between Master and standby controllers in version 6 ?

First off, for AP termination, simply go to the MC device nodes and create a VRRP between the two MCs. This becomes the VIP for the cluster. Just a VIP, there is no database synchronization, that is only configured for MM redundancy.

Point the LMS-IP of any AP group to the VIP. Don't worry about which is primary or standby. The cluster leader will distribute the APs between the cluster members. Also, once an AP comes up on the cluster for the first time, it will store a cluster node-list on its flash. Every time the AP boots in the future, it will use the node-list to connect to the cluster member that it is directed to. The LMS-IP essentially becomes unnecessary at that point, unless there are problems.

As for configuration, I don't want to compare it per se to previous versions of the OS because it is very different. It is an inheritance hierarchy. Essentially, an configuration that is made at a group node will inherit to the group node below it. That will be inherited then at any group nodes below that, and ultimately the configs will be inherited at the device node. Each node can have new settings that will then be inherited at the node level below, and each node level can replace settings that were made at the node level above (there are certaing types of settings that cannot be replaced, but I don't want to get into that level of detail here).

Essentially, if you set a configuration at a group node, the device nodes (MCs) below it will inherit that configuration.

I hope that helps,

Thanks so much westcott for your help, i found in your answer what i had missed :)

- where should i configure vrrp settings between two MCs managed by MM ?

- If vrrp ip not configured in LMS of AP group, what is master controller ip used by AP ?

From the MM, go to the device node for the first MC. Then go to Configuration -> Redundancy -> L2 redundancy -> Virtual Router Table and add a virtual router entry. Then go to the device node for the second MC and repeat this process (If you are not sure of the field values, there are lots of documentation and community references on setting up VRRP). After you do this for both MCs, a virtual IP will now be configured for them. Any AP-group LMS-IP references should point to this address.

I hope this helps,

- so what if i didn't configure vrrp ip and not assigned to ap group ? which ip the AP will take as the controller ip ?

- what is the difference betwen above vrrp ip and the one in cluster profile ?

- And Why it doesn't allow me to use the same vrrp ip for 2 controllers in cluster profile ?

If you do not create a VRRP, it is not a problem. When the AP boots it needs 6 pieces of information: IP address, subnet mask, default gateway, AP name, group, and IP address of the MC that the AP will initially connect to. It will discover the MC address from either a static setting on the AP (master IP), DHCP options 43/60, Aruba discovery protocol, or DNS (I've written more about this process in past post responses, you should be able to search for them for more details). After the AP gets this, it will talk to the MC that it discovers. That MC will direct the AP to the LMS-IP to create it's GRE. If the MC is part of a cluster, a list of all cluster MCs (nodelist) is downloaded to the AP. Any time that an AP boots after its initial connection, the AP will use the nodelist to connect to one of the cluster members, so discovery will not be needed in the future. This nodelist also supercedes the LMS-IP address, so that should be set, but once the AP connects to the cluster it will likely never use the LMS-IP address again.

The VRRPs that are specified as part of the cluster configuration is used for a technology known as "Authorization Server Interaction", referred to as ASI. These VIPs should never be used by anything you do. They are created to be used by the cluster members in the case of a change of authorization (CoA) after a cluster member has failed or is unreachable. That is the only use for them. If you want to learn more about this, look it up in the documentation (User Guide). The VRRPs that are defined in the cluster profile are for each cluster member. If you have 10 cluster members, you will need 10 IP addresses (one for each member), and 10 VRRP addresses (one for each member). 
The VRRP ID is by default automatically assigned, starting at 220. If you have 10 cluster members, then VRRP IDs 220 through 229 will be assigned. To be safe, do not assign any VRRP IDs for any other VRRP purposes in the range of 220 through 255, to prevent confusion with the system generated ones.

I hope this helps,