Wireless Access

HI,

 

Here is your gude for deploying HA model.

Active/Active Deployment model

In this model, two controllers are deployed in dual mode. Controller one acts as standby for the APs served by controller two, and vice-versa. Each controller in this deployment model supports approximately 50% of its total AP capacity, so if one controllerfails, all the APs served by that controller would fail over to the other controller , thereby providing high availability redundancy to all APs in the cluster.

Figure 1  Active-Active HA Deployment

1:1 Active/Standby Deployment model

In this model, the active controller supports up to 100% of its rated capacity of APs, while the other controller in standby mode is idle. If the active controller fails, all APs served by the active controller would failover to the standby controller.

Figure 2  1:1 Active/Standby Deployment

N:1 Active/Standby Deployment model

In this model, the active controller supports up to 100% of its rated AP capacity, while the other controller is idle in standby mode. If an active controller fails, all APs served by the active controller would failover to the standby controller. This model requires that the AP capacity of the standby controller is able to support the total number of APs distributed across all active controllers in the cluster.

In the cluster shown in the example below, the standby controller has enough AP capacity to support the total number of APs terminating at the active controllers. ( Controller 1 and Controller 2)

Figure 3  1:1 Active/Standby Deployment

AP Communication with Controllers

The High Availability: Fast Failover features work across Layer-3 networks, so there is no need for a direct Layer-2 connection between controllers in a high-availability group

When the AP first connects to its active controller, the active controller provides the IP address of a standby controller, and the AP attempts to establish a tunnel to the standby to the standby controller. If an AP fails to connect to the first standby controller, the active controller will select a new standby controller for that AP, and the AP will attempt to connect to that standby controller.

An AP will failover to its backup controller if it fails to contact its active controller through regular heartbeats and keepalive messages, or if the user manually triggers a failover using the WebUI or CLI.

 

Configuring High Availability: Fast Failover

Configure the High Availability feature in the WebUI or CLI using the high-availability and high-availability group profiles.

Using the WebUI

To configure High Availability:

1.

Navigate to Configuration>Advanced Services>All Profiles.

2.

In the Profiles list in the left window, expand the HA profile menu.

3.

Select HA group information.

4.

In the HA group information section in the right window pane, enter a name for a new HA group, then click Add.

5.

Select the HA group you just created.

6.

Enter the IP address of each controller in the HA group, and assign a role to each controller. The IP address of each controller must be reachable by APs, and must be the IP address that appears in the Configuration>Controller>System settings tab of the controller WebUI, or in the output of the show controller-ip CLI command.



Active: Controller is active and is serving APs.



Dual: Controller serves some APs and acts as a standby controller for other APs.



Standby: Controller does not serve APs, as only acts as a standby in case of failover.

7.

Select the Allow Preemption checkbox if an AP that has failed over to a standby should attempt to connect back to its original active controller once that controller is reachable again. When you enable this setting, the AP will wait for the time specified by the lms-hold-down-period parameter in the ap system profile before the AP attempts to switch back from the standby controller to the orginal controller.

8.

Click Apply to save your changes.

Using the CLI

Configure the High Availability group:

(host)(config) #ha group-profile <profile>

controller <ip-addr> role active|dual|standby

controller-v6 <ip-addr> role active|dual|standby

preemption

no ...

A controller using the high availability:fast failover feature must be defined as a member of a High Availability group.To add a controller to the new High Availability group, issue following CLI command:

(host)(config)#ha group-membership <ha-group>

Migrating from another Redundancy Solution

ArubaOS has a concept of a local management switch (LMS) and a backup LMS. In a typical deployment, the AP contacts the master mobility controller and is directed to the mobility controller that handles the AP connection and traffic via the LMS parameter. If the LMS becomes unreachable and a backup LMS is specified, the AP attempts to reconnect to that backup mobility controller. This function provides Layer 3 and site redundancy when this level of redundancy is required.

High Availability:Fast Failover provides redundancy for APs, but not for controllers. Deployments that require mastercontroller redundancy should continue to use an existing VRRP redundancy solution.

If your deployment currently uses a backup-LMS or VRRP redundancy solution, use the procedures below to migrate to a High-Availability based solution.

Migrating from VRRP Redundancy

Perform the following steps to migrate from VRRP to High-Availability redundancy:

1.

Remove the VRRP IP address as the LMS IP address of the AP.

(host) (AP system profile) #no lms-ip

2.

Configure the AP to use the active controller’s IP address (not VRRP the IP address) as the LMS-IP for the AP.

(host) (AP system profile) #lms-ip <ipaddress>

3.

Configure the AP to use the standby controller IP address (not VRRP the IP address) as the backup LMS-IP for the AP.

(host) (AP system profile) #bkup-lms-ip <ipaddress>

4.

Configure the master controller with an active role in the high-availability group profile.

(host) (config) #ha group-profile grp1

(host) (HA group information "grp1"): controller <ipaddress> role active

5.

Configure thestandby controller with a standby role in the high-availability group profile.

(host) (HA group information "grp1"): controller <ipaddress> role standby

Migrating from Backup-LMS Redundancy

Perform the following steps to migrate from Backup-LMS to High-Availability redundancy and maintain the existing configuration as defined by the lms-ip and bkup-lms-ip parameters in the AP system profile.

1.

Configure the controller serving the AP with an active role in the the high-availability group profile.

(host) (config) #ha group-profile grp1

(host) (HA group information "grp1"): controller <ipaddress> role active

2.

Configure the AP’s standby controller with a standby role in the high-availability group profile.

(host) (HA group information "grp1"): controller <ipaddress> role standby

 

Please feel free for any further help on this.

 

 

 

 

