It is mandatory to reload the controllers after you change these configuration settings:

• Management address

• SNMP configuration

• HTTPS encryption settings

• LAG mode (enable/disable)

• Licensing

• Do not use a file from one controller type into another, for example a 2500 into a 5520. Some fields, especially password data, may be lost. If you need to use files across controller models, use a file conversion tool https://cway.cisco.com/tools/WirelessConfigConverter/
• Do not do configuration changes when a configuration upload is in progress, to avoid any possible data corruption.
• As a precaution, always do a configuration backup before a code upgrade.

Configuration files may contain sensitive data. If you want to ensure password confidentiality, use the transfer upload encrypted file feature when doing configuration backups from the controller.

How to enable (replace with your 16 characters key):
(Cisco Controller) >transfer encrypt set-key <password>
(Cisco Controller) >transfer encrypt enable
How to verify:
(Cisco Controller) >transfer upload start
Mode............................................. TFTP
TFTP Server IP................................... 192.168.0.45
TFTP Path........................................ ./
TFTP Filename.................................... 5520-1.txt
Data Type........................................ Config File
Encryption....................................... Enabled

Restriction

This should be used in most scenarios.

In case of a controller crash, it is possible to enable automated upload of core dump for analysis to a FTP server, this file can be provided to TAC for further analysis. By default this feature is enabled

How to configure:

(Cisco Controller) >config coredump ftp <serverip> <filename>
(Cisco Controller) >config coredump enable

To validate the configuration:

(Cisco Controller) >show coredump summary
 Core Dump upload is enabled

Restriction

This should be used in most scenarios to facilitate data gathering in case of unexpected controller reload.

Related Documentation:

https://supportforums.cisco.com/t5/wireless-mobility-documents/how-to-find-amp-retrieve-wlc-s-crash-coredump-from-its-s-flash/ta-p/3145554

In recent releases (8.0.150.0, 8.2.160.0 and higher versions), the controller now supports a single file upload option to easily collect the most important support data in a simplified way. This will provide a bundle covering crash information, core files, configuration, RRM logs, and RF state data. It is advisable to always include this file when opening a TAC case, to have a good starting data set.

How to Upload (proceed with file upload mode as needed)

(Cisco Controller) >transfer upload datatype support-bundle

Restriction

This should be used in all scenarios.

Related documentation:https://www.cisco.com/c/en/us/td/docs/wireless/controller/8-6/config-guide/b_cg86/managing_configuration.html#diagnostic-support-bundle

It is recommended to use restart instead of reset system for the following scenarios to reduce network and service downtime and provide better serviceability:

• LAG Mode Change
• Mobility Mode Change
• Web-authentication cert installation
• Clear Configuration

The Fast Restart feature is supported on Cisco WLC 7510, 8510, 5520, 8540, and vWLC from release 8.1.

To restart the controller:

(Cisco Controller) >restart
The system has unsaved changes.
Would you like to save them now? (y/N) y
Updating HBL license statistics file Done.
Configuration Saved!
System will now restart! 
Updating license storage ...  Done.

When fast SSID changing is enabled, the controller allows clients to move faster between SSIDs, changing the client context between WLANs, instead of forcing a client delete and a wait time. From a security point of view, it is preferable the disable option, as there is full confirmation of all client state is deleted before it is allowed on another WLAN, that may have different security policies.

The enable option is advisable when Apple IOS clients are present, as these devices do not work properly with the "delete on WLAN change" behavior, and they may have the currently associated AP in a blocked list.

Restriction

This should be used in most scenarios to have it enabled for better interoperability. It must be disabled when using RADIUS NAC.

To enable fast SSID change:

(Cisco Controller) >config network fast-ssid-change enable

High Availability (HA) with Client SSO is a feature supported from controller version 7.4 and higher. This allows a pair of controllers to act as a single network entity, working in an active/standby scenario, while preserving AP and client states, and ensuring that devices will not have to authenticate in case of a failure on the current active controller.

Whenever allowed by the controller hardware type in use, it is advisable to take advantage of the HA SSO feature, to reduce any possible downtime in case of failure.

Restriction

This should be used in most scenarios.

Related Documentation:

High Availability (SSO) Deployment Guide

N+1 High Availability Deployment Guide

If load balancing is required on the WLAN, ensure that the controller has a global windows set to 5 clients or higher, to prevent association errors

Restriction

This should be used in most scenarios when Load Balancing feature is in use.

For large high density deployments, it is advisable to modify the default aggregate probe interval sent by access points. By default, the APs will update every 500ms about the probes sent by clients, this information is used by load balancing, band select, location and 802.11k features.

If there is a large number of clients and access points, it is advisable to modify the update interval, to prevent control plane performance issues in the WLC.

To change:

config advanced probe limit 50 64000

That would set it to 50 aggregated probe responses every 64 seconds.

Restriction

This should be used in most scenarios with very large count of access points and clients.

When configuring access points, always set the primary/secondary controller names, to control the AP selection during the CAPWAP join process. This can prevent "salt & pepper" scenarios that affect roaming time, make troubleshooting simpler and have a more predictive network operation.

To configure:

(Cisco Controller) > config ap primary-base <controller-name> <ap-name>

Restriction

This should be used in most scenarios.

Access points will generate syslog about important events for troubleshooting and serviceability. By default, they will use a local broadcast destination (255.255.255.255), to ensure that even when the AP is out of the box, it is possible to obtain some information about possible problems by doing a local capture.

For performance, security and ease of troubleshooting, it is recommended to set a unicast destination, and store the AP logs for later analysis in case of problems:

To configure for all access points that will join the controller:

(Cisco Controller) > config ap syslog host global <server-ip>

Restriction

This should be used in most scenarios.

If the RLDP feature is needed, use it only with monitor mode APs, to prevent performance and service impact to the wireless network.

(Cisco Controller) > config rogue ap rldp enable alarm-only monitor-ap-only

Restriction

This should be used in most scenarios.

For APs in local mode, or Flexconnect mode doing only central switched WLANs, configure the switch port with PortFast. To configure PortFast, 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 local mode APs never bridges traffic directly between VLANs.

The port can be set directly on access mode. Enable port fast, and remove any group membership with the command "switchport host", supported on most switch platforms

Note	For AP's in local mode, the round-trip latency must not exceed 20 milliseconds (ms) between the access point and the controller.

Restriction

For APs in Flex mode, local switching, need to be in trunk mode for most scenarios.

Related Documentation:

Configuring Spanning Tree PortFast

Using PortFast and Other Commands to Fix Workstation Startup Connectivity Delays

For APs in Flexconnect mode, when using locally switched WLANs mapped to different VLANs (AP switch port is on trunk mode), prune or limit the VLANs present on the port to match the AP configured VLANs.

Restriction

This should be used in most scenarios.

Related Documentation:

Global Traffic Forwarding Configurations

To optimize the TCP client traffic encapsulation in CAPWAP, it is recommended to always enable TCP MSS feature, as it can reduce the overall amount of CAPWAP fragmentation, improving overall wireless network performance. The MSS value should be adjusted depending of the traffic type and MTU of the WLC-AP path. In general, a 1300 bytes value is a good average, although it can be further optimized depending on your setup.

Restriction

This should be used in most scenarios.

Related Documentation:

Global Traffic Forwarding Configurations

To avoid unnecessary work of the controller data plane, it is advisable to always prune unused VLANs from the trunk ports arriving to the WLC, and only leave those that are configured as management and dynamic interfaces.

Restriction

This should be used in most scenarios.

Per design, most of the CPU initiated traffic is sent from the management address of the controller, for example, SNMP traps, RADIUS authentication requests, multicast forwarding, and so on.

The default exception to this rule is DHCP related traffic. By default, the WLC is in DHCP proxy mode, and all DHCP traffic related to a client, is sent from the interface corresponding to the WLAN where client is associated, with the WLC as relay agent and source IP. If the WLC is in DHCP bridge mode, the traffic is transparently bridged to the corresponding VLAN.

• From best practices point of view, using DHCP bridge or proxy modes is mostly equivalent and it depends on the specific scenario being deployed. In general, using proxy mode is preferable for security reasons, as it hides the DHCP server IP from clients.
• Ensure that DHCP mode matches across controllers in the same mobility group.

• It is possible to configure DHCP proxy mode per interface, or globally. If this is changed, ensure that the interface mode configuration matches all controllers in same WLAN mobility group.

Restriction

DHCP proxy mode generally fits most deployment scenarios. It may be necessary to disable when using an external DHCP relay, or for ISG DHCP as session initiator topologies.

Related Documentation:

Configuring DHCP Proxy

The controller has the ability to provide an internal DHCP server. This feature is not scalable and is normally used for a simple demonstration or proof-of-concept or for very small networks (low client count), for example in a lab environment. The best practice is not to use this feature in an enterprise production network.

Restriction

Internal DHCP should be disabled in most scenarios.

