250 likes | 398 Views
Module 14. Redundancy Removing the Single Point of Failure. Objectives. Explain the different types of redundancy Identify controller cluster fundamentals Describe key configuration elements Describe the process of license aggregation
E N D
Module 14 Redundancy Removing the Single Point of Failure
Objectives • Explain the different types of redundancy • Identify controller cluster fundamentals • Describe key configuration elements • Describe the process of license aggregation • Describe various use cases to address different types of redundancy • Explain AAA Failover • Describe DHCP redundancy • Identify key considerations and best practices clustering controllers
Introduction • WiNG5 supports various redundancy mechanisms including:
Clustering – Introduction • Clustering can be enabled between multiple Wireless Controllers to provide redundant services such as: • Access Point Adoption • License Aggregation • Access Point Failover and Reversion • DHCP Redundancy • Dynamic Access Point Load-Balancing • Clusters are now truly managed by a single management interface • Master configuration is synchronized between Cluster members • System wide events and statistics are available from any management interface • The supported number of controllers per cluster in WiNG5.2 is 2
License Aggregation • As with previous WiNG releases, Access Point and Adaptive Access Point licenses are shared between Wireless Controllers in the Cluster • Cluster of 2 controllers with 24 and 0 licenses will have 24 licenses total • Licenses persist across reboots • Still, controller will not support more APs that it can physically handle (HW Capacity) • Cluster of 2 RFS4000 (36 AAP licenses each) with 37 AAPs will have 72 licenses, but will be able to support only 36 AAPs when one switch is down. • HW capacity is different for Centralized forwarding (traffic goes through controller) and Adaptive/Distributed forwarding
Feature Licenses • Feature licenses are installed per Wireless Controller and are not shared within the Cluster • Advanced Security License: • One license is required per Wireless Controller managing Access Points where roles are being assigned to Wireless Clients • Advanced WIPS License: • One license is required per Wireless Controller that are defined as AirDefense Servers
Configuration Synchronization • The master configuration is synchronized between all Wireless Controllers in a cluster • One Wireless Controller in the cluster is elected as a Master • Changes made to the configuration on ANY Wireless Controller using the CLI or WiNG5 UI are made to the master’s config (when committed) and then propagated to slaves • Thus, when cluster forms, slave’s config is overwritten by master • Make sure you have set up networking for slave in the master’s config! Cluster = Corp rfs7000-4# rfs7000-4(config)# rfs7000-4(config-profile-corp-rfs7000)# rfs7000-4(config-profile-corp-rfs7000)# rfs7000-4(config-profile-corp-rfs7000)# rfs7000-4(config-profile-corp-rfs7000)# configure terminal profile rfs7000 corp-rfs7000 use firewall policy corp commit write memory rfs7000-1 rfs7000-2 rfs7000-3 rfs7000-4 (Master) rfs7000-5 rfs7000-6
Clustering – Options Peers • The following configuration options are available: • Cluster Name: Unique name for the cluster which is shared by all participating Wireless Controllers • Cluster Mode: Active or Standby • Peers: • L2 cluster links: VLAN ID that can be used to reach other cluster members • L3 cluster links: IP Address of each peer • Master priority (0-255): highest priority will become the master • Profile and device overrides may be used: • Ex: use profile to set cluster name and peers • Ex: use overrides to set master priority, mode and other local tweaks Device Profile Custer Name Cluster Mode
Example Use Case 1 (Active / Standby | Active / Active) Device License: AP: 48 AAP: 256 Cluster License: AP: 48 AAP: 256 Device License: AP: 0 AAP: 0 Cluster License: AP: 48 AAP: 256 Device License: AP: 0 AAP: 0 Cluster License: AP: 48 AAP: 256 ! rfs6000 00-15-70-A3-2B-9B use profile corp-rfs6000 use rf-domain branch hostname rfs6000-2 ip route 0.0.0.0/0 192.168.10.1 interface vlan 10 ip address 192.168.10.16/24 allow-management .. cluster name Cluster1 cluster member ip 192.168.10.15 cluster mode standby ! ! rfs6000 00-15-70-81-A2-9A use profile corp-rfs6000 use rf-domain branch hostname rfs6000-1 ip route 0.0.0.0/0 192.168.10.1 interface vlan 10 ip address 192.168.10.15/24 allow-management .. cluster name Cluster1 cluster member ip 192.168.10.16 ! Active/Standby Active Standby Active L3 MiNT Link Device License: AP: 24 AAP: 64 Cluster License: AP: 48 AAP: 96 Device License: AP: 24 AAP: 32 Cluster License: AP: 48 AAP: 96 ! rfs6000 00-15-70-81-A2-9A use profile corp-rfs6000 use rf-domain branch hostname rfs6000-1 ip route 0.0.0.0/0 192.168.10.1 interface vlan 10 ip address 192.168.10.15/24 allow-management .. cluster name Cluster2 cluster member vlan 11 ! ! rfs6000 00-15-70-A3-2B-9B use profile corp-rfs6000 use rf-domain branch hostname rfs6000-2 ip route 0.0.0.0/0 192.168.10.1 interface vlan 10 ip address 192.168.10.16/24 allow-management .. cluster name Cluster2 cluster member vlan 11 ! Active/Active Active Active L2 MiNT Link
Clustering – Enabling Cluster (WiNG 5.2+) • On the Primary controller • Configure all Policies, RF Domains, WLANs, etc… • Configure Cluster Name • On the Secondary controller • Configure IP connectivity to the Primary controller • Static IP preferred • Issue join-cluster CLI command with IP of the primary controller and admin username/password • This is to prevent someone else joining the cluster • Secondary controller will join cluster • Primary will add the device section of the Secondary into the Master Config and also add all the APs of the Secondary • Secondary will download Master Config from the Primary • All WLANs, policies, etc on the Secondary will be lost
Building a Cluster 1 On one Wireless Controller build the master configuration for the network In the master configuration define the profile and device configuration for each member Wireless Controller that will be added to the Cluster The member switch(es) will establish MiNT link(s), join the cluster and pull down the master configuration (which includes profiles, policies and device configuration) 2 4 Copy this configuration to each other cluster member 3
Considerations 1 Maximum of 2 Wireless Controllers per cluster group All Wireless Controllers in the cluster must be running the same firmware version Wireless Controllers cannot adopt more Access Points than their hardware capacity allows It is recommended that cluster configuration be performed using device overrides rather than Profiles as MiNT links on each device will be unique Access Point and Adaptive Access Point licenses are persistent until clustering is disabled on the Wireless Controller 2 4 5 6 The master configuration is automatically synchronized between cluster members so that all Wireless Controllers have the same configuration file 3
Introduction AP-650 Access Point • Each Access Point and Wireless Controller now supports Primary and Secondary firmware images • Either the Primary or Secondary firmware image is operational on the device at any one time: • Current Boot: Current firmware image operating on the device • Next Boot: The firmware image that will be loaded during the next device reboot • Software Fallback is enabled by default on all devices: • If the selected firmware image is corrupted, this allows the device to fallback to the previous firmware version Primary Firmware Image Secondary Firmware Image AP-7131 Access Point Primary Firmware Image Secondary Firmware Image Wireless Controller Primary Firmware Image Secondary Firmware Image
Introduction • AAA redundancy can be achieved by: • Deploying two or more RADIUS servers or enabling RADIUS services on two or more Wireless Controllers and Access Points • Defining a AAA Policy with a pool of two or more AAA server entries with fail-over enabled • WiNG5 can provide fail-over between up to 6 AAA Servers in a pool Failover AAA Server 1 AAA Policy AAA Server 2 WLAN Centralized AAA Server Centralized AAA Server Centralized AAA Server Local Wireless Controller Centralized Wireless Controller Local Access Point Failover Failover Failover Secondary Secondary Secondary Primary Primary Primary
Introduction • The DHCP protocol does not provide any standard native mechanisms that allow DHCP servers to co-operate and provide redundancy • WiNG5 still can offer two scenarios with DHCP redundancy : • Using external DHCP servers • Using WiNG5 built-in DHCP servers and cluster
External (Centralized) DHCP • DHCP redundancy using external DHCP servers is achieved by enabling duplicate scopes on both DHCP servers each providing 50% of the available IP addresses in the pool (non overlapping) • DHCP forwarding must be enabled on IP routers with two helper addresses defined, one for each DHCP server • Both DHCP servers will receive the DHCP discover packets from DHCP clients • Both DHCP servers will respond to the DHCP client with a lease • The DHCP client will select one address from both offers • The DHCP client will send an ACK for the selected lease and the IP address that is not selected will remain available in the pool DHCP Pool: Users1 Subnet: 172.16.200.0/24 Range: 172.16.200.50-250 Exclude: 172.16.200.150-250 DHCP Pool: Users1 Subnet: 172.16.200.0/24 Range: 172.16.200.50-250 Exclude: 172.16.200.50-149 DHCP Pool: Users2 Subnet: 172.16.201.0/24 Range: 172.16.201.50-250 Exclude: 172.16.201.50-149 DHCP Pool: Users2 Subnet: 172.16.201.0/24 Range: 172.16.201.50-250 Exclude: 172.16.201.150-250 DHCP Pool: Users3 Subnet: 172.16.203.0/24 Range: 172.16.203.50-250 Exclude: 172.16.203.150-250 DHCP Pool: Users3 Subnet: 172.16.203.0/24 Range: 172.16.203.50-250 Exclude: 172.16.203.50-149 DHCP Server 1 172.16.10.5/24 DHCP Server 2 172.16.20.5/24 ! Interface vlan 100 ip address 172.16.100.1/24 ip helper-address 172.16.10.5 ip helper-address 172.16.20.5
Build-In DHCP (Clustering) • DHCP redundancy can be provided by • Deploying two or more Wireless Controllers in a Cluster with a common DHCP Policy • Enabling DHCP redundancy in the Cluster configuration (Profile or Overrides) • The Wireless Controller with the lowest IP address will become the active DHCP server for the site • If the elected Wireless Controller fails, the next available Wireless Controller (with the lowest IP address) will become the active DHCP server IP: 172.16.10.10/24 DHCP: Active IP: 172.16.10.11/24 DHCP: Standby Pool & Options DHCP Server Policy Pool & Options DHCP Server Policy DHCP Server Policy DHCP Server Policy Device Profile IP: 172.16.10.13/24 DHCP: Standby
LAB: Redundency LAB10: Clustering and AP Steering Configure Primary controller for clustering Form and verify the cluster Configure and test AP Steering Examine failover behaviour of Local and Tunnelled VLANs
Explain the different types of redundancy • Identify controller cluster fundamentals • Describe key configuration elements • Describe the process of license aggregation • Describe various use cases to address different types of redundancy • Explain AAA Failover • Describe DHCP redundancy • Identify key considerations and best practices clustering controllers • Module Summary