EMEA Airheads- ArubaOS - Cluster Manager
•Download as PPTX, PDF•
2 likes•4,845 views
In this presentation, we will cover ArubaOS' Cluster Manager, a combination of multiple managed devices working together to provide high availability to all the clients and ensure service continuity when a failover occurs. Check out the webinar recording where this presentation was used: http://community.arubanetworks.com/t5/Wireless-Access/Technical-Webinar-Recording-Slides-ArubaOS-Cluster-Manager/td-p/297761 Register for the upcoming webinars: https://community.arubanetworks.com/t5/Training-Certification-Career/EMEA-Airheads-Webinars-Jul-Dec-2017/td-p/271908
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to EMEA Airheads- ArubaOS - Cluster Manager
Similar to EMEA Airheads- ArubaOS - Cluster Manager (20)
More from Aruba, a Hewlett Packard Enterprise company
More from Aruba, a Hewlett Packard Enterprise company (15)
Recently uploaded
Recently uploaded (20)
EMEA Airheads- ArubaOS - Cluster Manager
- 1. CLUSTER MANAGER Technical Climb Webinar 10:00 GMT | 11:00 CET | 13:00 GST May 30th, 2017 Presenter: Saravanan Moorthy saravanan.moorthy@hpe.com
- 2. 2 Welcome to the Technical 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 will be 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/)
- 5. 5 Agenda • Objectives • Clustering Highlights • Cluster Leader • Cluster Roles • Cluster Hitless Failover • Cluster Load Balancing • Cluster Manual/CLI (re)assignment of AP (and AP-group) to any controller
- 7. 7 HA/Fast-Failover: • The high availability: 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 in ArubaOS 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 Mobility Master 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: Mobility Master 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: Mobility Master Controller Cluster Controller Cluster (DMZ) Air Match
- 12. 12 Clustering for Mission Critical 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
- 14. 14 Highlights 1 Available ONLY with 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, 70xx and VMC supported 7210 7240 7220 7205 7030 7024 70 10 7005 7008VMC- 50 VMC- 250 VMC-1k Highlights
- 16. 16 Highlights 7024 5 72xx, 70xx and 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 Up to 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 Up to 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 Up to 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 Clustering and 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
- 22. CLUSTER LEADER
- 23. 23 How is a Cluster Leader Elected? 1 Hello Messages exchanged during Cluster Formation Mobility Master/Standby Headquarter MC MCMC
- 24. 24 How is a Cluster 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 does a 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 1 L2- Connected Cluster members sharing same VLANs 2 L3-Connected Cluster members NOT sharing same VLANs
- 27. 27 VLAN Probing: • CM process 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. CLUSTER ROLES
- 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/Standby1 AAC 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/Standby1 AAC 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. USER ANCHOR CONTROLLER (UAC)
- 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 a User 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. 39 CLI Output:
- 40. 40 CLI Output for Bucketmap:
- 41. 41 CLI Output for Bucketmap:
- 43. 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
- 45. 45 Cluster Hitless Failover 1 Redundancy 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
- 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 cluster members 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 LB process 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 • Cluster redundancy 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 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
- 58. 58 Questions ?
- 59. THANK YOU!
Editor's Notes
- 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.
- 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.
- 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.
- 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.
- The following Mobility Controllers are supported: &2xx, 70xx and Virtual Mobility Controllers (VMC)
- 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)
- Cluster capacity per platform: Up to 12 Mobility Controllers when using 72xx
- 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)
- 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.
- 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.
- 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)
- 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)
- 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.
- 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.
- 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
- 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
- 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.
- 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.
- 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
- 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