The show interface detailed management command is used to find if an internal DHCP server is configured. The primary DHCP server address is the same as the management IP address. See the following example:

(Cisco Controller) >show interface detailed management
Interface Name................................... management
MAC Address...................................... e0:2f:6d:5c:f0:40
IP Address....................................... 10.10.10.2
IP Netmask....................................... 255.255.255.0
IP Gateway....................................... 10.10.10.1
External NAT IP State............................ Disabled
External NAT IP Address.......................... 0.0.0.0
Link Local IPv6 Address.......................... fe80::e22f:6dff:fe5c:f040/64
STATE ........................................... NONE
Primary IPv6 Address............................. ::/128
STATE ........................................... NONE 
Primary IPv6 Gateway............................. ::
Secondary IPv6 Address........................... ::/128
..
Primary Physical Port............................ 1
Backup Physical Port............................. Unconfigured
DHCP Proxy Mode.................................. Global
Primary DHCP Server.............................. 10.10.10.2

Change the internal DHCP server (management IP address) to a production DHCP server:

(Cisco Controller) >config interface dhcp management primary <primary-server>
It is recommended to disable/clean up existing internal DHCP scope:
(Cisco Controller) >show dhcp summary
Scope Name                   Enabled          Address Range
	Scope1 	Yes      	10.10.10.100 -> 10.10.10.150 
To disable the scope:
(Cisco Controller) >config dhcp delete-scope <scope name> 
or
(Cisco Controller) >config dhcp disable <scope name>

WLC has a timeout for each client state (authentication, DHCP address negotiation, webauth pending, etc.). It is possible to change the default time allowed for a client to complete a successful address negotiation. This could be useful on some topology scenarios, for example, where the same SSID is served by 2 different controller groups that do not share a mobility relationship, and you want to force clients to be deleted and restart DHCP negotiation after an inter-controller roam.

By default, the timer is 120 seconds, and can be verified with:

(Cisco Controller) >show dhcp timeout
DHCP Timeout (seconds)................. 120

• Do not use a very short value, as it may lead to client disconnection on some scenarios. For example, on multi-controller mobility group, the initial client association may take up to 3 seconds to allow for L3 roaming negotiation. If the DHCP timer is set too low, it could cause unnecessary client disconnections, depending on the client DHCP discover request timers. The value should not be set lower than 10 seconds.

Restriction

In general, this is a configuration setting that does not need to be modified, and default values should be used.

Related Documentation:

Configuring a DHCP Timeout

Do not leave an interface with a 0.0.0.0 address. It might negatively affect DHCP handling in the controller.

Do not use addresses starting with 127.x.x.x as it can break Web Authentication feature.

To verify:

(Cisco Controller) >show interface summary
Interface Name        Port  Vlan Id   IP Address       Type     Ap Mgr 
--------------------  ----  --------  ---------------  -------  -----
ap-manager            LAG   15        192.168.15.66    Static   Yes 
example               LAG   30        0.0.0.0          Dynamic  No    
management            LAG   15        192.168.15.65    Static   No    
service-port          N/A   N/A       10.48.76.65      Static   No    

Note	Changing management IP address may require a WLC reload.

Restriction

This should be used in most scenarios.

It is recommended to configure a non-routable IP address for the virtual interface, ideally not overlapping with the network infrastructure addresses. Use one of the options proposed on RFC5737, for example, 192.0.2.0/24, 198.51.100.0/24, and 203.0.113.0/24 networks.

Restriction

This should be used in most scenarios.

To change the address:

(Cisco Controller) >config interface address virtual <new address>

• LAG mode is the preferred mode of operation, as it provides redundancy and additional network bandwidth (on some platforms)

  Restriction

  This should be used in most scenarios, except if a physical separation of traffic per ports is needed, and trunk mode is not acceptable

  Note	Changing WLC LAG state will require a WLC reload.

• When using Link aggregation (LAG) make sure 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.

• The controller relies on the switch for the load balancing decisions on traffic that come from the network, with “source-destination IP” as the typically recommended option. It is important to select a correct balancing configuration on the switch side, as some variations may have an impact on controller performance or cause packet drops on some scenarios, especially for 5520/8540/WISM2 models due to their hardware architecture, where traffic from different ports is split across different data planes internally.

• To verify the EtherChannel load balancing mechanism on switch side:

  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

  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 and above, 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 to implement this feature. This feature ensures that traffic that belongs to an LAP enters on the same port.
• For LAG scenarios, using VSS, 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 if you go to multiple switches, the ports must belong to the same L2 “entity” with regard to load balancing decisions.

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. It is not supported to have a WLC with a port up, without a corresponding AP manager interface.

• Do not create a backup port for an AP-manager interface. This was possible in older software versions. The redundancy is provided by the multiple AP-manager interfaces as mentioned earlier in this document.

Cisco recommends to use VLAN tagging for the management interface of the WLC, as this is required for High Availability deployments. For untagged interface, 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 command:

(Cisco Controller) >config interface vlan management <vlan-id> 

Ensure that the corresponding VLAN is allowed on the switchport and tagged by the trunk (non-native VLAN).

Restriction

This should be used in most scenarios, exception: for ME/2504/3504 small network deployment, with all devices (AP, WLC, clients) on same VLAN, which is a simple network, but has lower security

A "Black Hole" dynamic interface is a configuration scenario, where the dynamic interface VLAN configured on the controller, is not forwarded by the switch, or lacks any default gateway. Any client assigned to this interface, can't pass traffic or reach any network destination, with the goal of preventing a human configuration error, and reducing the possibility of traffic leaks.

This scenario is targeted for:

• Guest access or mobility auto-anchor: Configure a black hole interface on the foreign, to ensure that there is no traffic leak at foreign level, and that the only connectivity possible is through the anchor assigned interface
• AAA override: This ensures that all clients must get an assigned interface from the RADIUS server, or they can’t reach any network destination

Restriction

This should be used in most scenarios.

The multicast address is used by the controller to forward traffic to Access Points (APs). Ensure that the multicast address does not match another address in use on your network by other protocols. For example, if you use 224.0.0.251, it breaks mDNS used by some third party applications.

• Cisco recommends that the address be in the private range (239.0.0.0 – 239.255.255.255, which does not include 239.0.0.x and 239.128.0.x, as those ranges will cause L2 flood). Also, ensure that the multicast IP address is set to a different value on each WLC to avoid multicast packet duplication.

Restriction

This should be used in most scenarios.

Related Documentation:

More information about the selection of multicast addresses within the enterprise can be located here: https://www.cisco.com/c/dam/en/us/support/docs/ip/ip-multicast/ipmlt_wp.pdf

By default, Access Points have a default Cisco/Cisco username and password, with SSH and telnet disabled. It is advisable to configure a default password, to be applied as soon as they first join the controller:

(Cisco Controller) > config ap mgmtuser add username <username> password <password> secret <secret> all

Restriction

This should be used in most scenarios.

For increased security, configure 802.1X authentication between a lightweight access point (AP) and a Cisco switch. The AP acts as an 802.1X supplicant and is authenticated by the switch using EAP-FAST with anonymous PAC provisioning. This is configurable in the global authentication settings.

Restriction

This feature is supported across all releases for IOS APs (Wave1), and from 8.6 for Wave2 APs (AP-COS: 1800, 2800, 3800, 1560, 1540). This requires that Radius server supports EAP-FAST.

To configure the global authentication username and password for all APs, currently joined to the controller as well as any AP that will join the controller in the future:

(Cisco Controller) >config ap 802.1Xuser add username <ap-username> password <ap-password> all

To verify the configuration:

(Cisco Controller) >show ap summary
Number of APs.................................... 1
Global AP User Name.............................. globalap
Global AP Dot1x User Name........................ globalDot1x

The following is a sample configuration to enable 802.1X authentication on a switch port:

Switch# configure terminal
Switch(config)# dot1x system-auth-control
Switch(config)# aaa new-model
Switch(config)# aaa authentication dot1x default group radius
Switch(config)# radius-server host <ip_addr> auth-port <port> acct-port <port> key <key>
Switch(config)# interface gigabitethernet2/1
Switch(config-if)# switchport mode access
Switch(config-if)# dot1x pae authenticator
Switch(config-if)# dot1x port-control auto
Switch(config-if)# end

For increased security, confirm that HTTPS is enabled and HTTP is disabled for management access (default settings).

To confirm management Web Access configuration:

(Cisco Controller) >show network summary
RF-Network Name............................. default
Web Mode.................................... Enable
Secure Web Mode............................. Enable
Secure Web Mode Cipher-Option High.......... Disable
Secure Web Mode Cipher-Option SSLv2......... Disable

To disable HTTP management access:

(Cisco Controller) >config network webmode disable

To enable secure web mode:

(Cisco Controller) >config network secureweb enable

Restriction

This should be used in most scenarios.

