AP High Availability Overview
The following topics in this section provides an overview about High Availability and VRRP Virtual Router Redundancy Protocol. VRRP is an election protocol that dynamically assigns responsibility for a virtual router to one of the VRRP routers on a LAN. redundancy:
Learn more about High-Availability and VRRP Redundancy
This section is applicable only for a stand-alone controller or a managed device on the Mobility Master.
When you enable the High Availability WLAN Wireless Local Area Network. WLAN is a 802.11 standards-based LAN that the users access through a wireless connection. redundancy solution, campus APs Campus APs are used in private networks where APs connect over private links (LAN, WLAN, WAN or MPLS) and terminate directly on controllers. Campus APs are deployed as part of the indoor campus solution in enterprise office buildings, warehouses, hospitals, universities, and so on. that lose contact with their active controller do not need to re-bootstrap when they failover to the standby controller, significantly reducing AP downtime. APs using the High Availability features regularly communicate with the standby controller so the controller has a light workload to process in the event of an AP failover. This results in very rapid failover times and a shorter client reconnect period. Therefore, High Availability is usually preferable to other redundancy solutions (like a backup-LMS Local Management Switch. In multi-controller networks, each controller acts as an LMS and terminates user traffic from the APs, processes, and forwards the traffic to the wired network. ) that can put a heavy load on the backup controller during failover, which results in slower failover performance.
High Availability supports failover for campus APs using tunnel, or decrypt-tunnel, or bridge forwarding modes. It does not support failover for remote APs.
AP Fast Failover on bridge forwarding mode virtual AP is supported only on 7200 Series controllers.
Controller Role Types
A controller using this feature can have one of three high availability roles: , , or . An active controller serves APs, but cannot act as a failover standby controller for any AP except those that it serves as an active controller. 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, acting as the active controller for one set of APs, and a standby controller for another set of APs.
A controller is assigned the role if no other role is specified.
AP Communication with Controllers
The High Availability 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 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 Signal sent at periodic intervals from one device to another to verify that the link between the two devices is working. If no reply is received, data will be sent by a different path until the link is restored. A keepalive can also be used to indicate that the connection should be preserved so that the receiving device does not consider it timed out and drop it. messages, or if the user manually triggers a failover using the WebUI or CLI Command-Line Interface. A console interface with a command line shell that allows users to execute text input as commands and convert these commands to appropriate functions.. If inter-controller heartbeat is enabled, APs can failover even when the standby controller misses its heartbeats with the active controller.
Starting from ArubaOS 8.4.0.0, when an AP is disconnected without properly notifying the controller, the controller ages out the AP by detecting the AP heartbeats failure. Since the AP heartbeats are sent in clear text format, attackers can easily implement fake heartbeats and remove the valid APs without losing the AP connection state on the controller. To prevent attackers from sending rogue APs as valid APs that connect to the controller, the AP sends keepalive Signal sent at periodic intervals from one device to another to verify that the link between the two devices is working. If no reply is received, data will be sent by a different path until the link is restored. A keepalive can also be used to indicate that the connection should be preserved so that the receiving device does not consider it timed out and drop it. to both active and standby controllers every 10 minutes. Upon receiving the keepalive Signal sent at periodic intervals from one device to another to verify that the link between the two devices is working. If no reply is received, data will be sent by a different path until the link is restored. A keepalive can also be used to indicate that the connection should be preserved so that the receiving device does not consider it timed out and drop it., the controller updates the AP's last activity timestamp. If the last activity timestamp is more than 15 minutes, the controller ages out the AP.
High Availability for bridge mode is supported on Campus APs Campus APs are used in private networks where APs connect over private links (LAN, WLAN, WAN or MPLS) and terminate directly on controllers. Campus APs are deployed as part of the indoor campus solution in enterprise office buildings, warehouses, hospitals, universities, and so on.. In this mode, the controller sends ACL Access Control List. ACL is a common way of restricting certain types of traffic on a physical port. Names to the APs instead of the ACL Access Control List. ACL is a common way of restricting certain types of traffic on a physical port. IDs. These APs generate and maintain the mapping between the ACL Access Control List. ACL is a common way of restricting certain types of traffic on a physical port. Name and ACL Access Control List. ACL is a common way of restricting certain types of traffic on a physical port. Id. In the event of a failover the ACL Access Control List. ACL is a common way of restricting certain types of traffic on a physical port. name is sent to the AP from the stand-by controller. Since AP maintains the mapping, the ACL Access Control List. ACL is a common way of restricting certain types of traffic on a physical port. IDs remain intact during a failover.
Redundancy and High Availability Requirements and Limitations
A backup controller can use the High Availability feature. However, a backup controller can only accept standby connections from APs, and will not serve active APs as long as its master redundancy role is .
This type of High Availability deployment has the following requirements and limitations:
- A backup-master controller can only form an active-standby pair with the master controller.
- The backup master cannot terminate active APs.
- Both the backup-master and master controllers must be configured with the controller role.
- The defined in the high availability group profile must be the IP address of the controller.
- If MultiZone is enabled, High Availability cannot be configured.
- controllercontroller. If the inter-controller heartbeat feature is enabled in a high availability group profile for redundant masters, the inter-controller failover time must be greater than the VRRP Virtual Router Redundancy Protocol. VRRP is an election protocol that dynamically assigns responsibility for a virtual router to one of the VRRP routers on a LAN. failover time. That is, the (heartbeat interval * heartbeat threshold) value should be greater than the (advertisement time * 3 + preemption delay + skew time [which is based on priority]).
High Availability Deployment Models
High availability supports the following deployment models.
Active/Active Deployment Model
In this model, two controllers are deployed in dual mode. Controller one acts as a standby for the APs served by controller two, and vice-versa. To ensure that each AP gets a standby, Aruba recommends not to have AP count more than 50% of the platform limit; if one controller fails, all the APs served by that controller would failover to the other controller, 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 is idle in standby mode. If the active controller fails, all APs served by the active controller will 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 will 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
For information to help you plan your redundancy solution, refer to the following topics under this section:
High Availability with Extended Capacity