All of this information is in the AOS user guide.


Thanks,
Tim

Is HA configuration need any license, I am not getting the option in 7030 controller which running AOS 6.4.1.0

No additional license is required. You should see the option under Redundancy.


Thanks,
Tim

OK so if this works as outlined in the UG, how does one go about verifying the HA controllers in Dual mode are working properly? 

In Dual HA mode, do you have to configure both controllers seperately as Master controllers?

I must be missing something.....

 

Thanks,

 

John

 

The easiest way to test is to pull the links to one of the controllers.



Also, when you run show ap database, you'll see a standby controller IP.

OK I don't yet have any AP's up and running yet but will try that next. 

So how do you control which AP's will be served by which controller? 

If you use DNS resolution for aruba-master, which controller do you point DNS to?

 

The documenation for this seems very lacking.....

The ap system profile LMS-IP tells the AP which controller is its primary
controller

OK so DNS would still point to one of the controllers then the AP system profile tells the AP it's primary controller, correct? 

DNS should be pointing to the master controller. The AP system profile will
be tied to the AP groups.

Do the AP's then build a GRE tunnel to both controllers but only use one unless a failure occurs?

Correct. Traffic is re-routed to the second tunnel in the event of a
controller failure.

Ok great! One more question!

 Do the Master controllers syncronize somehow or do you need to setup AP groups and profiles seperately?

 

Thanks,

 

John

If you're doing all master, you need AirWave to synchronize them.

If this is a single site, I'd recommend doing master-local.


Thanks,
Tim

I see. No mention of that in the UG. :-(

 

Thanks. John

Master-local is a different topic so it won't be on the HA section.


Thanks,
Tim

Hmm. So are you saying I should just use Master/Local with no HA?

No, you would use master-local with HA.

---

@cappalli wrote:
DNS should be pointing to the master controller. The AP system profile will
be tied to the AP groups.

I am considering a DR test in Master-Local 1 Master 3 Locals architecture, all controllers are terminating APs  we lose the Master and have few doubts : 

 

1 ) In the event that  the Master goes down, aruba-master resolves to the Master IP@, then new CAPs connected to the network or any rebooting while the master is down would not be able to contact the Master and boot. unless ADP, DCHP or manually point the CAP to one of the IP@ of the locals, correct ?

 

2 ) If using  Infoblox to resolve aruba-master.

Would it be possible to configure 4 A records so aruba-master will resolve to any of the local's in case the Master is not alive ? has anybody faced this situation ?

 

3) Authentication External Server. Currently been forwarded from Masters IP@, would Locals carry on using its IP@ to relay Auth request, I believe this is the default behaviour. The reason I am asking is because if the source of auth request would be local's IP@ then we may need new FW rules in place to allow this. 

 

3) As Local redundancy we are currently using VRRP-LMS. What would the failover time for the APs active on the Master if it goes down ?

 

4) Looking to configure HA AP fast failover. For failover times of 1-2sec. Currently running 6.3.1.15 with some legacy AP70s  which I understand don't support HA AP FF ... would need to workaround this. Also believe there would be some new features on 6.4 to improve 

 

Thanks , 

 

DSP 

DSP i would start a new thread if i were you, these are partly totally different questions.

 

1) not 100% sure,  but i believe if you provision them to a local controller then they can restart fine without the master being reachable. new APs might have issues to get into the system.

 

2) it might get them there, but the locals will be kinda unmanagable without a master so not sure if this will do any good. asssuming 1 is correct you don't need this anyway.

 

3) i believe i get auth request from my local controllers in clearpass, so that will keep working

 

3 again and 4) you lost me a little there. as mentioned start a new thread, add some info on your exact setup (image, device types, version) and repost.

My issue has been solved. I just put all port channel in trusted.

Can controller master and standby is mix model? but It's same version

Yes

Get Outlook for iOS

When i read all the discussions, feeling better to go with VRRP only. In a normal campus environment, normally will not use master-local set up (Active/Active will work properly only with Master-local set up)

Please correct, if i am wrong.

 

Reg,

Shamz

 

It is simpler to setup VRRP-based or LMS-IP-based failover, sure.  HA failover is definitely faster and offers quicker recovery from a controller failure.  The good part is that we have a choice.

Thanks for your tech note;

In the Active/Active, the controllers will synch only if the setup is Master-Local. In case of Master-Master; required Airwave.

 

am i correct?

 

Reg,

Shamz

If you use master/backup master they will sync their configurations. Backup masters cannot terminate access points however.

If you have a master/master install Airwave is required to synchronize configurations, yes..

Also, just to clarify, master/local is still technically active/active as both controllers can terminate APs.

Just one more thing for clarification;

in Master/Master setup with VRRP, Airwave required or not to synch the controllers?

 

Reg,

Shamz..

Only in master/local or master/backup-master are the configurations synchronized automatically.  All other scenarios they configurations must be synchronized manually or with airwave.

Just want to confirm - master-master redundancy cannot be used with HA, because in HA mode the APs will establish tunnels to both controllers, and a master that is currently in standby mode will not terminate AP tunnels.  Is that correct?

The solution would be to remove master-master redundancy, make both controllers into standalone masters, and use AirWave to ensure that configuration is kept synchronized.  Correct?

HA with Master redundancy :

It is supported starting AOS 6.4 and up

---

@jgreen wrote:

Just want to confirm - master-master redundancy cannot be used with HA, because in HA mode the APs will establish tunnels to both controllers, and a master that is currently in standby mode will not terminate AP tunnels.  Is that correct?

The solution would be to remove master-master redundancy, make both controllers into standalone masters, and use AirWave to ensure that configuration is kept synchronized.  Correct?

---

Supported, but....