By default, WLC allows low security crypto options for HTTPS negotiation to ensure backward compatibility, which are no longer considered strong enough in several scenarios. For security reasons, it is advisable to force the controller to use only strong cyphers with the high encryption command. This may cause some interoperability issues if the client connecting to HTTPS only supports legacy or limited crypto options, so it is advisable to do testing for possible issues. This is not a problem for most modern browsers and operating systems.

To see the state:

(Cisco Controller) >show network summary
RF-Network Name............................. default
Web Mode.................................... Enable
Secure Web Mode............................. Enable
Secure Web Mode Cipher-Option High.......... Disable
Secure Web Mode Cipher-Option SSLv2......... Disable

To enable higher crypto options for HTTPS for management GUI:

(Cisco Controller) > config network secureweb cipher-option high enable

To enable higher crypto options for HTTPS for webauth WLANS:

(Cisco Controller) > config network web-auth secureweb cipher-option high

Note	For release 8.2, the command " config network secureweb cipher-option high" applies to both management and webauth scenarios.

Note	Changing HTTP/HTTPS state will require a WLC reload.

Restriction

If management station has limitations on higher crypto options.

The Cisco Wireless LAN Controllers supports some older crypto option negotiation for HTTPS for compatibility reasons: SSLv2, SSLv3 support, and RC4 crypto preference. They are disabled by default, as they are affected by different protocol or cryptographic vulnerabilities, and only provided for backward compatibility.

The SSLv2 and RC4 options are deprecated on later releases, so it is no longer present.

These options are not needed on almost all scenarios, and only should be enabled on very specific corner cases for old HTTPS client connectivity to WLC management and webauth features.

To check if whenever they are enable (8.2 and older):

(Cisco Controller) > show network summary
RF-Network Name............................. 5500
Web Mode.................................... Enable
Secure Web Mode............................. Enable
Secure Web Mode Cipher-Option High.......... Enable
Secure Web Mode Cipher-Option SSLv2......... Disable
Secure Web Mode RC4 Cipher Preference....... Disable
Secure Web Mode SSL Protocol................ Disable
..

In 8.3 and higher:

(Cisco Controller) > show network summary
	RF-Network Name............................. 3500
DNS Server IP............................... 0.0.0.0
Web Mode.................................... Enable
Secure Web Mode............................. Enable
Secure Web Mode Cipher-Option High.......... Enable
Secure Web Mode SSL Protocol................ Disable
Web CSRF check.............................. Enable

To disable them:

config network secureweb sslv3 disable
config network secureweb  cipher-option rc4-preference disable
config network secureweb  cipher-option sslv2 disable

Restriction

This should be used in most scenarios.

Cross Site Request Forgery is a type of attacks where an unsuspected user is tricked to perform unwanted actions. Starting with 8.3, Cisco Wireless LAN Controllers have embedded CSRF protection across all the management web interface.

This is enabled by default, and there is no reason to disable it, unless required as workaround for some specific issue. It should have no impact when active.

How to check:

(Cisco Controller) >show network summary

RF-Network Name............................. beta
DNS Server IP............................... 0.0.0.0
Web Mode.................................... Enable
Secure Web Mode............................. Enable
Secure Web Mode Cipher-Option High.......... Disable
Secure Web Mode SSL Protocol................ Enable
Web CSRF check.............................. Enable
OCSP........................................ Disabled
..

How to enable:

config network secureweb csrfcheck enable

Restriction

This should be used in most scenarios.

Similar to secure web access, confirm that SSH is enabled and Telnet is disabled to the controller for better security.

To see the network summary:

(Cisco Controller) > show network summary
Web Mode.................................... Enable
Secure Web Mode............................. Enable
Secure Web Mode Cipher-Option High.......... Enable
Secure Web Mode Cipher-Option SSLv2......... Enable
Secure Shell (ssh).......................... Enable
Telnet...................................... Enable

To disable Telnet:

(Cisco Controller) > config network telnet disable

To enable SSH:

(Cisco Controller) >config network ssh enable

Restriction

This should be used in most scenarios.

The Cisco Wireless LAN Controllers support higher crypto protocol negotiation for SSH connections. This is disabled by default, as older SSH clients may not support these cypher offerings. If your client is compatible, it is recommended to enable this option. Always test compatibility before implementing across a production network.

To check if it is enabled:

(Cisco Controller) >show network summary
RF-Network Name............................. 3500
DNS Server IP............................... 0.0.0.0
Web Mode.................................... Enable
..
Secure Shell (ssh).......................... Enable
Secure Shell (ssh) Cipher-Option High....... Enable

To enable SSH High Crypto:

(Cisco Controller) > config network ssh cipher-option high enable

Restriction

If management station SSH client has limited support for higher crypto options.

802.11r is the IEEE standard for fast roaming, where the initial authentication handshake with the target AP (that is, the next AP that the client intends to connect to) is done even before the client associates to the target AP. This is called Fast Transition (FT), and by default, fast transition is disabled in releases before 8.3. As of 8.3, a new capability called Adaptive FT is enabled by default, which is used for Apple IOS devices (see Apple recommendations section).

Using either FT or Adaptive FT can lower the total usage of the authentication services, as clients can do secure roaming without incurring full authentication on each AP change, so this has benefits both in roaming speed and overall reduced authentication load.

Restriction

If using FT instead of Adaptive FT, non 802.11r clients may not be able to connect to the WLAN. Ensure that the clients are 802.11r capable, for example, Apple devices on version 6 and above, or split WLANs. Adaptive FT can be enabled for the WLANs in almost all scenarios with very low probability of interoperability problems.

To enable 802.11r or Fast Transition (FT):

(Cisco Controller) >config wlan security ft enable <WLAN id> 

To configure FT authentication management using 802.1X:

(Cisco Controller) >config wlan security wpa akm ft-802.1X enable <WLAN id> 

To configure FT authentication management using PSK:

(Cisco Controller) >config wlan security wpa akm ftp-psk enable <WLAN id>

Aironet IE is a Cisco proprietary attribute used by Cisco devices for better connectivity and troubleshooting. It contains information, such as the access point name, load, and number of associated clients in the beacon and probe responses of the WLAN that are sent by the access point (AP). Cisco Client Extensions (CCX) clients use this information to choose the best AP with which to associate.

The CCX software is licensed to manufacturers and vendors of third-party client devices. The CCX code on these clients enables them to communicate wirelessly with Cisco APs and to support Cisco features that other client devices do not. The features are related to increased security, enhanced performance, fast roaming, and power management.

The CCX software is licensed to manufacturers and vendors of third-party client devices. The CCX code on these clients enables them to communicate wirelessly with Cisco APs and to support Cisco features that other client devices do not. The features are related to increased security, enhanced performance, fast roaming, and power management.

To disable Aironet IEs for a particular WLAN:

(Cisco Controller) >config wlan ccx aironet-ie disable <wlan_id>Forwarding

Restriction

Do not disable this if supporting Cisco voice devices (8821/792x, etc) or WGB.

When a user fails to authenticate, the controller can exclude the client. The client cannot connect to the network until the exclusion timer expires or is manually overridden by the administrator. This feature can prevent authentication server problems due to high load, caused by intentional or inadvertent client security misconfiguration. It is advisable to always have a client exclusion configured on all WLANs.

Client Exclusion can act as a protective mechanism for the AAA servers, as it will stop authentication request floods that could be triggered by misconfigured clients.

Exclusion detects authentication attempts made by a single device. When the device exceeds a maximum number of failures, that MAC address is not allowed to associate any longer.

The Cisco WLC excludes clients when the following conditions are met:

• Excessive 802.11 Association Failures after five consecutive failures
• 802.1X Authentication Failures after three consecutive failures
• IP Theft or IP Reuse, if the IP address obtained by the client is already assigned to another device
• Excessive Web Authentication Failures after three consecutive failures

It is possible to configure how long a client remains excluded, and exclusion can be enabled or disabled at the controller or WLAN level.

Restriction

This should be used in most scenarios.

To verify exclusion policy:

(Cisco Controller) >show wps summary
Auto-Immune
  Auto-Immune.................................... Disabled
  Auto-Immune by aWIPS Prevention................ Disabled
Client Exclusion Policy
  Excessive 802.11-association failures.......... Enabled
  Excessive 802.11-authentication failures....... Enabled
  Excessive 802.1x-authentication................ Enabled
  IP-theft....................................... Enabled
  Excessive Web authentication failure........... Enabled
  Maximum 802.1x-AAA failure attempts............ 3

Related documentation:

Management Frame Protection

Peer-to-peer blocking is a per WLAN setting, and each client inherits the peer-to-peer blocking setting of the WLAN to which it is associated. Peer-to-peer enables you to have more control over how traffic is directed. For example, you can choose to have traffic bridged locally within the controller, dropped by the controller, or forwarded to the upstream VLAN.

This setting can prevent a client attacking another client connected to the same WLAN, but it is important to keep in mind that using the drop option will prevent any application that can communicate directly between clients, for example chat or voice services.

Restriction

