You can order Cisco 5500 Series Controllers with support for 12, 25, 50, 100, 250 or 500 access points as the controller’s base capacity. You can add additional access point capacity through capacity adder licenses available at 25, 50, 100 and 250 access point capacities. You can add the capacity adder licenses to any base license in any combination to arrive at the maximum capacity of 500 access points. The base and adder licenses are supported through both rehosting and RMAs.

The base license supports the standard base software set, and the premium software set is included as part of the base feature set, which includes this functionality:

• Datagram Transport Layer Security (DTLS) data encryption for added security across remote WAN and LAN links.

• The availability of data DTLS is as follows:

  • Cisco 5500 Series Controller—The Cisco 5500 Series Controller is available with two licensing options: One with data DTLS capabilities and another image without data DTLS.

  • 2500, WiSM2—These platforms by default do not contain DTLS. To turn on data DTLS, you must install a license. These platforms will have a single image with data DTLS turned off. To use data DTLS, you must have a license.

• Support for OfficeExtend access points, which are used for secure mobile teleworking.

All features included in a Wireless LAN Controller WPLUS license are now included in the base license. There are no changes to Cisco Prime Infrastructure BASE and PLUS licensing. These WPlus license features are included in the base license:

• OfficeExtend AP

• Enterprise Mesh

• CAPWAP Data Encryption

For information about upgrade and capacity adder licenses, see the product data sheet of your controller model.

This section describes how to get an upgrade or capacity adder license.

• Configure debugging of license agent by entering this command:

  debug license agent {errors | all} {enable | disable}

• Configure debugging of licensing core events and core errors by entering this command:

  debug license core {all | errors | events} {enable | disable}

• Configure debugging of licensing errors by entering this command:

  debug license errors {enable | disable}

• Configure debugging of licensing events by entering this command:

  debug license events {enable | disable}

If you are considering upgrading to a license with a higher access point count, you can try an evaluation license before upgrading to a permanent version of the license. For example, if you are using a permanent license with a 50-access-point count and want to try an evaluation license with a 100-access-point count, you can try out the evaluation license for 60 days.

AP-count evaluation licenses are set to low priority by default so that the controller uses the ap-count permanent license. If you want to try an evaluation license with an increased access point count, you must change its priority to high. If you no longer want to have this higher capacity, you can lower the priority of the ap-count evaluation license, which forces the controller to use the permanent license.

Note

To prevent disruptions in operation, the controller does not switch licenses when an evaluation license expires. You must reboot the controller in order to return to a permanent license. Following a reboot, the controller defaults to the same feature set level as the expired evaluation license. If no permanent license at the same feature set level is installed, the controller uses a permanent license at another level or an unexpired evaluation license.

This section describes how to rehost licenses.

You can configure the 802.11b/g/n (2.4-GHz) and 802.11a/n (5-GHz) bands for the controller to comply with the regulatory requirements in your country. By default, both 802.11b/g/n and 802.11a/n are enabled.

When a controller is configured to allow only 802.11g traffic, 802.11b client devices are able to successfully connect to an access point but cannot pass traffic. When you configure the controller for 802.11g traffic only, you must mark 11g rates as mandatory.

This section provides instructions for managing 802.11n devices such as the Cisco Aironet 1140 and 3600 Series Access Points on your network. The 802.11n devices support the 2.4- and 5-GHz bands and offer high-throughput data rates.

The 802.11n high-throughput rates are available on all 802.11n access points for WLANs using WMM with no Layer 2 encryption or with WPA2/AES encryption enabled.

Note	Some Cisco 802.11n APs may intermittently emit incorrect beacon frames, which can trigger false wIPS alarms. We recommend that you ignore these alarms. The issue is observed in the following Cisco 802.11n APs: 1140, 1250, 2600, 3500, and 3600.

• Enable 802.11n support on the network by entering this command:

  config {802.11a | 802.11b} 11nsupport {enable | disable}

• Specify the modulation and coding scheme (MCS) rates at which data can be transmitted between the access point and the client by entering this command:

  config {802.11a | 802.11b} 11nsupport mcs tx {0-15} {enable | disable}

