It is much easier to setup the entire master first, and then add the second controller as the backup master. Here is the order;
- Setup the first controller with complete configuration. Install licenses. Terminate access points on it and make sure it is working.
- Add a VRRP or Virtual IP address to the master controller. Do not configure preemption. Make sure the VRRP has a key, so that it does not conflict with any other network equipment that uses HSRP. Change your aruba-master, dhcp option discovery and LMS-ip addresses to point to that new VRRP addresses, as applicable. At this point the controller should be working, and all access points should be pointing to the VRRP.
- Turn on centralized licensing on the master. It should not require a reboot.
- Bring up the second controller and give its management an ip address on the same VLAN as the master controller. Upgrade or downgrade the ArubaOS on that second controller to match the master controller and reboot.
- Add the second controller to the VRRP of the master, but give it a lower priority than the master and do not configure preemption. You should have configured the master with a key, so configure the VRRP on the second controller with same key. After you have configured the VRRP successfully, go to the commandline of the second controller and type "show vrrp" to ensure that it is indeed the backup controller.
The configuration that is used in a master/backup relationship is tied to who controls the VRRP, so it is very important that the first controller is the master of the VRRP and the second controller is the backup of the VRRP at this time. If "show VRRP" on the first controller does not show "master" and "show VRRP" on the second controller does not show backup, you need to stop and troubleshoot your VRRP, or you will risk wiping out your master with with the blank configuration of the second controller.
- Configure Master Redundancy on the first (master) controller by pointing it at the VRRP used between controllers, pointing it at the management ip address of the second controller and setting a new key between the controllers for master redundancy like below:
config t
master-redundancy
master-vrrp <VRRP number>
peer-ip-address <ip address of second controller> ipsec <master redundancy key>
After your configure those parameters on the first controller, when you type "show master-redundancy", it should list the VRRP instance that it is tied to, the state of the controller as being Master and ip address of the peer, or the second controller's ip address.
- Go to the second controller and configure the reverse on the commandline:
<code>
config t
master-redundancy
master-vrrp <VRRP number>
peer-ip-address <ip address of first controller> ipsec <master redundancy key>
Type "show master-redundancy" on the commandline of the second controller to ensure that it is indeed the backup. At this time, the configurations of the controller should start syncing and the backup master should be a read-only version of the master controller.
On the commandline of the master controller, type "show switches" to ensure that it sees itself as master and the backup controller as standby.
As a cleanup step, you will have to create all of the VLANs referenced by the global configuration on the backup controller, because VLAN and port information is not synchronized as part of the global configuration. You will also have to install a server certificate on the backup master, because that is not part of the global configuration, so it is not synchronized. If you are using a radius server, you will have to add the backup controller's ip address as a radius client, since the VRRP between the controllers only functions to virtualize incoming traffic, NOT outgoing traffic like radius requests.
There are quite a few other things that might have to be done to the backup controller, but the above is a general guideline on how to do it...
One word of advice: You want to make sure that the master is up and running with a complete configuration, terminating access points and authenticating clients.
In addition, when the master goes down, or the backup controller misses enough VRRP advertisements from the master, it will take control of the VRRP, and also become the master. Access points that terminate on the VRRP between the controllers will then be talking to the backup master and sending all their traffic to it. NOT configuring preemption on your VRRP avoids a faulty or rebooting piece of equipment from reintroducing itself back into the mix and taking control of the VRRP.
I hope this helps.