Do not use for WLANs supporting voice or video services, or for any scenario where client to client direct communication is required.

Related Documentation:

WLAN Security

To verify the peer-to-peer blocking setting of the WLAN:

(Cisco Controller) >show wlan <wlan_id>
WLAN Identifier.................................. 1
Profile Name..................................... cckm-ft
Network Name (SSID).............................. cckm-ft
Status........................................... Enabled
...
...
Peer-to-Peer Blocking Action..................... Disabled
Radio Policy..................................... All

To configure a WLAN for peer-to-peer blocking:

(Cisco Controller) >config wlan peer-blocking { disable | drop | forward-upstream} <wlan_id>

Local EAP is an authentication method that allows users and wireless clients to be authenticated locally on the controller instead of using a Radius server. Using local EAP in an enterprise production environment is not recommended for scalability reasons.

To check if a WLAN is configured to use local EAP:

(Cisco Controller) >show wlan <WLAN id>
Radius Servers
Authentication................................ Global Servers
Accounting.................................... Global Servers
Interim Update................................ Disabled 
Framed IPv6 Acct AVP ......................... Prefix
Dynamic Interface............................. Disabled 
Dynamic Interface Priority.................... wlan
Local EAP Authentication...................... Disabled 
Radius NAI-Realm.............................. Disabled

To disable local authentication on a WLAN:

(Cisco Controller) >config wlan local-authen disable <WLAN id>

Restriction

This should be used in most scenarios.

From security standpoint, it is advisable to configure WLANs with WPA2 with AES encryption, and 802.1x authentication. Other security policies like open, WEP, WPA/TKIP, etc, should be avoided, unless absolutely needed for legacy client support. Using a pre-shared key as authentication is not recommended for enterprise environments, and should only be used for specific client compatibility scenarios. In these cases, a shared secret of 18 characters or more is advisable.

To create a WLAN with WPA2 and 802.1X enabled:

(Cisco Controller) >config wlan security wpa enable <WLAN id>

To configure RADIUS authentication server on specified WPA2/802.1X WLAN:

(Cisco Controller) >config wlan radius_server auth add <WLAN id> <Server id> 

To configure RADIUS accounting server on specified WPA2/802.1X WLAN:

(Cisco Controller) >config wlan radius_server acct add <WLAN id> <Server id

Restriction

This should be used in most scenarios.

To avoid any possible errors that could lead to clients being assigned to the WLC management VLAN, it is advisable not to configure any WLAN using management interface. In the scenario of an auto-anchored WLAN, where the foreign controller would forward all traffic to the anchor, it is still recommended to set the WLAN on the foreign to a "dummy" interface

Restriction

This should be used in most scenarios.

How to verify:

(Cisco Controller) >show wlan 1
WLAN Identifier.................................. 1
Profile Name..................................... simft
Network Name (SSID).............................. simft
Status........................................... Disabled
MAC Filtering.................................... Disabled
Broadcast SSID................................... Enabled
AAA Policy Override.............................. Enabled
Network Admission Control
Client Profiling Status
    Radius Profiling ............................ Disabled
     DHCP ....................................... Disabled
     HTTP ....................................... Disabled
    Local Profiling ............................. Enabled
     DHCP ....................................... Enabled (Auto)
     HTTP ....................................... Enabled (Auto)
  Radius-NAC State............................... Disabled
  SNMP-NAC State................................. Disabled
  Quarantine VLAN................................ 0
Maximum Clients Allowed.......................... Unlimited
Security Group Tag............................... Unknown(0)

…
Webauth DHCP exclusion........................... Disabled
Interface........................................ management

You must enforce a strong password. The password policies allow enforcement of strong password checks on newly created passwords for additional management users of controller and access point. The following are the requirements enforced on the new password:

• When the controller is upgraded from an old version, all the old passwords are maintained even though the passwords are weak. After the system upgrade, if the strong password checks are enabled, the same is enforced from that time and the strength of previously added passwords will not be checked or altered.
• Depending on the settings done in the Password Policy page, the local management and access point user configuration is affected.

To verify strong password check:

(Cisco Controller) >show  switchconfig
Strong Password Check Features    
case-check.................................... Enabled    
consecutive-check............................. Enabled    
default-check................................. Enabled    
username-check................................ Enabled    
position-check................................ Disabled    
case-digit-check.............................. Disabled
   Min. Password length.......................... 3
   Min. Upper case chars......................... 0
   Min. Lower case chars......................... 0
   Min. Digits chars............................. 0
   Min. Special chars............................ 0

To enable strong password check for AP and WLC:

(Cisco Controller) >config switchconfig strong-pwd {case-check | consecutive-check | default-check | username-check | all-check} 
{enable | disable},

case-check—Checks the occurrence of same character thrice consecutively.

consecutive-check—Checks the default values or its variants being used.

default-check—Checks either username or its reverse being used.

all-checks—Enables/disables all the strong password checks.

Restriction

This should be used in most scenarios.

Related documentation:

Managing Users

The user login policies are provided to limit the number of concurrent logins of the local netusers of the controller. You can limit the number of concurrent logins, and it is recommended to configure a value greater than default of 0 (unlimited login). Please be aware that this could impact network devices that may be sharing same username and password, for example wireless phones same user profile for their wireless connection.

To verify netuser limit:

(Cisco Controller) >show netuser summary 
Maximum logins allowed for a given user name..... Unlimited

To configure user login policies:

(Cisco Controller) >config netuser maxuserlogin 5

Restriction

For some radius servers: when the external identity of the EAP authentication is shared across multiple devices (no username attribute on access-accept), or when intentionally a single user account is shared across devices.

The WLC Management Via Wireless feature allows operators to monitor and configure local WLCs using wireless clients connected to the controller. It is advisable to disable the Management over Wireless feature for security reasons.

To verify management over wireless interface:

(Cisco Controller) >show network summary
RF-Network Name............................. default
Web Mode.................................... Enable
Secure Web Mode............................. Enable
Secure Web Mode Cipher-Option High.......... Disable
Secure Web Mode Cipher-Option SSLv2......... Disable
Secure Web Mode RC4 Cipher Preference....... Disable
…
Mgmt Via Wireless Interface................. Enable

To disable management over wireless:

(Cisco Controller) > config network mgmt-via-wireless disable

Restriction

This should be used in most scenarios.

Network Time Protocol (NTP) is very important for several features. It is mandatory to use NTP synchronization on controllers, if you use any of these features: Location, SNMPv3, Access point authentication, or MFP. The WLC supports synchronization with NTP using authentication.

To enable NTP server:

(Cisco Controller) >config time ntp server 1 10.10.10.1 

To verify, check for entries in your traplog:

30 Mon Jan 6 08:12:03 2014 Controller time base status - Controller is in sync with the central timebase.

To enable NTP authentication:

(Cisco Controller) >config time ntp auth enable <ntp server index>
(Cisco Controller) >config time ntp key-auth add <key index>

Restriction

This should be used in most scenarios.

The default timeout for EAP Identity requests may need to be increased for some scenarios. For example, when implementing One Time Passwords (OTP) on Smart Cards, or where the user interaction is needed to answer the initial identity request. In autonomous APs, the default timeout is 30 seconds. Consider this while migrating autonomous to infrastructure wireless networks.

To verify default timeouts:

(Cisco Controller) >show advanced eap
EAP-Identity-Request Timeout (seconds)........... 30
EAP-Identity-Request Max Retries................. 2
EAP Key-Index for Dynamic WEP.................... 0
EAP Max-Login Ignore Identity Response........... enable
EAP-Request Timeout (seconds).................... 30
EAP-Request Max Retries.......................... 2
EAPOL-Key Timeout (milliseconds)................. 1000 
EAPOL-Key Max Retries............................ 2 
EAP-Broadcast Key Interval....................... 3600

To change timeout (seconds):

(Cisco Controller) >config advanced eap identity-request-timeout <seconds>

The EAPoL timeout should be as minimal as possible for voice clients, such as IP 7925/882x phones. Normally 400 to 1000 milliseconds can work correctly on most scenarios.

The maximum retry counter has a direct implication on several of the KRACK attacks reported on 2017 for wireless clients using WPA/WPA2. If the counter is set to zero, it can prevent most attacks against clients that are not yet patched against the vulnerability. This has implications on authentications performed on bad RF scenarios, or over a WAN network with possible packet loss, as using zero may cause a failed authentication process, if the original packet is lost.

Restriction

For security reasons, it may be advisable to use zero retries, but please validate on your environment, as it may have impact on failed authentication for bad RF scenarios.

To show default timeouts:

(Cisco Controller) >show advanced eap
EAP-Identity-Request Timeout (seconds)........... 30
EAP-Identity-Request Max Retries................. 2
EAP Key-Index for Dynamic WEP.................... 0
EAP Max-Login Ignore Identity Response........... enable
EAP-Request Timeout (seconds).................... 30
EAP-Request Max Retries.......................... 2
EAPOL-Key Timeout (milliseconds)................. 1000 
EAPOL-Key Max Retries............................ 2
EAP-Broadcast Key Interval....................... 3600