• Use the 802.11n data rates that you configured by enabling WMM on the WLAN as follows:

  config wlan wmm {allow | disable | require} wlan_id

  The require parameter requires client devices to use WMM. Devices that do not support WMM cannot join the WLAN.

  If set to allow, devices that cannot support WMM can join the WLAN but do not benefit from 802.11n rates.

• Specify the aggregation method used for 802.11n packets as follows:

  1. Disable the network by entering this command:

     config {802.11a | 802.11b} disable network

  2. Specify the aggregation method entering this command:

     config {802.11a | 802.11b} 11nsupport {a-mpdu | a-msdu} tx priority {0-7 | all} {enable | disable}

     Aggregation is the process of grouping packet data frames together rather than transmitting them separately. Two aggregation methods are available: Aggregated MAC Protocol Data Unit (A-MPDU) and Aggregated MAC Service Data Unit (A-MSDU). A-MSDU is performed in hardware and therefore is the default method.

     You can specify the aggregation method for various types of traffic from the access point to the clients. This table defines the priority levels (0-7) assigned per traffic type.

     Table 1 Traffic Type Priority Levels

     User Priority	Traffic Type
     0	Best effort
     1	Background
     2	Spare
     3	Excellent effort
     4	Controlled load
     5	Video, less than 100-ms latency and jitter
     6	Voice, less than 10-ms latency and jitter
     7	Network control

     You can configure each priority level independently, or you can use the all parameter to configure all of the priority levels at once. When you use the enable command, the traffic associated with that priority level uses A-MPDU transmission. When you use the disable command, the traffic associated with that priority level uses A-MSDU transmission. Configure the priority levels to match the aggregation method used by the clients. By default, A-MPDU is enabled for priority level 0, 4 and 5 and the rest are disabled. By default, A-MSDU is enabled for all priorities except 6 and 7.

  3. Reenable the network by entering this command:

     config {802.11a | 802.11b} enable network

• Configure the 802.11n-5 GHz A-MPDU transmit aggregation scheduler by entering this command:

  config 802.11{a | b} 11nsupport a-mpdu tx scheduler {enable | disable | timeout rt timeout-value}

  The timeout value is in milliseconds. The valid range is between 1 millisecond to 1000 milliseconds.

• Configure the guard interval for the network by entering this command: config 802.11{a | b} 11nsupport guard_interval {any | long}

• Configure the Reduced Interframe Space (RIFS) for the network by entering this command:

  config 802.11{a | b} 11nsupport rifs rx {enable | disable}

• Save your changes by entering this command: save config

• View the configuration settings for the 802.11 networks by entering this command:

  show {802.11a | 802.11b}

802.11h informs client devices about channel changes and can limit the transmit power of those client devices.

When DHCP proxy is enabled on the controller, the controller unicasts DHCP requests from the client to the configured servers. At least one DHCP server must be configured on either the interface associated with the WLAN or the WLAN itself.

When DHCP proxy is disabled on the controller, those DHCP packets transmitted to and from the clients are bridged by the controller without any modification to the IP portion of the packet. Packets received from the client are removed from the CAPWAP tunnel and transmitted on the upstream VLAN. DHCP packets directed to the client are received on the upstream VLAN, converted to 802.11, and transmitted through a CAPWAP tunnel toward the client. As a result, the internal DHCP server cannot be used when DHCP proxy is disabled. The ability to disable DHCP proxy allows organizations to use DHCP servers that do not support Cisco’s native proxy mode of operation. It should be disabled only when required by the existing infrastructure.

Note	DHCP proxy is enabled by default.

You can configure administrator usernames and passwords to prevent unauthorized users from reconfiguring the controller and viewing configuration information. This section provides instructions for initial configuration and for password recovery.

Note	To view the controller trap log, choose Monitor and click View All under “Most Recent Traps” on the controller GUI.

• Create an SNMP community name by entering this command: config snmp community create name

• Delete an SNMP community name by entering this command: config snmp community delete name

• Configure an SNMP community name with read-only privileges by entering this command: config snmp community accessmode ro name

• Configure an SNMP community name with read-write privileges by entering this command: config snmp community accessmode rw name

