- AP establish simultaneous communication channel with both active and standby controller
- During a failover, the load from the APs on a standby controller is minimal
- During a failover, the APs do not turn their radios off and on, thus minimizing the RF outage experience for an end-user
- The solution works across L3 networks. There is no need for direct L2 connection between HA controllers
- Apart from 1+1 (active-standby), AP Fast Failover supports 1:1 (active-active), N:1 and N+1 models
Feature Notes : This feature is introduced in 6.3 and further improvisation is done in 6.4. In this article we will focus about basic feature introduced in 6.3.
Environment : A master and local configured for AP fast failover and their High availability role defined.
Network Topology : Master (Active) -------Local (Standby)-------- APs
Configuration Steps :
Configure HA Group Profile
(Abilash-Lab-Cont-master-6.4) (config) #ha group-profile SFO
(Abilash-Lab-Cont-master-6.4) (HA group information "SFO") #controller 10.10.10.1 role active
(Abilash-Lab-Cont-master-6.4) (HA group information "SFO") #controller 10.10.10.2 role standby
(Abilash-Lab-Cont-master-6.4) (config) # ha group-memebership SFO
(Abilash-Lab-Cont-local-6.4) (config) # ha group-memebership SFO
- Active: Controller is active and serving APs
- Dual: Controller serves some APs and acts as standby for other APs (1:1)
- Standby: Controller does not serve APs, only acts as standby in case of failover
Show commands that can be used are:
#show ha ap table
#show ha group-membership
#show ha ap information ip-addr 10.17.164.102
- AP Fast Failover in AOS 6.3 supports Campus AP in tunnel or decrypt-tunnel forwarding mode only. AP Fast Failover is NOT supported for RAP, CAP in bridge mode and Mesh.
- AP Fast Failover is not supported on APs 6x,7x. Those APs will failover using legacy slow failover
- When AP Fast Failover is enabled, it has higher precedence over legacy lms/backup-lms based failover. i.e, the APs will first attempt AP Fast Failover. In practice, the backup-lms ip should be removed when AP Fast Failover is defined.
- The IPs configured in the HA group-profile must be controller IPs (these cannot be vlan IPs or VRRP IPs).
- AP Fast Failover does not use VRRP. If VRRP is defined, the the lms-ip and bkup-lms-ip should be changed to reflect the controller ip.
- AP Fast Failover does not provide redundancy for controllers, and hence customers using VRRP for controller redundancy should continue to use it. AP Fast Failover can coexist with VRRP, as long as VRRP-IP is not used in ha group-profile.
- Defining controller in Dual Role is suggested. A controller in Standby Role will only take over APs failing from a failing controller in Active Role. A Standby controller will not allow APs to use this as the first controller for image upgrade or config download purposes, eg. if "aruba-master' has a DNS record with this IP. This is by design.
- If LMS-IP is used in the ap-system-profile to redirect the AP to another controller, make sure it reflects the controller-IP of an Active or Dual mode HA controller.
- If LMS-IP is not used in the ap-system-profile, then make sure the "aruba-master" DNS entry or DHCP option reflects the controller-IP of an Active or dual mode HA controller
- What is the behavior when HA config is removed? 1) All APs connected to the earlier HA-Active should bring down their tunnels to earlier HA-Standby. 2) On earlier HA-standby controller, it should clean-up all information related to those APs, including AP, bss, radio as well as datapath tunnels. It should also free up the licenses for those APs. 3) APs should continue to remain connected and functioning on the earlier HA-Active, as long as the LMS configuration doesn't change for those APs. There should not be any disruption to AP or client connectivity on the earlier HA-active.