Wireless LAN Controller (WLC) Configuration Best Practices - PDF

Please download to get full document.

View again

of 13
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
Information Report

Recruiting & HR


Views: 23 | Pages: 13

Extension: PDF | Download: 1

Related documents
Wireless LAN Controller (WLC) Configuration Best Practices Document ID: Contributed by Cisco TAC Engineers. Mar 27, 2014 Contents Introduction Prerequisites Requirements Components Used Best Practices
Wireless LAN Controller (WLC) Configuration Best Practices Document ID: Contributed by Cisco TAC Engineers. Mar 27, 2014 Contents Introduction Prerequisites Requirements Components Used Best Practices Wireless/RF Network Connectivity Network Design Mobility Security General Administration How to Transfer the WLC Crash File from the WLC CLI to the TFTP Server Upload Core Dump File to an FTP Server User Friendliness Introduction This document offers short configuration tips that cover several Wireless Unified Infrastructure issues commonly seen in the Technical Assistance Center (TAC). The objective is to provide important notes that you can apply on most network implementations in order to minimize possible problems. Note: Not all networks are equal, therefore some tips might not be applicable on your installation. Always verify them before you perform any changes on a live network. Prerequisites Requirements Cisco recommends that you have knowledge of these topics: Knowledge of how to configure the Wireless LAN Controller (WLC) and Lightweight Access Point (LAP) for basic operation Basic knowledge of Control And Provisioning of Wireless Access Points (CAPWAP) protocol and wireless security methods Components Used The information in this document is based on these software and hardware versions: Cisco 5508 / 4400 / 7500 / Wireless Services Module (WiSM) / WiSM2 Series WLC that runs firmware Release 7.4 CAPWAP based Access Points, Series 1140 / 1260 / 3500 / 1600 / 2600 / 3600 Note: Any reference to 4400 WLCs is based on firmware Release 7.0. The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command. Best Practices Wireless/RF These are the best practices for wireless/radio frequency (RF): For any wireless deployment, always do a proper site survey in order to insure proper quality of service for your wireless clients. The requirements for voice or location deployments are more strict than for data services. Auto RF might help on channel and power settings management, but it cannot correct a bad RF design. The site survey must be done with devices that match the power and propagation behavior of the devices to be used on the real network. For example, do not use a B/G radio with omni antenna to study coverage if the final network uses 3600 dual radios for A and G with N data rates. You must carefully plan the process to disable or enable data rates. If your coverage is sufficient, it is often a good idea to slowly disable lower data rates one by one. Management frames like ACK or beacons will be sent at the lowest mandatory rate (typically 1Mbps) which slows down the whole throughput. It is also good to try not to have too many supported data rates so that clients downshifts their rate faster. Typically clients try to send at the fastest data rate they can and if the frame did not make it through, will retransmit at 1 data rate below that and so on until it goes through. The removal of some supported rates means that clients who retransmit a frame directly downshift several data rates, which increases the chance for the frame to go through at the second attempt. Remember that management frames are sent at the lowest mandatory rate. Multicast is sent at the highest mandatory rate. You might make a conscious decision to not disable all rates below 11Mbps (included) in order to stop the support of b only clients. CLI commands are : config b rate disabled/mandatory/supported rate list and config a rate disabled/mandatory/supported rate list . In the same related idea, limit the number of service set identifiers (SSIDs) configured at the controller. You can configure 16 simultaneous SSIDs (per radio on each access point (AP)), but as each WLAN/SSID needs separated probe responses and beaconing, the RF pollution increases as more SSIDs are added. The results are that some smaller wireless stations like PDA, WiFi Phones, and barcode scanners cannot cope with a high number of basic SSID (BSSID) information. This results in lockups, reloads, or association failures. Also the more SSIDs, the more beaconing needed, so less RF space is available for real data transmits. For RF environments that are clear spaces, like factories where there are access points in a large space without walls, it might be necessary to adjust the Transmit Power Threshold from the default of 65 dbm, to a lower value like 76 dbm. This allows you to lower the co channel interference (number of BSSID heard from a wireless client in a given moment). The best value is dependant on each site environmental characteristics, so it should be evaluated carefully with a site survey. Power Transmit Threshold This value, expressed in dbm, is the cut off signal level at which the Transmit Power Control (TPC) algorithm adjusts the power levels downward, such that this value is the strength at which the third strongest neighbor of an AP is heard. Some client software might encounter difficulties if it hears more than a certain fixed number of BSSIDs (for example, 24 or 32 BSSIDs.) When you reduce the transmit power threshold and hence the average AP transmit level, you can reduce the number of BSSIDs that such clients hear. Do not enable aggressive load balancing unless the network has a high density of access points available in the area, and never if there is voice over wireless. If you enable this feature with access points spaced too far away from each other, it might confuse the roaming algorithm of some clients and induce coverage holes in some cases. Network Connectivity These are the best practices for network connectivity: Do not use spanning tree on controllers. For most topologies, Spanning Tree Protocol (STP) that runs in the controller is not needed. STP is disabled by default. For non Cisco switches, it is recommended that you also disable STP on a per port basis. Enter this command in order to verify: Cisco Controller) show spanningtree switch STP Specification... IEEE 802.1D STP Base MAC Address... 00:18:B9:EA:5E:60 Spanning Tree Algorithm... Disable STP Bridge Priority STP Bridge Max. Age (seconds) STP Bridge Hello Time (seconds)... 2 STP Bridge Forward Delay (seconds) Although most of the controller configuration is applied on the fly , it is good idea to reload controllers after you change these configuration settings: Management address SNMP configuration Generally, the management interface of the WLC is left untagged. In this case, the packet sent to and from the management interface assumes the Native VLAN of the trunk port to which the WLC is connected. However, if you want the management interface to be on a different VLAN, tag it to the appropriate VLAN with the Cisco Controller config interface vlan management vlan id command. Ensure that the corresponding VLAN is allowed on the switchport and tagged by the trunk (non native vlan). For all trunk ports that connect to the controllers, filter out the VLANs that are not in use. For example in Cisco IOS switches, if the management interface is on VLAN 20, plus VLAN 40 and 50 are used for two different WLANs, use this configuration command at the switch side: switchport trunk allowed vlans 20,40,50 Do not leave an interface with a address, for example an unconfigured service port. It might affect DHCP handling in the controller. This is how you verify: (Cisco Controller) show interface summary Interface Name Port Vlan Id IP Address Type Ap Mgr ap manager LAG Static Yes example LAG Dynamic No management LAG Static No service port N/A N/A Static No test LAG Dynamic No virtual N/A N/A Static No Do not use link aggregation (LAG) unless all ports of the controller have the same Layer 2 configuration on the switch side. For example, avoid filtering some VLANs in one port, and not the others. When you use LAG, the controller relies on the switch for the load balancing decisions on traffic that come from the network. It expects that traffic that belongs to an AP always enters on the same port. Use only ip src or ip src ip dst load balancing options in the switch EtherChannel configuration. Some switch models might use unsupported load balancing mechanisms by default, so it is important to verify. This is how to verify the EtherChannel load balancing mechanism: switch#show etherchannel load balance EtherChannel Load Balancing Configuration: src dst ip EtherChannel Load Balancing Addresses Used Per Protocol: Non IP: Source XOR Destination MAC address IPv4: Source XOR Destination IP address IPv6: Source XOR Destination IP address This is how to change the switch configuration (IOS): switch(config)#port channel load balance src dst ip With the Cisco IOS Software Release 12.2(33)SXH6, there is an option for PFC3C mode chassis to exclude VLAN in the Load distribution. Use the port channel load balance src dst ip exclude vlan command in order to implement this feature. This feature ensures that traffic that belongs to a LAP enters on the same port. LAG while using VSS, or stacked switch (3750/2960) or Nexus VPC, should work as long as the fragments of an IP packet are sent to the same port. The idea is that if you go to multiple switches, the ports must belong to the same L2?entity? with regards of load balancing decisions. If you want to connect the WLC to more than one switch, you must create an AP manager for each physical port and disable LAG. This provides redundancy and scalability. Note: On Cisco model WLCs, you need at least three active physical ports in order to utilize the maximum capacity of 100 access points for each WLC. For Cisco model WLCs, you need two physical ports in order to utilize the maximum capacity of 50 access points for each WLC. Whenever possible, do not create a backup port for an AP manager interface, even if it is allowed in older software versions. The redundancy is provided by the multiple AP manager interfaces as mentioned earlier in this document. For multicast forwarding, the best performance and less bandwidth utilization is achieved through multicast mode. This is how to verify the multicast mode on the controller: (WiSM slot1 1) show network summary RF Network Name Web Mode... Enable Secure Web Mode... Enable Secure Web Mode Cipher Option High... Disable Secure Shell (ssh)... Enable Telnet... Enable Ethernet Multicast Mode... Enable Mode: Mcast Ethernet Broadcast Mode... Disable IGMP snooping... Disabled IGMP timeout seconds User Idle Timeout seconds ARP Idle Timeout seconds ARP Unicast Mode... Disabled Cisco AP Default Master... Disable Mgmt Via Wireless Interface... Disable Mgmt Via Dynamic Interface... Disable Bridge MAC filter Config... Enable Bridge Security Mode... EAP Over The Air Provisioning of AP's... Enable Apple Talk... Disable AP Fallback... Enable This is how to configure multicast multicast operations on the WLC command line: config network multicast mode multicast config network multicast global enable The multicast address is used by the controller in order to forward traffic to access points. It is important that it does not match another address in use on your network by other protocols. For example, if you use , it breaks mdns used by some third party applications. It is recommended that the address be in the private range ( , which does not include x and x.). It is also important that the multicast IP address be set to a different value on each WLC. You do not want a WLC that speaks to its access points to reach the APs of another WLC. If the access points are on a different subnetwork than the one used on the management interface, your network infrastructure must provide multicast routing between the management interface subnet and the AP subnetwork. Network Design These are the best practices for network design: For APs in local mode, configure the switch port with portfast. In order to do this, set the port to be connected as a?host? port (switchport host command) or directly with the portfast command. This allows a faster join process for an AP. There is no risk of loops, as the LWAPP AP never bridges between VLANs. Per design, most of the CPU initiated traffic is sent from the management address in the controller. For example, SNMP traps, RADIUS authentication requests, multicast forwarding, and so on. The exception to this rule is DHCP related traffic. You can also enable on each SSID radius interface overwrite and then the radius for this WLAN will be sent from the dynamic interface. However, this creates design issues with Bring Your Own Device (BYOD) flow and Change of Authorization (CoA). This is important to take into account when you configure firewall policies or design the network topology. It is important to avoid configuring a dynamic interface in the same sub network as a server that has to be reachable by the controller CPU, for example a RADIUS server, as it might cause asymmetric routing issues. Always configure the switchports in?access mode? for the APs in local mode. For the switchports in trunk mode that go to the APs in FlexConnect mode (that do local switching) and to the WLCs, always prune the VLANs in order to allow only the ones configured on the FlexConnect AP and WLC (as mentioned previously). In addition, enter the switchport nonegotiate command on those trunks in order to disable Dynamic Trunking Protocol (DTP) on the switchport and avoid the need for the AP/WLC to process frames that are not needed as they do not support DTP. Also, resources would be wasted on the switch, which would attempt to negotiate with a device that cannot support it. Mobility These are the best practices for mobility: All controllers in a mobility group should have the same IP address for a virtual interface. Historically, the IP address has been used in default configurations and by individuals. However, it is now a valid public IP address and therefore should not be used anymore. You should use a private IP address that does not route anywhere in your network. This is important for roaming. If all the controllers within a mobility group do not use the same virtual interface, inter controller roaming can appear to work, but the hand off does not complete and the client loses connectivity for a period of time. This is how to verify: (Cisco Controller) show interface summary Interface Name Port Vlan Id IP Address Type Ap Mgr ap manager LAG Static Yes management LAG Static No service port N/A N/A Static No test LAG Dynamic No virtual N/A N/A Static No The virtual gateway address must be not routable inside your network infrastructure. It is only intended to be reachable for a wireless client when connected to a controller, never from a wired connection. As a matter of fact, is now a valid public address so change it to anything unique and unroutable in your network was used in this example because it is still the default value. IP connectivity must exist between the management interfaces of all controllers. In most situations, all controllers must be configured with the same mobility group name. Exceptions to this rule are deployments on controllers for the Guest Access feature, typically in a Demilitarized Zone (DMZ). It is a safe trick to run all WLCs on the same software code versions in order to ensure you do not face inconsistent behaviors due to bugs present on some WLCs and not others. For software Release 6.0 and later, all versions are intercompatible for mobility purposes so it is not mandatory. Do not create unnecessarily large mobility groups. A mobility group should only have all controllers that have access points in the area where a client can physically roam, for example all controllers with access points in a building. If you have a scenario where several buildings are separated, they should be broken into several mobility groups. This saves memory and CPU, as controllers do not need to keep large lists of valid clients, rogues and access points inside the group, which would not interact anyway. Also, try to accommodate the AP distribution across controllers in the mobility group so that there are APs. For example, per floor or per controller, and not a salt and pepper distribution. This reduces intercontroller roaming, which has less impact on the mobility group activity. In scenarios where there is more than one controller in a mobility group, it is normal to see some rogue access point alerts about our own access points in the network after a controller reload. This happens due to the time it takes to update the access point, client and rogue lists between mobility group members. The DHCP Required option in WLAN settings allows you to force clients to do a DHCP address request/renew every time they associate to the WLAN before they are allowed to send or receive other traffic to the network. From a security standpoint, this allows for a more strict control of IP addresses in use, but also might have affects in the total time for roaming before traffic is allowed to pass again. Additionally, this might affect some client implementations which do not do a DHCP renew until the lease time expires. For example, Cisco 7921 or 7925 phones might have voice problems while they roam if this option is enabled, as the controller does not allow voice or signaling traffic to pass until the DHCP phase is completed. Some third party printer servers might also be affected. In general, it is a good idea not to use this option if the WLAN has non Windows clients. This is because the more strict controls might induce connectivity issues, based on how the DHCP client side is implemented. This is how you verify: (Cisco Controller) show wlan 1 WLAN Identifier... 1 Profile Name Network Name (SSID) Status... Enabled MAC Filtering... Disabled Broadcast SSID... Enabled AAA Policy Override... Disabled Number of Active Clients... 0 Exclusionlist Timeout seconds Session Timeout seconds Interface... management WLAN ACL... unconfigured DHCP Server... Default DHCP Address Assignment Required... Disabled Quality of Service... Silver (best effort) WMM... Disabled CCX AironetIe Support... Enabled CCX Gratuitous ProbeResponse (GPR)... Disabled Dot11 Phone Mode (7920)... Disabled Wired Protocol... None It is advisable to configure multicast mode for mobility. This allows the client to announce messages to be sent on multicast between mobility peers, instead of unicast sent to each controller, with benefits on time, CPU usage, and network utilization. Security This is how to verify: (WiSM slot1 1) show mobility summary Symmetric Mobility Tunneling (current)... Disabled Symmetric Mobility Tunneling (after reboot)... Disabled Mobility Protocol Port Mobility Security Mode... Disabled Default Mobility Domain Multicast Mode... Enabled Mobility Domain ID for r... 0x8e5e Mobility Keepalive Interval Mobility Keepalive Count... 3 Mobility Group Members Configured... 2 Mobility Control Message DSCP Value... 0 Controllers configured in the Mobility Group MAC Address IP Address Group Name Multicast IP Status 00:14:a9:bd:da:a Up 00:19:06:33:71: Up These are the best practices for security: It is a good idea to change the RADIUS timeout to 5 seconds. The default of 2 seconds is acceptable for a fast RADIUS failover, but probably not enough for Extensible Authentication Protocol Transport Layer Security (EAP TLS) authentication, or if the RADIUS server has to contact external databases (Active Directory, NAC, SQL, and so forth). This is how to verify: (Cisco Controller) show radius summary Vendor Id Backward Compatibility... Disabled Credentials Caching... Disabled Call Station Id Type... IP Address Administrative Authentication via RADIUS... Enabled Aggressive Failover... Disabled Keywrap... DisabledAuthentication Servers! This portion of code has been wrapped to several lines due to spatial! concerns. Idx Type Server Address Port State Tout RFC N Ena
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks

We need your sign to support Project to invent "SMART AND CONTROLLABLE REFLECTIVE BALLOONS" to cover the Sun and Save Our Earth.

More details...

Sign Now!

We are very appreciated for your Prompt Action!