• For IPv4 configuration—Configure an IPv4 address and subnet mask for an SNMP community by entering this command:

  config snmp community ipaddr ip-address ip-mask name

  Note

  This command behaves like an SNMP access list. It specifies the IP address from which the device accepts SNMP packets with the associated community. An AND operation is performed between the requesting entity’s IP address and the subnet mask before being compared to the IP address. If the subnet mask is set to 0.0.0.0, an IP address of 0.0.0.0 matches to all IP addresses. The default value is 0.0.0.0.

  Note	The controller can use only one IP address range to manage an SNMP community.

• For IPv6 configuration—Configure an IPv6 address and prefix-length for an SNMP community by entering this command: config snmp community ipaddr ipv6-address ip-mask name

• Enable or disable a community name by entering this command:

  config snmp community mode {enable | disable}

• Enable or disable a community name by entering this command:

  config snmp community ipsec {enable | disable}

• Configure the IKE authentication methods by entering this command:

  config snmp community ipsec ike auth-mode {certificate | pre-shared-key ascii/hex secret}

  Authentication mode can be configured per trap receiver. By default, the authentication mode is set to certificate.

• Configure a destination for a trap by entering this command:

  config snmp trapreceiver create name ip-address

• Delete a trap by entering this command:

  config snmp trapreceiver delete name

• Change the destination for a trap by entering this command:

  config snmp trapreceiver ipaddr old-ip-address name new-ip-address

• Configure the trap receiver IPSec session entering this command:

  config snmp trapreceiver ipsec {enable | disable} community-name

  Trap receiver IPSec must be in the disabled state to change the authentication mode.

• Configure the IKE authentication methods by entering this command:

  config snmp trapreceiver ipsec ike auth-mode {certificate | pre-shared-key ascii/hex secret community-name}

  Authentication mode can be configured per trap receiver. By default, the authentication mode is set to certificate.

• Enable or disable the traps by entering this command:

  config snmp trapreceiver mode {enable | disable}

• Configure the name of the SNMP contact by entering this command:

  config snmp syscontact syscontact-name

  Enter up to 31 alphanumeric characters for the contact name.

• Configure the SNMP system location by entering this command:

  config snmp syslocation syslocation-name

  Enter up to 31 alphanumeric characters for the location.

• Verify that the SNMP traps and communities are correctly configured by entering these commands:

  show snmpcommunity

  show snmptrap

• See the enabled and disabled trap flags by entering this command:

  show trapflags

  If necessary, use the config trapflags command to enable or disable trap flags.

• Configure the SNMP engine ID by entering this command:

  config snmp engineID engine-id-string

  Note	The engine ID string can be a maximum of 24 characters.

• View the engine ID by entering this command:

  show snmpengineID

• Configure the SNMP version by entering this command:

  config snmp version {v1 | v2c | v3} {enable | disable}

The controller has commonly known default values of "public" and "private" for the read-only and read-write SNMP community strings. Using these standard values presents a security risk. If you use the default community names, and since these are known, the community names could be used to communicate to the controller using SNMP. Therefore, we strongly advise that you change these values.

The controller uses a default value of “default” for the username, authentication password, and privacy password for SNMP v3 users. Using these standard values presents a security risk. Therefore, Cisco strongly advises that you change these values.

Note	SNMP v3 is time sensitive. Ensure that you configure the correct time and time zone on your controller.

Enabling aggressive load balancing on the controller allows lightweight access points to load balance wireless clients across access points. You can enable aggressive load balancing using the controller.

Note	Clients are load balanced between access points on the same controller. Load balancing does not occur between access points on different controllers.

When a wireless client attempts to associate to a lightweight access point, association response packets are sent to the client with an 802.11 response packet including status code 17. The code 17 indicates that the AP is busy. The AP responds with an association response bearing 'success' if the AP threshold is not met, and with code 17 (AP busy) if the AP utilization threshold is reached or exceeded and another less busy AP heard the client request.

For example, if the number of clients on AP1 is more than the number of clients on AP2 plus the load-balancing window, then AP1 is considered to be busier than AP2. When a client attempts to associate to AP1, it receives an 802.11 response packet with status code 17, indicating that the access point is busy, and the client attempts to associate to a different access point.