To configure EAPoL timeout:

(Cisco Controller) >config advanced eap eapol-key-timeout <milliseconds>

To configure EAPoL retry counts:

(Cisco Controller) >config advanced eap eapol-key-retries <retries>

During the 802.1x authentication phase, in the event of an EAP retry due to packet loss or lack of response from client, the WLC may retry the EAP request. Some clients may not properly handle fast retry timers, so this may need adjustment depending on client types, to facilitate fast recovery for bad RF environments. Acceptable values may be around 10 seconds in most cases, up to 30 for slow clients (phones)

To show default timeouts:

(Cisco Controller) >show advanced eap
EAP-Identity-Request Timeout (seconds)........... 30
EAP-Identity-Request Max Retries................. 2
EAP Key-Index for Dynamic WEP.................... 0
EAP Max-Login Ignore Identity Response........... enable
EAP-Request Timeout (seconds).................... 30
EAP-Request Max Retries.......................... 2
EAPOL-Key Timeout (milliseconds)................. 1000 
EAPOL-Key Max Retries............................ 2 
EAP-Broadcast Key Interval....................... 3600

To configure EAP Request timeout:

(Cisco Controller) >config advanced eap request-timeout <seconds>

To configure EAP Request retry counts:

 (Cisco Controller) >config advanced eap request-retries <retries>

It is a best practice to increase the retransmit timeout value for TACACS+ authentication, authorization, and accounting servers, if you experience repeated re-authentication attempts or if the controller falls back to the backup server when the primary server is active and reachable. This is especially true when implementing One Time Password (OTP).

(Cisco Controller) >show tacacs summary 
Authentication Servers
Idx      Server Address        Port    State   Tout   MgmtTout
--- 	 --------------- 	------  -------  -----  -------
1     10.10.10.60 	49      Enabled  5      2         
         Authorization Servers
Idx      Server Address        Port    State   Tout   MgmtTout
---  ----------------   	------  -------  -----  -------
1    10.10.10.60 	49      Enabled  5      2         

To configure TACACS+ authentication retransmit timeout:

(Cisco Controller) >config tacacs auth server-timeout 1 <seconds>

To configure TACACS+ authorization retransmit timeout:

(Cisco Controller) >config tacacs athr server-timeout 1 <seconds>

Restriction

This should be used in most scenarios.

LEAP is an old simple EAP authentication protocol, used on some Cisco devices, and supported by several third party clients. The protocol is considered fully compromised, and its use could lead to man in the middle attacks, or password recovery of user credentials. It is currently only supported for legacy backwards compatibility.

It is strongly suggested to avoid using it in any scenario. It should be disabled on your authentication server (for example ISE or ACS), or if the using Local EAP feature in WLC.

Restriction

This should be avoided in most scenarios; including even legacy devices.

Enable the wireless IDS feature and 17 built-in signatures to detect intrusion attacks.

For this best practice feature to work, ensure that at least one WLAN is enabled and client exclusion-listing is enabled for the WLAN. To enable client exclusion-listing for a WLAN, use the conf wlan exclusionlist wlan-id enabled command.

Enable signature check by entering this command:

(Cisco Controller) >config wps signature enable

Restriction

This should be used in most scenarios.

Check on the SNMPv3 default user. By default, the controller is configured with a username that must be disabled or changed, otherwise this could represent a security risk.

To verify SNMPv3 default user:

(Cisco Controller) >show snmpv3user 
SNMP v3 User Name    AccessMode  Authentication Encryption   
-------------------- ----------- -------------- ----------   
default               Read/Write  HMAC-SHA       CFB-AES   

To configure SNMPv3 default user:

(Cisco Controller) >config snmp v3user delete default 
(Cisco Controller) >config snmp v3user create nondefault rw hmacsha des authkey <encrypkey12characters> 

Note	Ensure that your SNMP settings match between the controller and the Wireless Control System (WCS)/Network Control System(NCS)/Prime Infrastructure (PI). Also, you should use encryption and hash keys that match your security policies.

Note	Changing some SNMP settings may require a WLC reload.

Restriction

This should be used in most scenarios.

Check on the SNMP default communities. By default, the controller is configured with communities used to simplify initial connection to Prime Infrastructure(PI) services. These communities must be removed as they could represent a security risk in most deployments.

Restriction

This should be used in most scenarios.

To verify SNMP default user:

(Cisco Controller) >show snmpcommunity

IPSec mode: Disabled / Profile: none

SNMP Community Name Client IP Address                       Client IP Mask    Access Mode Status
------------------- -----------------                       ----------------- ----------- --------
public              0.0.0.0                                  0.0.0.0           Read Only   Enable
**********          0.0.0.0                                  0.0.0.0           Read/Write  Enable

To configure SNMP communities:

(Cisco Controller) config snmp community delete private 
(Cisco Controller) config snmp community delete public 
(Cisco Controller) >config snmp community create

Note	Ensure that your SNMP settings match between the controller and the Wireless Control System (WCS)/Network Control System(NCS)/Prime Infrastructure (PI).

RADIUS authentication and accounting servers should have 5 seconds as the minimum value for server timeout to prevent early expiration of client authentication process during load.

Set the timeout for RADIUS authentication and accounting servers by entering these commands:

(Cisco Controller) >config radius auth retransmit-timeout RADIUS-Server-ID timeout-in-seconds
(Cisco Controller) >config radius acct retransmit-timeout RADIUS-Server-ID timeout-in-seconds

Restriction

This should be used in most scenarios.

RADIUS aggressive failover should be disabled to get optimum performance for client authentication on a Cisco ISE server.

 (Cisco Controller) >config radius aggressive-failover disable

Restriction

This should be used in most scenarios.

Policy should be set at least to High.

Set the rogue detection security level to High by entering this command:

(Cisco Controller) >config rogue detection security-level high

The controller maintains a single channel scan list for the RRM metrics (Noise, Interference) and for Rogue detection monitoring. The list can be configured to focus on "DCA channels", those channels which will be automatically assigned to APs, or to "country channels", which would be those only valid in the configured country, or to scan all possible channels. This latter is the best option to ensure that any rogue using an uncommon channel can be detected properly. The drawback is that with a longer channel list, the AP will have to go off-channel more frequently inside the configured channel scan interval.

• For higher security, choose all channel.
• Choose DCA channels for performance, as system will scan as least as possible.
• For a balance of performance and security, choose country channel.

(Cisco Controller) > config advanced 802.11a monitor channel-list all
(Cisco Controller) > config advanced 802.11b monitor channel-list all

Define malicious rogue AP rules to prioritize major and critical rogue AP alarms that require immediate attention and mitigation plan.

Critical or major rogue AP alarms are classified as 'Malicious' and are detected on the network.

Each rogue rule is composed of single or multiple conditions (Required or Recommended). The malicious rogue AP rules are as follows:

• Managed SSIDs (Required)—Any rogue APs using managed SSIDs, the same as your wireless infrastructure, must be marked as “Malicious”. Administrators need to investigate and mitigate this threat.
• Minimum RSSI >-70 dBm (Recommended)—This criterion normally indicates that unknown rogue APs are inside the facility perimeters, and can cause potential interference to the wireless network.

  This rule is only recommended for Enterprise deployment having its own isolated buildings and secured perimeters.

  This rule is not recommended for retail customers or venues that are shared by various tenants, where WiFi signals from all parties normally bleed into each other.

• User configured SSIDs/Sub-string SSIDs (Recommended) monitor any SSIDs that use different variations or combinations of characters in your production SSIDs (Managed SSIDs).

  The following points lists the recommended actions for matching conditions in malicious rouge AP rules:

• For malicious rogue APs matching “Must” conditions, configure “Contain” as action.
• Configure only one condition for each rule and make the rule name intuitive for its related condition. This facilitates the administrator to identify and troubleshoot.
• For malicious rogue APs matching “Optional” conditions, it is not recommended to configure “Contain” as action due to legal complications. Instead, configure “Alert” as action.

Note

There are legal implications for containing rogue APs. However, rogue AP using same SSIDs as your production SSIDs can be the exception for auto containment in mitigating potential threat from this rogue attracting legitimate wireless clients. Additionally containing rogues using infrastructure APs will have a significant negative impact on wireless service during operation, unless dedicated APs are used for containment activities

To create a rogue rule for additional conditions set, for example, create 'rule1':

(Cisco Controller) >config rogue rule add ap priority 1 classify malicious notify all state alert rule1

To activate the rule:

(Cisco Controller) >config rogue rule enable rule1

To verify rule summary:

(Cisco Controller) >show rogue rule summary 
	Priority	Rule Name Rule state Class Type Notify State Match Hit Count
-------- -------------------------------- ----------- ----------- -------- -------- ------
	1 	rule1	Enabled    Malicious    All Alert    Any    0

