Downloaded 198 times
![43
Configuration:
Creating a new cluster group profile (should be done on the MM)
(MM) [cluster2] (config) #lc-cluster group-profile vmc2
(MM) ^[cluster2] (Classic Controller Cluster Profile "vmc2") #controller 10.29.161.98
(MM) ^[cluster2] (Classic Controller Cluster Profile "vmc2") #controller 10.29.161.251
Registering to a cluster group (should be done on the MM with the
managed node as its path)
(MM) ^[cluster2] (config) #cd /md/cluster2/00:0c:29:bc:2a:96
(MM) ^[00:0c:29:bc:2a:96] (config) #lc-cluster group-membership vmc2](https://image.slidesharecdn.com/emeaairheadsarubaosclustermanager-170531055427/85/EMEA-Airheads-ArubaOS-Cluster-Manager-43-320.jpg)
![57
Configuration
• Load balancing is enabled by default when cluster is configured.
− Aruba7210) #show lc-cluster group-profile testlb
Redundancy:No
L2-Connected:No
Active Client Rebalance Threshold:50%
Standby Client Rebalance Threshold:75%
Unbalance Threshold:5%
• The threshold parameters can be configured in cluster group profile
from MM
(ArubaSC) [md] (config) #lc-cluster group-profile Clusterlb
(ArubaSC) ^[md] (Classic Controller Cluster Profile "Clusterlb") #active-client-rebalance-threshold
60
(ArubaSC) ^[md] (Classic Controller Cluster Profile "Clusterlb") #standby-client-rebalance-threshold
70
(ArubaSC) ^[md] (Classic Controller Cluster Profile "Clusterlb") #unbalance-threshold 10](https://image.slidesharecdn.com/emeaairheadsarubaosclustermanager-170531055427/85/EMEA-Airheads-ArubaOS-Cluster-Manager-57-320.jpg)
Uploaded byAruba, a Hewlett Packard Enterprise company
EMEA Airheads- ArubaOS - Cluster Manager
The webinar on Cluster Manager discusses key features of Aruba's clustering capabilities, including seamless campus roaming, hitless client failover, and load balancing among controllers. It covers updates in ArubaOS 8.0, detailing the functionalities of Mobility Master and the clustering architecture for improved network management. The session also addresses practical configuration settings and considerations for maintaining high availability in mission-critical networks.
More Related Content
Similar to EMEA Airheads- ArubaOS - Cluster Manager
![Acmp study guide_d[1]](https://cdn.slidesharecdn.com/ss_thumbnails/acmpstudyguided1-130813141231-phpapp01-thumbnail.jpg?width=640&height=640&fit=bounds)
More from Aruba, a Hewlett Packard Enterprise company
EMEA Airheads- ArubaOS - Cluster Manager
- 1. CLUSTER MANAGER Technical ClimbWebinar 10:00 GMT | 11:00 CET | 13:00 GST May 30th, 2017 Presenter: Saravanan Moorthy saravanan.moorthy@hpe.com
- 2. 2 Welcome to theTechnical Climb Webinar Listen to this webinar using the computer audio broadcasting or dial in by phone. The dial in number can be found in the audio panel, click additional numbers to view local dial in numbers. If you experience any difficulties accessing the webinar contact us using the questions panel.
- 3. 3 Housekeeping This webinar willbe recorded All lines will be muted during the webinar How can you ask questions? Use the question panel on your screen The recorded presentation will be posted on Arubapedia for Partners (https://arubapedia.arubanetworks.com/afp/)
- 4.
- 5. 5 Agenda • Objectives • ClusteringHighlights • Cluster Leader • Cluster Roles • Cluster Hitless Failover • Cluster Load Balancing • Cluster Manual/CLI (re)assignment of AP (and AP-group) to any controller
- 6.
- 7. 7 HA/Fast-Failover: • The highavailability: Fast Failover feature supports APs in campus mode using tunnel or decrypt-tunnel forwarding modes, but does not support campus APs in bridge mode. • This feature is not supported on remote APs and mesh APs in any mode. • With 8 consecutive heartbeat misses (default), AP will detect that the Active controller is no longer available and will failover to Standby controller. • AP will deauth clients before failover to ensure that client will come up properly on backup controller. • AP’s standby tunnel will become active without having to rebootstrap. The SSIDs remains up during failover. • Clients will reconnect to SSID, authenticate and start passing traffic again. • Once primary controller is back up, APs will form standby tunnels to it. If preemption for HA is enabled. APs will move back to primary controller after “LMS hold down” time configured in AP system profile
- 8. 8 What’s New inArubaOS 8.0? - Ideal for Control Plane Functions - Not in the path of traffic - Often need more Memory & more Processing Capacity - Current Form Factor - Same as Locals - Optimized for Packet Fwd’ing - Limited CPU & Memory - Limited Scale
- 9. 9 In ArubaOS 8.0 MobilityMaster Mobility Master - Runs on X86 (VM in 8.0 – Hardware Appliance in post 8.0 releases) - Scales vertically as needed - Flexible CPU/Memory/Disk allocation - Ideal for Control Plane functions - No AP Termination - Software Only option - Economical Solution for Customers
- 10. 10 In ArubaOS 8.0: MobilityMaster Controller Cluster Controller Cluster - Cluster of Controllers performing Control & Data Plane Functions - Cluster up to 12 Nodes - Auto Load balancing of APs and Stations - 100% Redundancy - Active – Active Mode of Operations - High Value Sessions are sync’ed - Sub-Second Switchover
- 11. 11 In ArubaOS 8.0: MobilityMaster Controller Cluster Controller Cluster (DMZ) Air Match
- 12. 12 Clustering for MissionCritical Networks 1 Seamless Campus Roaming Clients stay anchored to a single MD when roaming across controllers 3 Client Load Balancing Users automatically load balanced across cluster members 2 Hitless Client Failover User traffic uninterrupted upon cluster member failure Mobility Master/Standby MCMC MC
- 13.
- 14. 14 Highlights 1 Available ONLYwith Mobility Master 2 Only among Managed Devices (not MM) 3 No License needed MD MD Mobility Master/Standby Headquarter MD 4 CAP, RAP and Mesh AP support
- 15. 15 5 72xx, 70xxand VMC supported 7210 7240 7220 7205 7030 7024 70 10 7005 7008VMC- 50 VMC- 250 VMC-1k Highlights
- 16. 16 Highlights 7024 5 72xx, 70xxand VMC supported All Managed Devices need to run the same software version6 7210 7240 7220 72057030 70 10 7005 7008 8.0.1 8.0.1 8.0.1 8.0.18.0.1 8.0.1 8.0.1 8.0.1 8.0.1 8.0.1 8.0.1 8.0.1 VM C-50 VMC- 250 VMC-1k
- 17. 17 Cluster Capacity: 1 Upto 12 nodes in a cluster when using 72xx devices 7240 7205 7220 7205 7220 7205 7210 7205 7240 7205 7240 7205
- 18. 18 Cluster Capacity: 1 Upto 12 nodes in a cluster when using 72xx devices 2 Up to 4 nodes in a cluster when using 70xx devices 7010 7005 7030 7024
- 19. 19 Cluster Capacity: 1 Upto 12 nodes in a cluster when using 72xx devices VMC- 50 VMC- 250 VMC-1k 2 Up to 4 nodes in a cluster when using 70xx devices 3 Up to 4 nodes in a cluster when using VMC devices VMC-1k
- 20. 20 Key Considerations: 1 Clusteringand HA-AP Fast Failover mutually exclusive 2 Cluster members need to run the same firmware version 3 Size of Cluster terminating RAPs limited to 4 4 Mix of 72xx and 70xx devices in a cluster not recommended
- 21.
- 22.
- 23. 23 How is aCluster Leader Elected? 1 Hello Messages exchanged during Cluster Formation Mobility Master/Standby Headquarter MC MCMC
- 24. 24 How is aCluster Leader Elected? 1 Hello Messages exchanged during Cluster Formation 2 Cluster Leader Election Defined by highest effective priority derived from Configured Priority, Platform Value & MAC 3 All controllers end up in fully meshed IPSEC tunnels between each pair 4 Cluster can be formed over a L2 (recommended) or L3 Network MC MC Mobility Master/Standby Headquarter MC
- 25. 25 What role doesa Cluster Leader play? 1 Dynamically Load Balance clients on increasing load or member addition MC MC Mobility Master/Standby Headquarter 2 Identify Standby MDs for Clients and APs to ensure hitless failover MC
- 26. 26 Cluster Connection Types 1L2- Connected Cluster members sharing same VLANs 2 L3-Connected Cluster members NOT sharing same VLANs
- 27. 27 VLAN Probing: • CMprocess will send a broadcast packet, with source mac as a special mac and destination mac as FF:FF:FF:FF:FF:FF, with vlan set to one of the vlans defined on the controller. • If the cluster member is L2 connected then this broadcast packet will be received by it and an entry with the special mac corresponding to that vlan will be created in the bridge table. • The CM will repeat the broadcast for every vlan defined. • If the bridge table on the peer controller (i.e. cluster member) has entries for this special mac corresponding to every vlan then the two peers are said to be L2-connected, in which case the state of the cluster member will be moved to L2-CONNECTED.
- 28.
- 29. 29 Two Managed Devices(MD) Roles 1 AP Anchor Controller (AAC) 2 User Anchor Controller (UAC) 3 Standby-AAC (S-AAC) 4 Standby-UAC (S-UAC) Redundancy
- 30. 30 Terminology • AAC – −AP Anchor Controller, a role given to a controller from individual AP perspective. − AAC handles all the management functions for a given AP and its radios. The AP is assigned to a given AAC through the existing mechanism of LMS-IP/Backup-LMS-IP configuration for the given AP in the AP-Group profile. • UAC − User Anchor Controller, a role given to a controller from individual User perspective. − UAC handles all the wireless client traffic, including association/disassociation notification, authentication, and all the unicast traffic between controller and the client. − The purpose of UAC is to fix the controller so that when wireless client roams between APs, the controller remains the same within the cluster. − UAC assignment spreads the load of users among available controllers in the cluster
- 31. 31 Terminology • S-AAC – −Standby Controller from the AP perspective − AP fails over to this controller on Active AAC down • S-UAC − Standby Controller from the User perspective − User fails over to this controllers on Active UAC down
- 32. AP ANCHOR CONTROLLER(AAC)
- 33. 33 AP Anchor Controller(AAC) AAC S-AAC Mobility Master/Standby 1 AP sets up Active Tunnels with its LMS (AAC) 2 S-AAC is dynamically assigned from other cluster members 3 AP sets up Standby Tunnels with S-AAC Active Tunnel Standby Tunnel
- 34. 34 AAC Failover AAC S-AAC Mobility Master/Standby1AAC fails and Failure detected by S-AAC 2 AP tears tunnel and S-AAC instructs AP to fail over Active Tunnel Standby Tunnel AAC
- 35. 35 AAC Failover AAC S-AAC Mobility Master/Standby1AAC fails and Failure detected by S-AAC 2 AP tears tunnel and S-AAC instructs AP to fail over 3 AP builds Active tunnels with new AAC Active Tunnel Standby Tunnel AAC AAC 4 New S-AAC is assigned by Cluster Leader S-AAC
- 36.
- 37. 37 User Anchor Controller(UAC) Mobility Master/Standby Laptop MC MC MC UAC 2 When client roams, old AP tears down dynamic tunnel 3 User traffic is always tunneled to its UAC 1 AP creates dynamic tunnel to client UAC
- 38. 38 How does aUser remain anchored to a single controller (UAC)? 2 Hashing -> Index to Mapping Table User 1 Hashing algorithm MAC 1 -> UAC2 MAC 2 -> UAC3 …. User 2 1 User mapped to its UAC via a hashing algorithm at AP level UAC2 UAC3 Mapping Table 3 Same Mapping is pushed to all APs by Cluster Leader 4 Cluster Leader selects S-UAC on per User basis
- 39.
- 40. 40 CLI Output forBucketmap:
- 41. 41 CLI Output forBucketmap:
- 42.
- 43. 43 Configuration: Creating a newcluster group profile (should be done on the MM) (MM) [cluster2] (config) #lc-cluster group-profile vmc2 (MM) ^[cluster2] (Classic Controller Cluster Profile "vmc2") #controller 10.29.161.98 (MM) ^[cluster2] (Classic Controller Cluster Profile "vmc2") #controller 10.29.161.251 Registering to a cluster group (should be done on the MM with the managed node as its path) (MM) ^[cluster2] (config) #cd /md/cluster2/00:0c:29:bc:2a:96 (MM) ^[00:0c:29:bc:2a:96] (config) #lc-cluster group-membership vmc2
- 44.
- 45. 45 Cluster Hitless Failover 1Redundancy Mode enabled TWO CONDITIONS 2 L2-Connected Cluster members sharing same VLANs
- 46. 46 Cluster Hitless Failover •How is Hitless Failover achieved? 1 Client State sync’ed to S-UAC Sta, user, L2_user, L3-user, key_cache, pmk_cache,etc.. 2 High-Value sessions sync’ed to S-UAC FTP, Telnet, SSH, DPI qualified sessions.. 3 NO Client de-Auth w/ failover to S-UAC
- 47.
- 48. 48 Cluster Load Balancing •Why Load Balance Clients? 1 Assume clients are disproportionately balanced 2 Not efficient use of system resources MC MC Mobility Master/Standby Headquarter MC
- 49. 49 Cluster Load Balancing •Why Load Balance Clients? 1 Assume clients are disproportionately balanced 2 Not efficient use of system resources MC MC Mobility Master/Standby Headquarter MC 3 Load Balance clients to optimally load users across a cluster
- 50. 50 Cluster Load Balancing •How does Load on a controller calculated? 1 Identify the controller model 2 Get current client count on controllers 3 Get total client capacity for controller 7240 7220 7210 3000 32000 2000 24000 1000 16000 4 Ratio of the two will give the load ÷ ÷ ÷ 9% 8.3% 6.2%5 Based on the load and additional triggers load balancing takes place
- 51. 51 Cluster Load Balancing •How is the Load Balancing triggered? 1 Rebalance Thresholds Load on cluster node exceeds threshold 2 Unbalance Threshold (5%) Active Client Rebalance Threshold (50%) Standby Client Rebalance Threshold (75%) One Rebalance Threshold and the Unbalance Threshold both exceeded
- 52. 52 Functionality • As clustermembers can be of different controller models, the LB trigger is based on individual node’s current load and not the combined cluster load. • Admin can control when the LB gets triggered by configuring the threshold parameters in the cluster profile. Active Client Rebalance Threshold:50% (default) (Will redistribute active client load when active load on any cluster node is beyond this configured percentage) Standby Client Rebalance Threshold:75% (default) (Will redistribute standby client load when standby load on any cluster node is beyond this configured percentage. Applicable only when redundancy is ON) Unbalance Threshold:5% (default) (The minimum difference in load percentage between max loaded cluster node and min loaded cluster node to let load balancing algorithm kick in)
- 53. 53 Functionality • The LBprocess flow is as follows • Trigger Evaluate Rebalance • LB is triggered only when BOTH load balance threshold and unbalance threshold are met. • “Rebalance” is the process of moving the station (s) from one node to another. This adjustment is done by changing the UAC index in the bucket map for the affected bucket on a per ESS-bucket. • The LB action of moving the clients across nodes to maintain balance will be hitless. • When cluster redundancy is enabled, the LB will additionally trigger and rebalance the standby STA load, just like the active STA load.
- 54. 54 Cluster Load Balancing •Load Balance trigger example 1 Identify the controller model 2 Get current client count on controllers 3 Get total client capacity for controller 7240 7220 7210 17000 32000 10000 240001000 16000 4 Ratio of the two will give the load ÷ ÷ ÷ 53% 41.6% 6.2% 5 LB triggered -> Rebalance from 7240 between 7210 and 7220 Clients
- 55. 55 Example case studies -active-client-rebalance-threshold 10% - unbalance-threshold 5% Case1: − 7240 (A): 3,000 clients − 7220 (B): 2,000 clients Result: No LB. Because neither threshold is met! (A is 9%, B is 8%) Case2: − 7240 (A): 4,000 clients − 7220 (B): 700 clients Result: LB is triggered. (A is 12.5%, B is 2.8%, and unbalance is > 5%) Case3: − 7240 (A): 500 clients − 7220 (B): 0 clients (node just rebooted) Result: No LB. Because neither threshold is met! (A is 1.5% and unbalance is < 5%)
- 56. 56 LB Internals • Clusterredundancy disabled LB uses the standby-UAC designation to alter the replication from none to a target new controller first. Once replication is done, CM will re-publish the bucket map to change the active-UAC and then clear the standby-UAC of the bucket. The active-UAC designation of a bucket causes AP to switch clients to the new UAC, which already receives the data as a “temporary standby”, so that client can switch to new UAC with minimal disruption. • Cluster redundancy enabled. LB will set the standby-UAC to the new UAC. Once completed, LB will swap the active-UAC and standby- UAC in the bucket map. Once done, the new UAC will be the active one, and the original active UAC will be the standby. It is up to Load Balancer to decide whether to transition back and use the original standby-UAC for the switched bucket or not, depending on the overall load distribution target that Load Balancer concludes.
- 57. 57 Configuration • Load balancingis enabled by default when cluster is configured. − Aruba7210) #show lc-cluster group-profile testlb Redundancy:No L2-Connected:No Active Client Rebalance Threshold:50% Standby Client Rebalance Threshold:75% Unbalance Threshold:5% • The threshold parameters can be configured in cluster group profile from MM (ArubaSC) [md] (config) #lc-cluster group-profile Clusterlb (ArubaSC) ^[md] (Classic Controller Cluster Profile "Clusterlb") #active-client-rebalance-threshold 60 (ArubaSC) ^[md] (Classic Controller Cluster Profile "Clusterlb") #standby-client-rebalance-threshold 70 (ArubaSC) ^[md] (Classic Controller Cluster Profile "Clusterlb") #unbalance-threshold 10
- 58.
- 59.
Editor's Notes
- #7 Current Aruba’s Move Architecture and what is the current challenge in this. Network Access: Layer 1 Access(AP’s) - Innovation from .11b to .11ac – Wireless or RF optimization – Client Match - Hardware changes Aggregation: (Local controllers or Mobility Controllers) All the client tunnel to the controller – AppRF – WCC - Wireless CP/DP – Not good for resilient – Upgrade and not good for failover – Load sharing is not possible Network Services: (Master Controllers or Master Mobility controller) Central mgmt – WMS + N+1 redundancy – No support for SDN(Software Defined Networking) or Open flow controllers– No Global view/visibility like topology, all AP’s. Airgroup - Need more scale and push for more intelligence or more memory.
- #13 The AOS 8 Clustering feature was designed primarily for mission critical networks. Its goal is to provide full redundancy to APs and Wifi clients alike in case of a malfunction of one or more of its cluster members. Here are the benefits that could be immediately obtained from deploying on campus Aruba Mobility controllers as Managed Devices in a cluster configuration: Seamless Campus Roaming: The fact that clients remain anchored to a single controller (cluster member) throughout their roaming on campus, no matter which access point they connect to, makes their roaming experience seamless since their L2/L3 information and sessions remain on the same controller. Hitless Client Failover: Thanks to the full redundancy within the cluster, in the event of a cluster member failure, its connected clients are failed over to a redundant cluster member without disruption to their wireless connectivity, nor to their existing high value sessions. Client Load Balancing: The clients are automatically load balanced within the cluster. When clients are moved among cluster members, the move is done in a hitless manner.
- #14 The AOS 8 Clustering feature was designed primarily for mission critical networks. Its goal is to provide full redundancy to APs and Wifi clients alike in case of a malfunction of one or more of its cluster members. Here are the benefits that could be immediately obtained from deploying on campus Aruba Mobility controllers as Managed Devices in a cluster configuration: Seamless Campus Roaming: The fact that clients remain anchored to a single controller (cluster member) throughout their roaming on campus, no matter which access point they connect to, makes their roaming experience seamless since their L2/L3 information and sessions remain on the same controller. Hitless Client Failover: Thanks to the full redundancy within the cluster, in the event of a cluster member failure, its connected clients are failed over to a redundant cluster member without disruption to their wireless connectivity, nor to their existing high value sessions. Client Load Balancing: The clients are automatically load balanced within the cluster. When clients are moved among cluster members, the move is done in a hitless manner.
- #15 Here are highlights of the Clustering feature: 1. The Clustering feature is only available in deployments with the Mobility Master, as opposed to standalone controller deployments. 2. Cluster members can only be Mobility Controllers. In other words, we cannot at this time have Mobility Masters in a cluster. 3. There is no license required to turn on the Clustering feature. 4. Cluster members can terminate Campus APs (CAP), Remote APs (RAP) and Mesh APs.
- #16 The following Mobility Controllers are supported: &2xx, 70xx and Virtual Mobility Controllers (VMC)
- #17 The following Mobility Controllers are supported: &2xx, 70xx and Virtual Mobility Controllers (VMC) All Managed Devices are required to run the same ArubaOS version (8.0 and higher)
- #18 Cluster capacity per platform: Up to 12 Mobility Controllers when using 72xx
- #20 Cluster capacity per platform: Up to 12 Mobility Controllers when using 72xx Up to 4 Mobility Controllers when using 70xx Up to 4 VMs when using the Virtual Mobility Controller (VMC)
- #21 It is important to keep in mind several key considerations: The Clustering feature and the HA AP Fast Failover feature are mutually exclusive. Cluster members are required to run the same ArubaOS version. When the cluster is terminating Remote APs (RAPs), the size of the cluster is reduced to 4. A mix of hardware (7xxx) and x86 Mobility Controllers in the same cluster is NOT supported A mix of 72xx and 70xx Mobility Controllers in the same cluster is not recommended, not to mention the fact that the number of cluster members is reduced to 4.
- #24 As soon as Mobility Controllers are configured as members of the same cluster, they start handshaking among each others to determine cluster reachability and eligibility. Such action ensures that all cluster members see each other and that the cluster is fully meshed.
- #25 Here are some of the duties of the Cluster Leader: Mapping of clients to a their dedicated Mobility Controller within the cluster. This is known as bucketmap computation. Dynamic load balancing clients among cluster members on client load increase or member join/split. Dynamic assignment of Standby AP and User Anchor Controllers (S-AAC and S-UAC)
- #26 Here are some of the duties of the Cluster Leader: Mapping of clients to a their dedicated Mobility Controller within the cluster. This is known as bucketmap computation. Dynamic load balancing clients among cluster members on client load increase or member join/split. Dynamic assignment of Standby AP and User Anchor Controllers (S-AAC and S-UAC)
- #27 As a follow-up to the cluster members in a full mesh state, the cluster members connection type become known as L3-Connected. Once all cluster peers are in L3-Connected state, a mechanism called VLAN Probing is launched on each cluster member. The Vlan Probing MMheme on each cluster member consists of sending a specially crafted L2 broadcast packet on each configured vlan on the controller. This vlan probing MMheme is bidirectional and is performed between every pair of cluster members. If a cluster member receives an acknowledgment to its probe on all its configured vlans from its cluster peer, it changes its connection state with that peer to L2-Connected. If all cluster members have an L2-Connected state with all their cluster peers, that will indicate that all vlans are shared among all cluster members. Besides vlan probing, Cluster members will also periodically heartbeat each others for faster failure diMMovery. The heartbeat MMheme is dynamic and takes into account the roud trip delay (RTD) between each pair of cluster members. As a follow-up to the cluster members in a full mesh state, the cluster members connection type become known as L3-Connected. Once all cluster peers are in L3-Connected state, a mechanism called VLAN Probing is launched on each cluster member. The Vlan Probing MMheme on each cluster member consists of sending a specially crafted L2 broadcast packet on each configured vlan on the controller. This vlan probing MMheme is bidirectional and is performed between every pair of cluster members. If a cluster member receives an acknowledgment to its probe on all its configured vlans from its cluster peer, it changes its connection state with that peer to L2-Connected. If all cluster members have an L2-Connected state with all their cluster peers, that will indicate that all vlans are shared among all cluster members. Besides vlan probing, Cluster members will also periodically heartbeat each others for faster failure diMMovery. The heartbeat MMheme is dynamic and takes into account the roud trip delay (RTD) between each pair of cluster members.
- #30 When Redundancy is enabled (default), the Cluster Leader elects standby controllers roles for every AAC and UAC in the cluster: S-AAC and S-UAC. If Redundancy is disabled, the hitless failover feature will not be available and clients are de-auth’ed by the APs upon a cluster member failure. However, the Load Balancing feature is maintained.
- #34 The AP Anchor Controller (AAC) is a role given to a cluster member Mobility Controller from an AP perspective. The AAC is actually the AP LMS controller. In other words, an AP that belongs to a given ap-group will get assigned its AAC through the lms-ip option in the ap system profile. The AAC is responsible for the handling of all the management functions of an AP and its radios. Here are examples of the AAC tasks: AP image upgrade CPSEC tunnel setup Config download to the AP With redundancy enabled, Cluster Manager dynamically assigns another cluster member as a Standby AAC (S-AAC) to the AP. The AP in turn builds standby tunnel(s) to the S-AAC
- #35 In the event of an AAC failure: The S-AAC detects the failure within a very short time thanks to the inter-controller heartbeats The S-AAC instructs the AP to failover immediately
- #38 The User Anchor Controller (UAC) is a role given to cluster members from an individual user perspective. The UAC Mobility Controller handles all wireless client traffic: Association/Disassociation notification Authentication All unicast traffic between the Mobility Controller and its clients Roaming clients among APs Upon associating to the AP, a client UAC Mobility Controller is determined and the AP uses existing GRE tunnel, if it exists, to push the client traffic to its UAC. If no GRE tunnel exists, the AP creates on the fly a dynamic tunnel to that client’s UAC. When that client roams to a different AP, the original AP tears down the dynamic tunnel if no other clients are using it. The new AP the client roamed to follows the same tunneling guidelines as above to push traffic to the SAME UAC Mobility Controller.
- #39 As mentioned in the previous slide, a given user traffic is always terminating on the same Anchor Mobility Controller (UAC) no matter which AP the user is connected to within the controller clustering domain. Here is how an AP is able to keep a given user anchored to a single controller: When a client associates to an AP, its wifi mac address goes through a hashing algorithm to produce a decimal number [0..255]. That decimal number is used as an index to a mapping table that provides the UAC controller for that client. This mapping table is also known as a Bucket-Map. The bucket-Map is computed by the Cluster Leader on a per ESSID basis and pushed to all the APs in the clustering domain. At the same time that a UAC is assigned to a given user, a Standby UAC gets also assigned to that user, if Redundancy is enabled.
- #46 A hitless failover within a cluster is defined as a seamless failover of users from their UAC to their S-UAC without any of their applications timing out or dropping as a result of a cluster member failover. There are two (2) conditions to achieve a cluster hitless failover: Redundancy mode is enabled Cluster members are L2-Connected
- #47 The hitless failover has been possible thanks to the following 8.0 features: Full clients state is sync’ed to the S-UAC, where multiple GSM objects are copied over: sta, user, mac_user, ip_user, ky_cache, pmk_cache Hi-value sessions like FTP, Telnet, SSH and DPI qualified sessions are duplicated and remain ‘dormant’ in the data plane No client de-auth with failover to S-UAC