You can configure the controller to deny client associations up to 10 times (if a client attempted to associate 11 times, it would be allowed to associate on the 11th try). You can also enable or disable load balancing on a particular WLAN, which is useful if you want to disable load balancing for a select group of clients (such as time-sensitive voice clients).

Note	Voice Client does not authenticate when delay is configured more than 300 ms. To avoid this configure a Central-Auth, Local Switching WLAN with CCKM, configure a Pagent Router between AP and WLC with a delay of 600 ms (300 ms UP and 300 ms DOWN and try associating the voice client

Passive scanning clients will be able to associate to an AP irrespective of whether load balancing is enabled or not.

Note	Cisco 600 Series OfficeExtend Access Points do not support client load balancing. With the 7.4 release, FlexConnect access points do support client load balancing.

You can configure the controller to analyze the WAN interface utilization of neighboring APs and then load balance the clients across the lightly loaded APs. You can configure this by defining a load balancing threshold. By defining the threshold, you can measure the WAN interface utilization percentage. For example, a threshold value of 50 triggers the load balancing upon detecting utilization of 50% or more on an AP-WAN interface.

Note

For a FlexConnect AP the association is locally handled. The load-balancing decisions are taken at the Cisco WLC. A FlexConnect AP initially responds to the client before knowing the result of calculations at the Cisco WLC. Load-balancing doesn't take effect when the FlexConnect AP is in standalone mode. FlexConnect AP does not send (re)association response with status 17 for Load-Balancing as Local mode APs do; instead, it first sends (re)association with status 0 (success) and then deauth with reason 5.

Band selection enables client radios that are capable of dual-band (2.4- and 5-GHz) operation to move to a less congested 5-GHz access point. The 2.4-GHz band is often congested. Clients on this band typically experience interference from Bluetooth devices, microwave ovens, and cordless phones as well as co-channel interference from other access points because of the 802.11b/g limit of three nonoverlapping channels. To prevent these sources of interference and improve overall network performance, you can configure band selection on the controller.

Band selection is enabled globally by default.

Band selection 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.

Note

The client RSSI value (seen as sh cont d0 | beg RSSI) is the average of the client packets received, and the midRSSI feature is the instantaneous RSSI value of the probe packets. As a result, the client RSSI is seen as weaker than the configured midRSSI value (7 dB delta). The 802.11b probes from the client are suppressed to push the client to associate with the 802.11a band.

When fast SSID changing is enabled, the controller allows clients to move faster between SSIDs. When fast SSID is enabled, the client entry is not cleared and the delay is not enforced.

When fast SSID changing is disabled, the controller enforces a delay before clients are allowed to move to a new SSID. When fast SSID is disabled and the client sends a new association for a different SSID, the client entry in the controller connection table is cleared before the client is added to the new SSID.

802.3X Flow Control is disabled by default. To enable it, enter the config switchconfig flowcontrol enable command.

If your network supports packet multicasting, you can configure the multicast method that the controller uses. The controller performs multicasting in two modes:

• Unicast mode—In this mode, the controller unicasts every multicast packet to every access point associated to the controller. This mode is inefficient but might be required on networks that do not support multicasting.

• Multicast mode—In this mode, the controller sends multicast packets to a CAPWAP multicast group. This method reduces overhead on the controller processor and shifts the work of packet replication to your network, which is much more efficient than the unicast method.

When you enable multicast mode and the controller receives a multicast packet from the wired LAN, the controller encapsulates the packet using CAPWAP and forwards the packet to the CAPWAP multicast group address. The controller always uses the management interface for sending multicast packets. Access points in the multicast group receive the packet and forward it to all the BSSIDs mapped to the interface on which clients receive multicast traffic. From the access point perspective, the multicast appears to be a broadcast to all SSIDs.

Note	Until Release 7.5, the port number used for CAPWAP multicast was 12224. From Release 7.6 onwards, the port number used for CAPWAP is changed to 5247.

The controller supports Multicast Listener Discovery (MLD) v1 snooping for IPv6 multicast. This feature keeps track of and delivers IPv6 multicast flows to the clients that request them. To support IPv6 multicast, you must enable Global Multicast Mode.

Note

When you disable the Global Multicast Mode, the controller still forwards the IPv6 ICMP multicast messages, such as router announcements and DHCPv6 solicits, as these are required for IPv6 to work. As a result, enabling the Global Multicast Mode on the controller does not impact the ICMPv6 and the DHCPv6 messages. These messages will always be forwarded irrespective of whether or not the Global Multicast Mode is enabled.

In controller software 4.2 or later releases, Internet Group Management Protocol (IGMP) snooping is introduced to better direct multicast packets. When this feature is enabled, the controller gathers IGMP reports from the clients, processes them, creates unique multicast group IDs (MGIDs) from the IGMP reports after selecting the Layer 3 multicast address and the VLAN number, and sends the IGMP reports to the infrastructure switch. The controller sends these reports with the source address as the interface address on which it received the reports from the clients. The controller then updates the access point MGID table on the access point with the client MAC address. When the controller receives multicast traffic for a particular multicast group, it forwards it to all the access points, but only those access points that have active clients listening or subscribed to that multicast group send multicast traffic on that particular WLAN. IP packets are forwarded with an MGID that is unique for an ingress VLAN and the destination multicast group. Layer 2 multicast packets are forwarded with an MGID that is unique for the ingress interface.

When IGMP snooping is disabled, the following is true:

• The controller always uses Layer 2 MGID when it sends multicast data to the access point. Every interface created is assigned one Layer 2 MGID. For example, the management interface has an MGID of 0, and the first dynamic interface created is assigned an MGID of 8, which increments as each dynamic interface is created.

• The IGMP packets from clients are forwarded to the router. As a result, the router IGMP table is updated with the IP address of the clients as the last reporter.

When IGMP snooping is enabled, the following is true:

• The controller always uses Layer 3 MGID for all Layer 3 multicast traffic sent to the access point. For all Layer 2 multicast traffic, it continues to use Layer 2 MGID.

• IGMP report packets from wireless clients are consumed or absorbed by the controller, which generates a query for the clients. After the router sends the IGMP query, the controller sends the IGMP reports with its interface IP address as the listener IP address for the multicast group. As a result, the router IGMP table is updated with the controller IP address as the multicast listener.

• When the client that is listening to the multicast groups roams from one controller to another, the first controller transmits all the multicast group information for the listening client to the second controller. As a result, the second controller can immediately create the multicast group information for the client. The second controller sends the IGMP reports to the network for all multicast groups to which the client was listening. This process aids in the seamless transfer of multicast data to the client.

• If the listening client roams to a controller in a different subnet, the multicast packets are tunneled to the anchor controller of the client to avoid the reverse path filtering (RPF) check. The anchor then forwards the multicast packets to the infrastructure switch.

  Note	The MGIDs are controller specific. The same multicast group packets coming from the same VLAN in two different controllers may be mapped to two different MGIDs.

  Note	If Layer 2 multicast is enabled, a single MGID is assigned to all the multicast addresses coming from an interface.

  Note	The number of multicast addresses supported per VLAN for a Cisco WLC is 100.

Quality of service (QoS) refers to the capability of a network to provide better service to selected network traffic over various technologies. The primary goal of QoS is to provide priority including dedicated bandwidth, controlled jitter and latency (required by some real-time and interactive traffic), and improved loss characteristics.

The controller supports four QoS levels:

• Platinum/Voice—Ensures a high quality of service for voice over wireless.

• Gold/Video—Supports high-quality video applications.

• Silver/Best Effort—Supports normal bandwidth for clients. This is the default setting.

• Bronze/Background—Provides the lowest bandwidth for guest services.

  Note	VoIP clients should be set to Platinum.

You can configure the bandwidth of each QoS level using QoS profiles and then apply the profiles to WLANs. The profile settings are pushed to the clients associated to that WLAN. In addition, you can create QoS roles to specify different bandwidth levels for regular and guest users. Follow the instructions in this section to configure QoS profiles and QoS roles. You can also define the maximum and default QoS levels for unicast and multicast traffic when you assign a QoS profile to a WLAN.

The wireless rate limits can be defined on both upstream and downstream traffic. Rate limits can be defined per SSID and/or specified as a maximum rate limit for all clients. These rate limits can be individually configured.

You can configure the Platinum, Gold, Silver, and Bronze QoS profiles.