Up to six conditions can be added to a rogue rule. These are CLI examples, refer to the Rogue Management and Detection, page 21 section on rogue management for best practices guidance.

Adding condition based rules can help to easily detect people spoofing on your network. To configure condition rule based on a managed SSID:

(Cisco Controller) >config rogue rule condition ap set managed-ssid rule1

To add condition based on specific SSID name:

(Cisco Controller) >config rogue rule condition ap set ssid <SSID_name> rule1

To add condition based on minimum RSSI, for example, -70 dBm:

(Cisco Controller) >config rogue rule condition ap set rssi -70 rule1

To add condition based on duration (in seconds) that the rogue has been detected, for example, 120 seconds:

(Cisco Controller) >config rogue rule condition ap set duration 120 rule1

To confirm rogue rule conditions:

(Cisco Controller) >show rogue rule detailed rule1
Priority......................................... 1
Rule Name........................................ rule1
State............................................ Disabled
Type............................................. Malicious
Notify........................................... All
State ........................................... Alert
Match Operation.................................. Any
Hit Count........................................ 0
Total Conditions................................. 3 Condition 1 type.... 
Duration value (seconds)....... 120 
Condition 2 type........... Managed-ssid value....................... Enabled 
Condition 3 type............
Rssi value (dBm)...................................... -70

Research and investigate, and then remove friendly rogue APs from "Unclassified" rogue AP list on a regular basis (weekly or monthly).

Examples of friendly rogue APs are as follows:

• Known Internal Friendly Rogue APs, for example within facility perimeters, and known AP MAC addresses imported into the friendly rouge AP list.
• Known External Friendly Rogue APs, for example, vendor shared venues and neighboring retailers.

By default, rogue AP alarms are displayed as "Unclassified" with "Minor" severity if they do not meet the defined classification rules. This list can grow and become unmanageable in Prime Infrastructure. For example, transient rogue APs are detected only for a short duration, such as MiFi devices. It is unnecessary to monitor these rogues on a daily basis if they are not detected on the wired network. Instead, do the following:

• Implement automated rogue AP mitigation mechanism, such as auto switchport tracing. If traced on wired network, critical alarms will be triggered.
• Run monthly or quarterly report on unclassified rogue APs to identify potentially unknown friendly ones among them.

It is recommended is to implement auto SPT for rogue AP mitigation, which correlates rogue AP radio MAC addresses, heard over the air, to Ethernet MAC addresses on wired network side. Once the potential match is found, it will be reported as "Found On Network" on Prime Infrastructure.

• When auto SPT starts, it runs through each rogue AP radio MAC address against all known Ethernet MAC addresses on all known switches.

• Auto SPT enabled for alarms with “Minor” severity eases the job of administrators as the mitigation scheme is already in place.

To verify rogues detected on AP:

(Cisco Controller) >show rogue ap summary 
Rogue Detection Security Level................... custom
Rogue Pending Time............................... 180 secs
Rogue on wire Auto-Contain....................... Disabled
Rogue using our SSID Auto-Contain................ Disabled
Valid client on rogue AP Auto-Contain............ Disabled
Rogue AP timeout................................. 1200
Rogue Detection Report Interval.................. 10
Rogue Detection Min Rssi......................... -128
Rogue Detection Transient Interval............... 0
Rogue Detection Client Num Thershold............. 0
Total Rogues(AP+Ad-hoc) supported................ 2000
Total Rogues classified.......................... 41
MAC Address        Classification     # APs # Clients Last Heard             
-----------------  ------------------ ----- --------- -----------------------
00:0d:67:1e:7c:a5  Unclassified       1     0         Thu Feb  6 22:04:38 2014
00:0d:67:1e:7c:a6  Unclassified       1     0         Thu Feb  6 22:04:38 2014
00:0d:67:1e:7c:ac  Unclassified       2     0         Thu Feb  6 22:04:38 2014

It is possible to configure rogue detection feature on a per AP basis. For example, it could be useful to disable rogue detection on APs located on public areas. By default, rogue detection is enabled.

To verify rogue configuration on AP:

(Cisco Controller) >show ap config general <AP Name>
Cisco AP Identifier.............................. 4
Cisco AP Name.................................... AP1140
Country code..................................... Multiple Countries:PT,US
Regulatory Domain allowed by Country............. 802.11bg:-AE    802.11a:-AE
AP Country code.................................. US  - United States 
AP Regulatory Domain............................. 802.11bg:-A    802.11a:-A 
AP Link Latency.................................. Disabled
Rogue Detection.................................. Enabled 

To enable rogue detection on an AP:

(Cisco Controller) >config rogue detection enable <Cisco AP>

Specifies the minimum RSSI value that rogues should have for APs to detect them and for the rogue entries to be created in the Cisco WLC. Recommended value is around -70 to -80 dBm, depending of deployment scenario. The idea is to filter out rogues that are not inside the building, or significant enough to represent an RF impact to the infrastructure. If ensuring a full detection of rogues is done, independently of their RSSI level, then set this to a very low signal level.

Set the minimum RSSI value that rogues should have by entering this command:

(Cisco Controller) >config rogue detection min-rssi rssi-in-dBm <value> 

Using the transient interval values, you can control the time interval at which APs should scan for rogues. APs can also filter rogues based on their transient interval values.

This feature has the following advantages:

• Rogue reports from APs to the controller are shorter.
• Transient rogue entries are avoided in the controller.
• Unnecessary memory allocation for transient rogues is avoided.

To configure transient rogue interval of 2 minutes (120 seconds):

(Cisco Controller) >config rogue detection monitor-ap transient-rogue-interval 120

Similar to general rogue detection, ad hoc rogue detection is ideal in certain scenarios where security is justifiable.

However, it is not recommended in scenarios such as open venues/stadiums, citywide, and public outdoors.

To enable ad hoc rogue detection and reporting:

(Cisco Controller) >config rogue adhoc enable

The reason for enabling AAA validation for rogue clients is that the WLC will reliably and continuously check for a client to exist on the AAA server, and then mark it either valid or malicious.

(Cisco Controller) >config rogue client aaa enable

If there is a Mobility Services Engine (MSE) available and integrated, it can share the information in its learned client database to compliment the WLC in validating whether a client is valid or a threat.

To enable the use of MSE (if available) to check if rogue clients are valid:

(Cisco Controller) >config rogue client mse enable 

For any wireless deployment, always do a proper site survey to ensure proper service levels for your wireless clients. The requirements for voice or location deployments are stricter than 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. Ideally, the actual device model and operating system/firmware versions should be used in the same condition (with sled or case) and orientation that will be used in the live network. For example, do not use an older 802.11b/g radio with omni antenna to study coverage, if the final network uses more modern dual radios for 802.11a/b/g/n and 802.11ac data rates.

The site survey should match the AP model that the customer is going to install. The AP should be at the orientation and height that will be typical of the final installation. The data rates on the AP should be set to the rates required by the customer application, bandwidth, and coverage requirements. Do not measure the coverage area to a data rate of 1 Mbps with 2.4 GHz. If the primary objective of the network design is for each area of coverage to support 30 users at 5 GHz with 9 Mbps of data rate, then perform a coverage test with the primary network device with only the 5 GHz data rate with 9 Mbps enabled. Then, measure the -67 dBm receive signal strength indicator (RSSI) on the AP for the test network client during active data traffic between the AP and client. High quality RF links have good signal to noise ratios (SNR, 25 or better) and low channel utilization (CU) percentages. RSSI, SNR, and CU values are found on the WLC's client and AP information pages.

Related Documentation:

Site Survey Guidelines for WLAN Deployment

Wireless LAN Design Guide for High Density Client Environments in Higher Education

You must carefully plan the process to disable or enable data rates. If your coverage is sufficient, it is a good idea to incrementally disable lower data rates one by one. Management frames such as ACK or beacons are sent at the lowest mandatory rate (typically 1 Mbps), which slows down the whole throughput as the lowest mandatory rate consumes the most airtime.

Try not to have too many supported data rates so that clients can down-shift their rate faster when retransmitting. Typically, clients try to send at the fastest data rate. If the frame does not make it through, the client will retransmit at the next lowest data rate and so on until the frame goes through. The removal of some supported rates helps the clients that retransmit a frame to directly down-shift several data rates, which increases the chance for the frame to go through at the second attempt.

• Beacons are sent at the lowest mandatory rate, defining roughly the cell size.
• Multicast is sent on the range between lowest and highest priority, depending on associated clients.
• If your design does not require low data rates, consider disabling the 802.11b data rates (1, 2, 5.5, and 11) and leave the rest enabled.

The following example serves only as an example and should not be viewed as a strict guideline for every design. These changes are sensitive and heavily dependent on your RF coverage design.

• For example, if you are designing for hotspot, enable lowest data rate, because the goal is to have coverage gain versus speed.
• Conversely, if you are designing for a high-speed network, with already good RF coverage, disable the lowest.

