Best practices to deploy high-availability in Wireless LAN Architectures Simone Arena Wireless Networking Group, TME
Abstract The proliferation of Wi-Fi enabled devices creates a significant challenge for IT organizations to create the same level of service and support on the wireless network as there currently is on the wired network. The primary goal of this session is to provide design guidance and share best practices around building reliable and highly available Wireless LAN networks. This session will review wireless design architectures including FlexConnect, RRM and software upgrade algorithms. Best practice and design guidance for achieving high availability for all components of the Cisco Wireless LAN network: NCS/Prime Infrastructure, WLC, APs and MSE will be covered in-depth. This session is applicable for attendees responsible for the design, deployment, operations, and management of highly available Wireless LAN Networks. 3
What is High Availability? High Availability Is this HA???? 4
Planned downtime Failover End-to-end access Redundancy Cost $$$$ Clustering/Pooling Survivability Performance High Availability Productivity Session Objectives Learn the Design Recommendations, Configuration Best Practices, Deployment tips, to have your wireless network.. ALWAYS ON 5
Agenda Ok..so what are we really talking about? Radio Frequency (RF) High Availability (HA) Site Survey, RRM, CleanAir Network Infrastructure HA Devices Physical layout Controller Redundancy and AP Failover AP Stateful Switchover (AP SSO) FlexConnect WAN and AAA Survivability Management and Mobility Services HA Prime Infrastructure Mobility Services Engine Conclusions 6
Radio Frequency High Availability RF HA is the ability to have redundancy in the physical layer. Creating a stable RF environment Dealing with coverage holes if an AP goes down How to mitigate an interference source Creating a pervasive, predictable RF environment 7
Radio Frequency High Availability Guidelines: Surveying for RF HA Rule of Thumb Want most radios at power level 3 Site Survey tools: Using Active Survey tools give you more info Examples: AirMagnet, Ekahau, Veriwave WaveDeploy Clients and AP should be same model as production network Get to know the area: Consider three dimensional radio propagation in multi-story buildings Be aware of perimeter and corner areas May not be optimal to start first survey with AP in corner Survey for lowest common client type and technology supported 802.11b/g, 802.11a, 802.11n Smartphones usually have lower power radio 8
Radio Frequency High Availability TX Power and Antenna gain comparison MacBook Pro ipad 3 iphone 4S iphone 5 Samsung S3 # Antennas 2.4 GHz 5 GHz 2 2 1 1 1 0 1 1 1 1 Antenna Gain (dbi) 2.4 GHz 5 GHz 4.6 7-0.26 4.5-1.5 n/a -1.4-2.9 Total Tx Pwr (dbm) 2.4 GHz 5 GHz 28 (20) 26 (23) ave-peak 16.5-25.5 17.5-26.4 ave-peak 17-25 n/a ave-peak 16-26 13-25 ave-peak 13-20 15-20 Source: Placeholder for Notes is 12pts 9
Radio Frequency High Availability RRM Radio Resource Management What are RRM s objectives? Provide a system wide RF view of the network To dynamically balance the infrastructure and mitigate changes Monitor and maintain coverage for all clients Manage Spectrum Efficiency so as to provide the optimal throughput under changing conditions What RRM does not do Substitute for a site survey Correct an incorrectly architected network Manufacture spectrum 10
Radio Frequency High Availability RRM How does it work? DCA Dynamic Channel Assignment Each AP radio gets a transmit channel assigned to it Changes in air quality are monitored, AP channel assignment changed when deemed appropriate (based on DCA cost function) TPC Transmit Power Control Tx Power assignment based on radio to radio pathloss TPC is in charge of reducing Tx on some APs but may also increase Tx by defaulting back to power level higher than the current Tx level CHDM Coverage Hole Detection and Mitigation Detecting clients in coverage holes Deciding on Tx adjustment (typically Tx increase) on certain APs based on (in)adequacy of estimated downlink client coverage 11
Radio Frequency High Availability RF Profiles RF Profiles allow the administrator to tune groups of AP s sharing a common coverage zone together. Selectively changing how RRM will operate the AP s within that coverage zone RF Profiles are created for either the 2.4 GHz radio or 5GHz radio Profiles are applied to groups of AP s belonging to an AP Group, in which all AP s in the group will have the same Profile Settings There are two components to this feature: RF Groups Existing capability No impact on channel selection algorithms RF Profile New from 7.2, providing administrative control over: Min/Max TPC values TPCv1 Threshold TPCv2 Threshold Data Rates
Radio Frequency High Availability CleanAir- Self Healing & Optimizing the Spectrum BEFORE Wireless interference decreases reliability and performance AFTER CleanAir mitigates RF interference improving reliability and performance Wireless Client Performance AIR QUALITY PERFORMANCE AIR QUALITY PERFORMANCE Spectrum intelligence solution designed to proactively manage the challenges of a shared wireless spectrum Who, what, when, where, and how with interference Enables the network to act upon this information 13
Power Power Radio Frequency High Availability Why CleanAir? The Industry s ONLY in-line high-resolution spectrum analyzer Typical Wi-Fi chipset Spectral Resolution at 5 MHz Cisco CleanAir Wi-Fi chipset Spectral Resolution at 156 KHz Microwave oven Microwave oven? BlueTooth BlueTooth Identification is fuzzy, best guess 32 times WiFi chip s visibility Limited ability to differentiate devices Accurate classification Devices lost in the noise Multiple device recognition Chip View Visualization of Microwave oven and BlueTooth Interference 14
Radio Frequency High Availability Client Link: Reduced Coverage Holes ClientLink Disabled ClientLink Enabled Lower Data Rates Source: Miercom; AirMagnet/Fluke Iperf Survey Higher Data Rates 15
Network Infrastructure HA
Network Infrastructure HA Campus Design: Resiliency Structure, Modularity and Hierarchy Access Distribution Si Si Si Si Si Si Core Si Si Distribution Si Si Si Si Si Si Access WAN Data Center Anchor WLC - 1 Internet Anchor WLC - 2 WLC -1 WLC -2
Network Infrastructure HA AP Physical connection How to connect the AP Create redundancy throughout the access layer by homing APs into different switches Access Distribution Core
Network Infrastructure HA Controller Physical connection Access How to connect the WLC Configure Link Aggregation (LAG) Only one LAG is supported per AireOS WLC On the connecting switch: Set mode to ON (no Aggregation Protocol) Terminates on different modules or blades Load-balancing method for Catalyst switches is src-dst-ip Distribution Core
Network Infrastructure HA Controller Physical connection: connecting to a VSS switch Cisco 5508 WLC can be attached to a Cisco Catalyst VSS switch pair 4 ports of Cisco 5508 are connected to active VSS switch 2 nd set of 4 ports of Cisco 5508 is connected to standby VSS switch In case of failure of primary switch traffic continues to flow through secondary switch in the VSS pair Catalyst VSS Pair Cisco 5508 20
Controller Redundancy and AP Failover
Controller Redundancy Dynamic mode Rely on CAPWAP to load-balance APs across controllers and populate APs with backup controllers (needs Mobility Group) Results in dynamic salt-and-pepper design Design works better when controllers are clustered in a centralized design Pros Easy to deploy and configure, less upfront work Cons Bigger operational challenges due to unpredictability More inter-controller roaming Longer failover times No fallback option in the event of controller failure If Dynamic mode is required, Cisco recommends to use it only for Layer 2 connected WLCs Deterministic redundancy or AP SSO is recommended AP1 AP2 AP3 AP4 AP5 AP6 AP7 AP8 AP9 WLC1 WLC2 22
Controller Redundancy Deterministic mode WLAN-Controller-A WLAN-Controller-B WLAN-Controller-C Primary: WLAN-Controller-A Secondary: WLAN-Controller-B Tertiary: WLAN-Controller-C Primary: WLAN-Controller-B Secondary: WLAN-Controller-C Tertiary: WLAN-Controller-A Primary: WLAN-Controller-C Secondary: WLAN-Controller-A Tertiary: WLAN-Controller-B Administrator statically assigns APs a primary, secondary, and/or tertiary controller Pros: Cons: Assigned from controller interface (per AP) or NCS/Prime Infrastructure (templatebased) You need to specify Name and IP if WLCs are not in the same Mobility Group Predictability: easier operational management Faster failover times Fallback option in the case of failover More flexible and powerful redundancy design options (1:1, N:1, N:N:1) More upfront planning and configuration 24
Controller Redundancy Deterministic: backup Controllers Backup controllers configured for all APs under Wireless > High Availability tab Used if there are no primary/secondary/tertiary WLCs configured on the AP The backup controllers are added to the primary discovery request message recipient list of the AP. 25
Controller Redundancy Deterministic: N+1 Design Redundant WLC in a geographically separate location WLAN-Controller-1 APs Configured With: Primary: WLAN-Controller-1 Secondary: WLC-BKP Redundant WLC need not be part of the same mobility group Configure high availability parameters to detect failure and faster failover NOC or Data Center WLC-BKP WLAN-Controller-2 APs Configured With: Primary: WLAN-Controller-2 Secondary: WLC-BKP Use AP priority in case of over subscription of redundant WLC HA SKU available in 7.4 for 5508, 7500 and 8500 controllers WLAN-Controller-n APs Configured With: Primary: WLAN-Controller-n Secondary: WLC-BKP 26
Controller Redundancy Deterministic: HA SKU No need to purchase licenses on backup WLC. When backup takes over 90-days counter is started Needs to be configured normally as you would do with the secondary controller (no auto synch). Supported on 5508, WiSM2, Flex7500 and 8510 Primary Controller: WiSM-2 License Count: 500 APs connected: 400 No licenses needed on secondary AIR-CT5508-HA-K9 Secondary Controller Max AP support: 500-25 475- APs 400 = 475 = APs Primary Controller : 2504 License Count: 50 APs connected: 25 27
Controller Redundancy Deterministic: 1+1 Design For every active primary controller there is a standby redundant controller. Redundant WLCs in a geographically separate location Layer-3 connectivity between the AP connected to primary WLC and the redundant WLC Configure High Availability parameters to detect failure and faster failover APs can be load balanced or not HA SKU available in 7.4 28
AP Failover
AP Failover Understanding the CAPWAP State Machine For Your Reference AP Boots UP Discovery Reset DTLS Setup Image Data Run Join Config 30
AP Failover Failover Principles: AP Boots UP Discovery Reset When configured with Primary and backup Controller: AP uses heartbeats to validate current WLC connectivity AP uses Primary Discovery message to validate backup WLC list (every 30 sec) DTLS Setup Join Config Image Data Run When AP looses 5 heartbeats it start join process to first backup WLC candidate Candidate Backup WLC is the first alive WLC in this order : primary, secondary, tertiary, global primary, global secondary. Failover is faster than Dynamic mode because AP goes back to discovery state just to make sure the backup WLC is UP and then immediately starts the JOIN process 31
AP Failover Fast Heartbeat AP sends HA heartbeat packets, by default every 1 sec Reduce the amount of time it takes to detect a controller failure When the fast heartbeat timer expires, the AP sends a 3 fast echo requests to the WLC for 3 times If no response primary is considered dead and the AP selects an available controller from its backup controller list in the order of primary, secondary, tertiary, primary backup controller, and secondary backup controller. Fast Heartbeat only supported for Local and Flex mode 33
AP Failover Failover Priority Critical AP fails over AP Priority: Critical Controller Assign priorities to APs: Critical, High, Medium, Low Critical priority APs get precedence over all other APs when joining a controller In a failover situation, a higher priority AP will be allowed in ahead of all other APs If controller is full, existing lower priority APs will be dropped to accommodate higher priority APs AP Priority: Medium Medium priority AP dropped 34
AP Stateful Switch Over (AP SSO)
High Availability before 7.3 code and AP SSO Summary of what we saw so far Primary/Secondary/Tertiary WLC need to be defined on each AP Each WLC configured separately and have their own unique IP Address Primary and Secondary Backup are configured Globally Fast Heartbeat can be used to speed up failover With Failover detection AP goes in Discovery State and CAPWAP State Machine is restarted Downtime between Failover may go up to 1.5 minutes depending upon number of APs Each WLC is managed and monitored separately by NCS/Prime Infrastructure
AP Stateful switchover (AP SSO) Overview True Box to Box High Availability i.e. 1:1 One WLC in Active state and second WLC in Hot Standby state Secondary continuously monitors the health of Active WLC via dedicated link Configuration on Active is synched to Standby WLC This happens at startup and incrementally at each configuration change on the Active CAPWAP state of APs is also synched APs do not go in Discovery state when Active WLC fails Downtime between failover reduced to 5-1000 msec in case failover AP SSO is supported on 5500 / 7500 / 8500 and WiSM-2 WLC Clients state is not synched, so Client SSO is not supported in 7.3 and 7.4 release Client will need to re-authenticate unless it s a FlexConnect AP with local switching
AP Stateful switchover (AP SSO) Overview Redundancy Management Interface To check gateway and peer reachability sending ICMP packets every 1 sec Notification to standby in event of box failure or manual reset Communication with Syslog, NTP, TFTP server for uploading configurations Should be in same subnet as Management Interface
AP Stateful switchover (AP SSO) Overview Redundancy Port To check peer reachability sending udp keep alive messages every 100 msec Notification to standby in event of box failure Configuration synch from Active to Standby (Bulk and Incremental Config) Auto generated IP Address where last 2 octets are picked from the last 2 octets of Redundancy Management Interface (First 2 octets are always 169.254) If NTP is not configured manual time synch is done from Active to Standby
AP Stateful switchover (AP SSO) Controller physical connectivity Active Controller 5500/7500/8500 have dedicated Redundancy Port. Only direct connection supported in 7.4 WiSM-2 WLC have dedicated Redundancy VLAN which is used to synch configuration from Active to Standby WLC Redundancy VLAN should be a non-routable VLAN, meaning a Layer 3 interface should not be created for this VLAN Redundancy Port Connectivity RP 1 RP 2 Hot Stand-by Controller To achieve HA between WiSM-2 WLCs it can be deployed in single chassis OR can also be deployed between multiple chassis using VSS Single Chassis Connectivity Multi Chassis Connectivity
AP Stateful switchover (AP SSO) Controllers pairing HA Pairing is possible only between same type of hardware and software version. Mismatch may result in Maintenance mode. HA Pairing happens when WLC is booting. Reboot of WLC is required after HA is enabled. While booting WLCs try to discover their pair (waits for 120 seconds) using Redundant Management Interface and Redundant Port. Once discovered Active WLC start syncing all configuration to Standby WLC via Redundant Port.
AP Stateful switchover (AP SSO) Controllers pairing While config is synching from Active to Standby WLC or Standby WLC is booting no config operation is possible on Active WLC. Active and Standby decision is not an automated election process. Active/Standby WLC is decided based on HA SKU (Manufacturing Ordered UDI) from 7.3 release onwards. WLC with HA SKU UDI will always be Standby WLC For existing WLCs Active/Standby decision can be made based on configuration. No configuration is possible on Standby WLC
AP Stateful switchover (AP SSO) Controller Pairing: Maintenance Mode Standby WLC may transition to Maintenance Mode Non reachability to Gateway via Redundant Management Interface WLC with HA SKU which had never discovered peer Redundant Port is down WLC should be rebooted to bring it out of Maintenance Mode Only Console and Service Port is available in Maintenance and Standby Mode Telnet / SSH / SNMP / Web Access is not available on Management and Dynamic interface in Maintenance and Standby Mode No Web Access in available on Service Port when HA is enabled.
AP Stateful switchover (AP SSO) Controller Failover Failover in HA can be categorized as Box Failover Box Failover can occur due to software crash, software hang, manual reset and force switchover. Failover time will vary from 5-200 msec*. Box Failover can also occur due to power failure or unhandled software hang/crash. Failover time varies from 325-1000 msec*. Client SSO is not supported. AP SSO will de-auth clients (with an exception for Flex Local Switching clients). Clients have to start fresh association on new Active WLC. After failover clients in mobility setup will deauth and come up as new client. * Failover time is dependent on number of APs and AP Mode
AP Stateful switchover (AP SSO) Controller failover: process in detail For Your Reference Standby WLC keep sending keepalive messages on Redundant Port every 100 msec to check the state of Active WLC If Active does not acknowledge keepalive message, Standby WLC will immediately send ICMP packet to Active s Redundant Management Interface to check the status via infra network. Active Controller HA Cloud RP 1 RP 2 Hot Stand-by Controller Standby WLC retransmit Keepalive message on Redundant Port after 75 msec. If keepalive is not acknowledged ICMP packet is sent again via Redundant Management interface. Active Connection Redundant Connection This process is repeated 3 rd time and this time keepalive is sent after 50 msec followed by ICMP packet on infra network if 3 rd keepalive packet is also not acknowledged. AP 1 AP 2 After failure of 3 rd Keepalive and ICMP packet Switchover will trigger and Standby WLC will take over the network serving as Active WLC. Anytime in the middle if there is response for ICMP packet, Switchover will not happen.
AP Stateful switchover (AP SSO) Configuration (mandatory) Mandatory Configuration for HA setup: Redundant Management IP Address Peer Redundant Management IP Address Redundancy Mode set to SSO enable (by default is disabled) Primary/Secondary Configuration Required if peer WLC s UDI is not HA SKU CLI Configuration: HA Configuration can be done from Configuration Wizard
AP Stateful switchover (AP SSO) Configuration (optional) Optional Configuration for HA setup Peer Service Port Config Peer Route Config Keep Alive Timer (Default timer 100 msec, Range 100-400 msec in multiple of 50) Peer Search Timer (Default timer 120 sec, Range 60-180 sec) Mobility MAC Configuration should be used to have control on MAC Address for mobility peer. If not configured Active WLC MAC address will always be used for mobility tunnel to come up. Force Switchover Manual Peer Reset CLI Configuration
AP Stateful switchover (AP SSO) Configuration via GUI By default HA is disabled. Configure Redundant Management and Peer Redundant Management IP first before enabling AP SSO
AP Stateful switchover (AP SSO) Configuration by GUI Configure AP SSO selecting Enable from drop down: All other optional configuration like Service Port Peer IP, Mobility MAC Address, Keep Alive and Peer Search Timer can be configured on same page To Reset Peer WLC click on Commands -> Redundancy -> Reset Peer
AP Stateful switchover (AP SSO) Important things to know Physical connection between Redundant Port and Infrastructure Network should be done first before HA configuration Keepalive and Peer Discovery timers should be left with default timer values for better performance Clear configuration on Active WLC will also initiate clear config on Standby WLC. Internal DHCP is not supported when HA configuration is enabled. GARP is sent for all the interfaces after switchover. 3 GARP packets are sent out after SSO. Standby WLC sends GARP only for Redundant Management Interface while booting. L2 MGID is synched but L3 MGID database is cleared with SSO Location and Rogue information is not synched. When HA is disabled on Active it will be pushed to Standby and after reboot all the ports will come up on Active and will be disabled on Standby.
AP Stateful switchover (AP SSO) Checking configuration To check the Redundancy Status and Switchover History Total 10 history counts are maintained for switchover.
AP Stateful switchover (AP SSO) Integration with existing Controller Redundancy model AP SSO can be deployed with Secondary and Tertiary Controllers Both Active and Standby combined in AP SSO setup are configured as primary. On failure of both Active and Standby WLC in AP SSO setup, APs will fall back to secondary and further to configured tertiary controller.
AP Stateful switchover (AP SSO) Integration with existing Controller Redundancy model When AP SSO is setup, by default Primary WLC mac-address is synched as Mobility Mac Address on standby WLC which should be used to form a mobility peer Custom MAC can also be configured as Mobility Mac instead of using Active WLC mac-address Mobility mac address should be configured before forming High Availability pair. Once HA pair is formed mobility mac cannot be changed or edited.
AP Stateful switchover (AP SSO) Licensing HA Pair with HA SKU License on one WLC HA SKU is a new SKU with Zero AP Count License The device with HA SKU becomes standby first time it pairs up AP-count license info will be pushed from Active to Standby On event of Active failure HA SKU will let APs join with AP-count obtained and will start 90-day count-down. The granularity of the same is in days. After 90-days, it starts nagging messages.won t disconnect connected APs With new WLC coming up HA SKU, at the time of paring, the Standby will get the AP Count: If new WLC has higher AP count than previous, 90 days counter is reset. If new WLC has lower AP count than previous, 90 days counter is not reset. Elapsed time and AP-count are remembered on reboot
AP Stateful switchover (AP SSO) Licensing HA Pair with both the WLC having Valid AP Count License Active / Standby WLC decided based on configuration. To be configured as Standby, WLC needs at least a minimal license count for that platform to be active (ex. 50 APs for 5508) AP-count license info will be pushed from Active to Standby In the event of a switch over, the new Active will operate with the license count of the previous Active and will start 90-day count-down. Rest of the behavior is same as defined for HA SKU HA Pair with one WLC running Evaluation License and other WLC with HA SKU The device with HA SKU becomes standby first time it pairs up with an existing Active WLC running Evaluation License AP-count license info will be pushed from Active to Standby In the event of a switch over, the new Active will operate with the license count of the previous Active and will start 90-day count-down. Rest of the behavior is same as defined for HA SKU
FlexConnect and WAN Survivability
FlexConnect overview Management and data plane are split Data Plane can be: Centralized (split MAC architecture) Local (local MAC architecture) Two modes of operation: Connected (when WLC is reachable) Standalone (when WLC is not reachable) Traffic Switching is configured per AP and per WLAN (SSID) From 7.3 split tunneling is supported on a WLAN basis FlexConnect Group: Defines the Key caching domain for Fast Roaming, allows backup Radius scenarios Centralized Traffic Central Site WAN Local Traffic Cluster of WLC Centralized Traffic Remote Office
FlexConnect Overview Feature Limitations For Your Reference Some features are not available in standalone mode or in local switching mode Local controller Web Auth in Standalone Mode Mesh AP VideoStream IPv6 L3 Mobility SXP TrustSec QoS override See full list in «FlexConnect Feature Matrix» : http://www.cisco.com/en/us/products/ps6366/products_tech_note09186a0080b3690b.shtml
FlexConnect Survivability: WAN Failure (or single central WLC failure) Central Site HA considerations: No impact for connected clients on locally switched SSIDs Disconnection for centrally switched SSIDs clients Static authentication keys are locally stored in FlexConnect AP New clients can join if authentication is based on static keys Fast roaming allowed within FlexConnect group for already connected clients Lost features RRM, CleanAir, WIDS, Location, other AP modes Web authentication, NAC Remote Site WAN Application Server Remote Office
FlexConnect Survivability: WLC failure with Primary/Secondary Central Site Secondary Primary HA considerations: No impact for locally switched SSIDs Disconnection of centrally switched SSIDs clients FlexConnect AP transitions to Standalone and then to Connected when joins the Secondary WAN When in Standalone mode, Fast roaming is allowed within the FlexConnect Group Remote Site Upon resync with Secondary, client sessions for local traffic are not impacted (provided that the configuration on the WLCs are identical) Application Server Remote Office
FlexConnect Survivability: WLC failure scenario with AP SSO Central Site Standby Active HA considerations: No impact for locally switched SSIDs Disconnection of centrally switched SSIDs clients FlexConnect AP will NOT transition to Standalone because AP SSO kicks in WAN AP will go straight to Connected mode with the Standby WLC Remote Site Client sessions for Local traffic are not impacted and this is really Client SSO Application Server Remote Office
FlexConnect Survivability : WAN/WLC Failure and AP reboots Central Site AP reboots with WAN down Central Switched WLANs will shutdown Web-auth WLANs will shutdown Local Switched WLANs will be up : Only Open, Shared and WPA-PSK are allowed Local 802.1x allowed with local AP authentication or local RADIUS Unsupported features RRM, CCKM, WIDS, Location, Other AP Mode, NAC WAN Application Server Remote Office
FlexConnect and AAA Survivability
FlexConnect Survivability: AAA server backup Central Site By default authentication is done centrally in connected mode When WLC/WAN fails, AP goes in Standalone mode In Standalone mode, the AP can be configured to authenticate new clients with backup RADIUS defined locally at the AP Backup AAA servers are configured at FlexConnect Group level Upon WAN/WLC failure: Existing connected clients stay connected New clients are authenticated to the locally defined AAA Local Backup RADIUS Central RADIUS WAN FlexConnect Group Remote Office
FlexConnect AAA server backup Configuration Define primary and secondary local backup RADIUS server under FlexConnect Group configuration
FlexConnect Survivability: AAA server on AP By default authentication is done centrally in connected mode When WLC/WAN fails AP goes in Standalone mode In Standalone, the AP can act as a AAA server Only EAP-FAST and LEAP and a max of 100 clients supported Upon WAN/WLC failure: Existing connected clients stay connected New clients are authenticated to the locally defined AAA Central RADIUS Remote Site Central Site WAN
FlexConnect AAA server on AP - Configuration Define users (max 100) and passwords Define EAP parameters (LEAP or EAP-FAST)
FlexConnect Survivability: FlexConnect Local Auth Central Site By default FlexConnect AP authenticates clients through central controller when in Connected mode Central RADIUS This feature allows AP to act as an Authenticator even in Connected mode AAA servers are defined at the FlexGroup level Useful HA scenarios: Local RADIUS Remote Site WAN WAN goes down and Local users are authenticated to Local site AAA WLC goes down and Local users are authenticated from AP to Central site AAA Remote Office
FlexConnect FlexConnect Local Auth: configuration
Management and Mobility Services HA
Network Control System/Prime Infrastructure (PI) High Availability PI runs in an active / standby (1:1) mode Secondary PI not accessible Requires same HW and SW - Physical-physical and virtual-virtual supported No database loss when failover occurs Failover can be Automatic or Manual. Failback is always manual If the standby PI doesn t receive 3 heartbeats (timeout 2 seconds) then either the standby PI will become active or email will be sent to network admin. Active Standby 76
Prime Infrastructure HA Health Monitor The Health Monitor (HM) is a process implemented in PI, that is the primary component that manages the high availability operation of the system. It displays valuable logging and troubleshooting information For Your Reference To get to the Health Monitor direct the secondary PI to the 8082 port https://< secondary PI ip address>:8082 Note if you navigate to the primary s port 8082 you will not be able to login as it is only available on the secondary PI 77
Prime Infrastructure HA Configuration of HA Feature For Your Reference The first step is to install and configure the Secondary PI. When configuring the Primary PI for HA, the Secondary PI needs to be installed and reachable by the Primary PI The following parameters must be configured on the primary PI: name/ip address of secondary PI email address of network administrator for system notification manual or automatic failover option Secondary PI must always be a new installation and this option must be selected during PI install process, i.e. standalone or primary PI cannot be converted to secondary PI. Standalone PI can be converted to HA Primary. 79
Prime Infrastructure HA Configuration cont. For Your Reference Verify that the configuration is complete on the HA Status tab. After initial deployment of PI, the entire configuration of primary PI is replicated to the host of the secondary PI This process can be time consuming and take up to a half hour to run After database is replicated on the delta of changes will be pushed over to the secondary PI 80
Mobility Service Engine HA
Mobility Service Engine (MSE) High Availability A heartbeat is maintained between the primary and secondary MSE When the primary MSE fails and the secondary takes over, the virtual address of the primary MSE is switched transparently. HA for all services supported; Failover times < 1 min No HA license or a second set of client/ WIPS license required Supports 1:1 & 2:1 configuration (2 primaries can be backed to one secondary) HA supports Network Connected and Direct Connected. Directly connected with a cable can help reduce latencies in heartbeat response times, data replication and failure detection times. WLC1 Primary MSE Virtual IP: 10.10.10.11 Eth0: 10.10.10.12 WLC2 Directly or network connected Secondary MSE Eth0: 10.10.10.13 PI 3 rd Party 82
MSE HA Deployment Considerations Only MSE Layer-2 redundancy is supported. Both the health monitor IP and virtual IP must be on the same subnet and accessible from the Network Control System (PI). Layer-3 redundancy is not supported. Supports automatic & manual failover / failback Physical to physical & virtual to virtual HA supported Every active primary MSE is backed up by another inactive instance. The secondary MSE becomes active only after the failover procedure is initiated. The failover procedure can be manual or automatic. Failover to Secondary WLC1 Directly or network connected Primary MSE Eth0: 10.10.10.12 WLC2 Secondary MSE Virtual IP: 10.10.10.11 Eth0: 10.10.10.13 PI 3 rd Party 83
MSE HA Configuration For Your Reference Additional config required under HA HA mode in Start up script Define secondary name & ip address 84
MSE HA Verification For Your Reference Status shows active under the HA Configuration Sync is complete 85
Conclusions Let s recap HA for wireless starts from a good RF Site survey! Know your environment Leverage RRM Implement the Cisco advanced features for RF HA is about deterministic behavior Create a blueprint for the wired network to support a HA wireless deployment Deterministic Controller failover Stateful switchover for wireless: AP SSO is the first step Remote site and branch office: leverage the HA capability of FlexConnect Wireless ALWAYS ON? We are getting there 86
87