AP redundancy solutoins (like a backup-LMS) put heavy load on the backup controller during failover, resulting in slower failover performance. If the number of Acces Points to failover is much more then unavailability of wireless downtime to users further increases. To avoid this, ArubaOS now supports redundancy through the High Availability:Fast Failover feature based upon the Virtual Router Redundancy Protocol (VRRP). This WLAN redundancy solution allows a campus AP to rapidly fail over from a active to a standby controller without needing to rebootstrap. It significantly reduces network downtime and client traffic disruption during network upgrades or unexpected failures. APs using the High Availability: Fast Failover feature regularly communicate with the standby controller, so the standby controllerr has only a light workload to process if an AP failover occurs. This results in very rapid failover times, and a shorter client reconnect period. This feature supports failover for campus APs in tunnel forwarding mode only. It does not support failover for remote APs or campus APs in bridge forwarding mode. 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, that controller sends the AP the IP address of a standby controller, and the AP attempts to connect to the standby controller. APs using control plane security establish an IPsec tunnel to their standby controllers. APs that are not configured to use control plane security send clear, unencrypted information to the 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.
A controller using this feature can have one of three high availability roles – active, standby or dual.
An active controller serves APs, but cannot act as a failover standby controller for any AP except the ones that it serves as active.
A standby controller acts as a failover backup controller, but cannot be configured as the primary controller for any AP.
A dual controller can support both roles, and acts as the active controller for one set of APs, and also acts as a standby controller for another set of APs.
High Availability groups support the following deployment modes
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 controller fails, 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.
1:1 Active/Standby Deployment model:
In this model, the controller in active mode 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.
N:1 Active/Standby Deployment model:
In this model, each controller in active mode supports up to 100% of its rated capacity of APs, while one other controller is idle in standby mode is idle. 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, two active controllers use a single higher-capacity standby controller.
Configuring High Availability:Fast Failover From WebUI:
NOTE: The IP address of each controller must be reachable by APs, and must be the IP address that appears in the "show controller-ip" command on specific controllers
Select the 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. From CLI:
Points to be noted:
When using active-active with fast failover, how do you monitor the number of active APs via SNMP?
.188.8.131.52.4.1.148184.108.40.206.220.127.116.11 seems to give all the APs, not just the active ones.
In other words, what is the SNMP equivalent to "show ap active"?
#show datapath tunnel table | include <ip address of AP>
#show datapath session table | include <ip address of AP>
#logging level debugging system process ha_mgr
HA failover information:-
#show ap debug system-status ap-name <ap-name>
How do we enable debug to check the HA fast failover is working?
At Aruba, we believe that the most dynamic customer experiences happen at the Edge. Our mission is to deliver innovative solutions that harness data at the Edge to drive powerful business outcomes.
© Copyright 2021 Hewlett Packard Enterprise Development LPAll Rights Reserved.