To disable low data rates (5 GHz and 2.4 GHz):

(Cisco Controller) >config 802.11a disable network
(Cisco Controller) >config 802.11a 11nSupport enable
(Cisco Controller) >config 802.11a rate disabled 6
(Cisco Controller) >config 802.11a rate disabled 9
(Cisco Controller) >config 802.11a rate disabled 12
(Cisco Controller) >config 802.11a rate disabled 18
(Cisco Controller) >config 802.11a rate mandatory 24
(Cisco Controller) >config 802.11a rate supported 36
(Cisco Controller) >config 802.11a rate supported 48
(Cisco Controller) >config 802.11a rate supported 54
(Cisco Controller) >config 802.11a enable network
(Cisco Controller) >config 802.11b disable network
(Cisco Controller) >config 802.11b 11gSupport enable
(Cisco Controller) >config 802.11b 11nSupport enable
(Cisco Controller) >config 802.11b rate disabled 1
(Cisco Controller) >config 802.11b rate disabled 2
(Cisco Controller) >config 802.11b rate disabled 5.5
(Cisco Controller) >config 802.11b rate disabled 11
(Cisco Controller) >config 802.11b rate disabled 6
(Cisco Controller) >config 802.11b rate disabled 9
(Cisco Controller) >config 802.11b rate supported 12
(Cisco Controller) >config 802.11b rate supported 18
(Cisco Controller) >config 802.11b rate mandatory 24
(Cisco Controller) >config 802.11b rate supported 36
(Cisco Controller) >config 802.11b rate supported 48
(Cisco Controller) >config 802.11b rate supported 54
(Cisco Controller) >config 802.11b enable network

Cisco recommends limiting the number of service set identifiers (SSIDs) configured in the controller. You can configure 16 simultaneous WLAN/SSIDs (per radio on each AP), but as each WLAN/SSID needs separate probe responses and beaconing, transmitted at the lowest mandatory rate, the RF pollution increases as more SSIDs are added. Also, some smaller wireless stations such as PDA, WiFi Phones, and barcode scanners cannot cope with a high number of basic SSID (BSSID) over the air. This results in lockups, reloads, or association failures. It is recommended to have one to three SSIDs for an enterprise, and one SSID for high-density designs.

By using the AAA override feature, the number of WLAN/SSID's can be reduced while assigning individual per user VLAN/settings on a single SSID scenario.

Enter this command to verify the SSIDs:

(Cisco Controller) >show wlan summary 
Number of WLANs.................................. 8
WLAN ID  WLAN Profile Name / SSID               Status    Interface Name
-------  -------------------------------------  --------  --------------------
WLAN-Local / WLAN-Local                Enabled   	    management            
WLAN-Lync / WLAN-Lync                  Enabled	       Lync
WLAN-AVC / WLAN-AVC                    Enabled	       AVC
WLAN-11ac / WLAN-11ac                  Enabled   	    11ac            
WLAN-Visitor / WLAN-Visitor            Enabled   	    Visitor            
WLAN-1X / WLAN-1X                      Enabled   	    1X            
WLAN-23 / WLAN-23                      Enabled   	    23            
WLAN-HS2 / WLAN-HS2		                  Enabled 	      HS2 

To disable unnecessary SSIDs:

(Cisco Controller) >config wlan disable <wlan-id>

Restriction

This should be used in most scenarios.

channel. The 2.4 GHz band is frequently under higher utilization, and can suffer interference from Bluetooth devices, microwave ovens, cordless phones as well as co-channel interference from other APs because of the 802.11b/g limit of three non-overlapping channels. To prevent these sources of interference and improve overall network performance, you can configure band selection on controller:

• Band Select is disabled per wlan by default
• Band Select works by regulating probe responses to clients. It makes 5 GHz channels more attractive to clients by delaying probe responses to clients on 2.4 GHz channels.
• Do not use Band Select if you will deploy voice or video services (any interactive traffic), as it may impair roaming performance on some client types.
• Most newer model clients prefer 5 GHz by default if the 5 GHz signal of the AP is equal to or stronger than the 2.4 GHz signal. This means on deployments with newer client types, band select may not be necessary

In general, dual band clients will start scanning on the same band where they first associated. Band Select will impact the initial scan, steering clients towards 5 GHz so, if the client initially joins the 5 GHz band, then it is more likely to stay there if there are good power levels on 5 GHz.

Enter this command to verify the band select:.

(Cisco Controller) >show band-select 
Band Select Probe Response....................... per WLAN enabling
Cycle Count...................................... 2 cycles
Cycle Threshold.................................. 200 milliseconds
Age Out Suppression.............................. 20 seconds
Age Out Dual Band................................ 60 seconds
Client RSSI...................................... -80 dBm 

To enable or disable band-select on specific WLANs:

(Cisco Controller) >config wlan band-select allow enable <WLAN id> 

Restriction

Do not use Band Select when providing voice, video or other real-time based applications on the WLAN.

When a wireless network is first initialized, all participating radios require a channel assignment to operate without interference. DCA optimizes the channel assignments to allow for interference free operation. Wireless network does this using the air metrics reported by each radio on every possible channel, and provides a solution that maximizes channel bandwidth and minimizes RF interference from all sources, such as self (signal), other networks (foreign interference), and noise (everything else).

DCA is enabled by default and provides a global solution to channel planning for your network.

• Let RRM automatically configure all 802.11a or 802.11b/g channels based on availability and interference:

(Cisco Controller) >config 802.11a channel global auto	
(Cisco Controller) >config 802.11b channel global auto

The Cisco WLC dynamically controls the access point transmit power based on real-time wireless LAN conditions. You can choose between two versions of transmit power control: TPCv1 and TPCv2. With TPCv1, power can be kept low to gain extra capacity and reduce interference. With TPCv2, transmit power is dynamically adjusted with the goal of minimum interference. TPCv2 is suitable for dense networks. In this mode, there could be higher roaming delays and coverage hole incidents.

The Transmit Power Control (TPC) algorithm increases and decreases the power of an access point (AP) in response to changes in the RF environment. In most instances, TPC seeks to lower the power of the AP to reduce interference. But, in the case of a sudden change in the RF coverage, for example, if the AP fails or becomes disabled, TPC can also increase power of the surrounding APs. This feature is different from coverage hole detection, which is primarily concerned with clients. TPC provides enough RF power to achieve desired coverage levels while avoiding channel interference between APs.

Note	For optimal performance, use the Automatic setting to allow best transmit power for each radio.

To configure auto TPC on either a or b radio:

(Cisco Controller) >config 802.11a|b txPower global auto

Restriction

This should be used in most scenarios. It is advisable to adjust the TPC threshold to adapt properly to the RF deployment characteristics.

It is important to remember that the "default ap group" will always contain WLANs with ID 1 to 16. All access points go into this group when they are first added into the controller, until they are moved to a different group (out of the box).

For some scenarios, it is common to pre-define a set of "dummy" WLANs with IDs 1 to 16, to ensure that no WLANs are added by accident into the default AP group, and broadcasted by APs on default configuration. This does not apply to small controllers, where only ID 1 to 16 are supported.

Restriction

This should be used in most scenarios.

Related Documentation:

Configuring AP Groups

RF Profiles are the mechanism used within AP Groups, to customize the RRM and RF parameters for a given set of access points. This will allow for fine tuning scenarios for channel selection, data rates, RX-SOP, among other configuration characteristics.

General recommendations:

• Set the desired TPC threshold on the RF group, based on the AP density and installed height. For large deployments, there can be significant variations on the RF environment, so it is important to adjust properly TPC to ensure optimal coverage on each location
• Together with transmit power, data rates are the primary mechanism to influence the client roaming behavior. Changing which is the lowest mandatory rate can modify when the client may trigger a new roam, which is especially important for large open spaces, that suffer from "sticky client problems"
• When setting up RF profiles, try to avoid configuring adjacent AP groups/RF profiles, with different DCA channel sets, as this can impact negatively DCA channel assignment calculations.

Restriction

This should be used in most scenarios.

General additional information:

Radio Resource Management

To effectively detect and mitigate RF interference, enable CleanAir whenever possible. There are recommendations to various sources of interference to trigger security alerts, such as generic DECT phones, jammer, etc.

To verify CleanAir configuration on the network (802.11b):

(Cisco Controller) >show 802.11b cleanair config

To verify CleanAir configuration on the network (802.11a):

(Cisco Controller) >show 802.11a cleanair config


Clean Air Solution............................... Disabled
Air Quality Settings:
    Air Quality Reporting........................ Enabled
    Air Quality Reporting Period (min)........... 15
    Air Quality Alarms........................... Enabled
      Air Quality Alarm Threshold................ 35
      Unclassified Interference.................. Disabled
      Unclassified Severity Threshold............ 20
Interference Device Settings:
    Interference Device Reporting................ Enabled
    Interference Device Types:
        TDD Transmitter.......................... Enabled
        Jammer................................... Enabled
        Continuous Transmitter................... Enabled

To enable CleanAir functionality:

(Cisco Controller) >config 802.11b cleanair enable network
(Cisco Controller) >config 802.11a cleanair enable network

To enable interference detection, for example, for jammer:

(Cisco Controller) >config 802.11b cleanair device enable jammer

Note	CleanAir in general, does not have an impact in network performance, with the exception of BLE Beacon detection feature. If this RF signature is not required, it is advisable to disable it:

config 802.11b cleanair device disable ble-beacon

Restriction

This should be used in most scenarios, with the exception of the BLE Beacon signature.

This feature enables the WLC to do channel changes when a sudden and critical RF interference is detected on the AP current operating channel, without waiting for the normal DCA process to perform the modification based on RF metrics. It can leverage the CleanAir information, and use it to force a quick reaction time, for situations that could probably mean that clients will be suffering from bad throughput or connectivity issues

The outdoor environment is a challenging RF environment. Many obstacles and interferers exist that cannot be avoided.

Prior to designing a network, an RF Active Site Survey is the first step to understand your RF environment.

Once the RF active site survey is performed, you must estimate the number of outdoor access points required to meet your network's design requirement. The best tool to estimate an access point's coverage area is the WNG Coverage and Capacity Calculator

Outdoor access points can operate in multiple deployment modes, with each deployment mode meeting a different use case.

Local Mode–Best option for an outdoor deployment. Provides full support of Cisco Unified Network features, Radio Resource Management (RRM), and allows the 2.4 GHz and 5 GHz radios to be used exclusively for client access. This deployment mode should be used when each access point has a dedicated Ethernet connection.

Local Mode–Best option for an outdoor deployment. Provides full support of Cisco Unified Network features, Radio Resource Management (RRM), and allows the 2.4 GHz and 5 GHz radios to be used exclusively for client access. This deployment mode should be used when each access point has a dedicated Ethernet connection.

Bridge–Flex Mode–Provides a hybrid operation between Mesh and Flex. This is recommended for scenarios where the AP are separated by a WAN from the WLC, also when you need to have traffic to be locally switched at the AP level, and not sent centrally to the controller.

If the regulatory domain channel plan allows it, when selecting the backhaul channel for a mesh tree, avoid channels that can be used for radar (DFS channels).

When operating in Bridge Mode, each access point should be assigned a Bridge Group Name and Preferred Parent. This helps the mesh network to converge in the same sequence every time, allowing the network to match the initial design.

To set Bridge Group Name:

(Cisco Controller) >config` ap bridgegroupname set BGN-name ap-name

To verify:

(Cisco Controller) >show ap config general ap-name

To set Preferred Parent:

(Cisco Controller) >config mesh parent <ap-name> <parent_MAC>

To verify:

(Cisco Controller) >show ap config general <ap-name>

Restriction

This should be used in most scenarios.

When deploying a mesh network, there should be multiple paths for each access point back to a WLC. Multiple paths can be added by having multiple Root Access Points (RAPs) per mesh tree. If an RAP fails and goes offline, other mesh access points will join another RAP in the same BGN and still have a path back to the WLC.

• For best results, ensure that RAPs are configured on different channels, to reduce or avoid co-channel interference. Map will use background scanning to identify each RAP
• RAP should be on the same VLAN/subnet to prevent mesh AP address renegotiation on parent change, that could delay total mesh convergence time
• Ensure that MAP have background scanning enabled, to facilitate new parent discovery

Restriction

This should be used in most scenarios.

When deploying a mesh network, each mesh node should communicate on the highest possible backhaul data rate. To ensure this, it is recommended to enable Dynamic Rate Adjustment (DRA) by selecting the "auto" backhaul data rate.

DRA has to be enabled on every mesh link.

To enable "auto":

(Cisco Controller) > config ap bhrate auto <ap-name>

To verify:

(Cisco Controller) > show ap bhrate <ap-name>

When deploying a mesh network, each mesh node should communicate on the highest possible backhaul speed, 40 MHz allows the best equilibrium between performance and RF congestion avoidance.

To set the channel width per AP:

(Cisco Controller) >config 802.11a chan_width <ap-name> 40

Restriction

This should be used in most scenarios.

To ensure optimal performance over your mesh network, make sure the backhaul link quality is good. An optimal link quality would be greater than 40 dBm, but this is not always achievable in non-line of site deployment or long-range bridges. Cisco recommends the link SNR to be at least 25 dBm or greater.

Restriction

This should be used in most scenarios.

To check the LinkSNR:
(Cisco Controller) >show mesh neigh summary ap-name
AP Name/Radio 	Channel	Rate 	Link-Snr	Flags	State
------------- 	-------	------	---------	-----	------
RAP_e380	136	m15	 33	0x0	UPDATED NEIGH PARENT BEACON 

Or:
(Cisco Controller) >show mesh neigh detail ap-name
AP MAC : 1C:AA:07:5F:E3:80  AP Name: RAP_e380 backhaul rate m15
FLAGS : 86F UPDATED NEIGH PARENT BEACON Neighbor reported by slot: 1
worstDv 0, Ant 0, channel 136, biters 0, ppiters 10 Numroutes 1, snr 0, snrUp 40, snrDown 43, linkSnr 39 adjustedEase 8648576, unadjustedEase 8648576

An external radius server should be configured for MAC authentications. This allows all bridge mode access points to authenticate at a single location, thus simplifying network management.

For instructions on how to setup an external radius server:

Mesh Access Points, Design and Deployment Guide

To have the best equilibrium between mesh security and ease of deployments, it is advisable to enable the Mesh Key Provisioned feature.

Related Documentation:

Mesh PSK Key provisioning

iOS devices running iOS 10 and higher will identify the Adaptive 11r functionality on a Cisco network running AireOS 8.3 or later and perform an FT Association on the WLAN. The Cisco Wireless infrastructure will allow FT association on the WLAN from devices that can negotiate FT association on a non-FT WLAN.

config wlan security ft adaptive enable/disable 

• Enable Authentication and Key Management (AKM) as 802.1x or PSK instead of FT 802.1x or FT PSK when adaptive 11r is enabled

In addition, with WLC running AireOS 8.3, 802.11k and 11v features are enabled by default on an SSID. These features help clients roam better by telling them when to roam and providing them with information about neighboring APs so that no time is wasted scanning when roaming is needed. Since iOS devices support dual- band, the 802.11k neighbor list is updated on dual-band, adaptively for iOS devices.

Set Fast Transition to enabled or Adaptive:

(Cisco Controller) >config wlan security ft adaptive enable <wlan-id>

Apple iOS device mark QoS as per IETF recommendations. With WLC running AireOS 8.3, you can enable the Fastlane feature, which enables several beneficial functions:

Your WLC QoS configuration is optimized globally to better support real-time applications iOS 10 devices can send upstream voice traffic without the requirement to perform WMM TSPEC/TCLAS negotiation. The infrastructure will honor the voice marking for these devices.

You can apply a QoS profile to your iOS 10 devices, and decide which applications should receive QoS marking.

Cisco and Apple recommend to always design and implement the wireless networks for 5 GHz operation for optimal performance

All MCS rates (0-31) should be enabled to prevent problems with Apple devices.

(Cisco Controller) >show 802.11a
802.11a Network.................................. Enabled
11acSupport...................................... Enabled
11nSupport....................................... Enabled
      802.11a Low Band........................... Enabled
      802.11a Mid Band........................... Enabled
      802.11a High Band.......................... Enabled
802.11a Operational Rates
    802.11a 6M Rate.............................. Disabled
    802.11a 9M Rate.............................. Disabled
    802.11a 12M Rate............................. Mandatory
    802.11a 18M Rate............................. Supported
    802.11a 24M Rate............................. Supported
    802.11a 36M Rate............................. Supported
    802.11a 48M Rate............................. Supported
    802.11a 54M Rate............................. Supported
802.11n MCS Settings:
    MCS 0........................................ Supported
    MCS 1........................................ Supported

Enable MCS rates on a 5-GHz network by entering this command:

(Cisco Controller) >config 802.11a 11acsupport mcs tx {mcs8 | mcs9} ss {1-4} enable

Enabling the QoS Map and Trust DSCP Upstream helps improve the performance of Apple client devices.

Enable QoS Map values by entering these commands:

(Cisco Controller) >config qos qosmap enable
(Cisco Controller) >config qos qosmap trust-dscp-upstream enable

The Unicast and Multicast priority should be Best Effort for Platinum Profile to help improve the performance of Apple client devices.

Enable Best Effort on the Platinum Profile by entering this command:

(Cisco Controller) >config qos priority platinum besteffort besteffort besteffort

Optimized roaming should be disabled because Apple devices use the newer 802.11r, 802.11k, or 802.11v roaming improvement.

Disable optimized roaming by entering this command:

(Cisco Controller) >config advanced 802.11{a | b} optimized-roaming disable