The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
DTIM Period
In the 802.11 networks, lightweight access points broadcast a beacon at regular intervals, which coincides with the Delivery Traffic Indication Map (DTIM). After the access point broadcasts the beacon, it transmits any buffered broadcast and multicast frames based on the value set for the DTIM period. This feature allows power-saving clients to wake up at the appropriate time if they are expecting broadcast or multicast data.
Typically, the DTIM value is set to 1 (to transmit broadcast and multicast frames after every beacon) or 2 (to transmit after every other beacon). For instance, if the beacon period of the 802.11 network is 100 ms and the DTIM value is set to 1, the access point transmits buffered broadcast and multicast frames 10 times per second. If the beacon period is 100 ms and the DTIM value is set to 2, the access point transmits buffered broadcast and multicast frames 5 times per second. Either of these settings are suitable for applications, including Voice Over IP (VoIP), that expect frequent broadcast and multicast frames.
However, the DTIM value can be set as high as 255 (to transmit broadcast and multicast frames after every 255th beacon) if all 802.11 clients have power save enabled. Because the clients have to listen only when the DTIM period is reached, they can be set to listen for broadcasts and multicasts less frequently which results in a longer battery life. For example, if the beacon period is 100 ms and you set the DTIM value to 100, the access point transmits buffered broadcast and multicast frames once every 10 seconds. This rate allows the power-saving clients to sleep longer before they have to wake up and listen for broadcasts and multicasts, which results in a longer battery life.
Many applications cannot tolerate a long time between broadcast and multicast messages, which results in poor protocol and application performance. We recommend that you set a low DTIM value for 802.11 networks that support such clients.
You can configure the DTIM period for the 802.11 radio networks on specific WLANs. For example, you might want to set different DTIM values for voice and data WLANs.
Off-Channel Scanning Deferral
In deployments with certain power-save clients, you sometimes need to defer the Radio Resource Management's (RRM) normal off-channel scanning to avoid missing critical information from low-volume clients (for example, medical devices that use power-save mode and periodically send telemetry information). This feature improves the way that Quality of Service (QoS) interacts with the RRM scan defer feature.
You can use a client's Wi-Fi Multimedia (WMM) UP marking to configure the access point to defer off-channel scanning for a configurable period of time if it receives a packet marked UP.
Off-Channel Scanning Defer is essential to the operation of RRM, which gathers information about alternate channel choices such as noise and interference. Additionally, Off-Channel Scanning Defer is responsible for rogue detection. Devices that need to defer Off-Channel Scanning Defer should use the same WLAN as often as possible. If there are many of these devices (and the possibility exists that Off-Channel Defer scanning could be completely disabled by the use of this feature), you should implement an alternative to local AP Off-Channel Scanning Defer, such as monitoring access points, or other access points in the same location that do not have this WLAN assigned.
You can assign a QoS policy (bronze, silver, gold, and platinum) to a WLAN to affect how packets are marked on the downlink connection from the access point regardless of how they were received on the uplink from the client. UP=1,2 is the lowest priority, and UP=0,3 is the next higher priority. The marking results of each QoS policy are as follows:
Configuring Off-Channel Scanning Defer for WLANs
You can specify the channels that the dynamic channel assignment (DCA) algorithm considers when selecting the channels to be used for RRM scanning by using the Cisco WLC GUI.
Note | This functionality is helpful when you know that the clients do not support certain channels because they are legacy devices or they have certain regulatory restrictions. |
Step 1 | Disable the 802.11 network as follows: | ||
Step 2 | Choose Wireless > 802.11a/n/ac or 802.11b/g/n > RRM > Coverage to open the 802.11a/ac (or 802.11b/g/n) > RRM > Coverage page. | ||
Step 3 | Select the Enable Coverage Hole Detection check box to enable coverage hole detection, or unselect it to disable this feature. If you enable coverage hole detection, the Cisco WLC automatically determines, based on data received from the access points, if any access points have clients that are potentially located in areas with poor coverage. The default value is selected. | ||
Step 4 | In the Data RSSI text box, enter the minimum receive signal strength indication (RSSI) value for data packets received by the access point. The value that you enter is used to identify coverage holes (or areas of poor coverage) within your network. If the access point receives a packet in the data queue with an RSSI value below the value that you enter here, a potential coverage hole has been detected. The valid range is –90 to –60 dBm, and the default value is –80 dBm. The access point takes data RSSI measurements every 5 seconds and reports them to the Cisco WLC in 90-second intervals. | ||
Step 5 | In the Voice RSSI text box, enter the minimum receive signal strength indication (RSSI) value for voice packets received by the access point. The value that you enter is used to identify coverage holes within your network. If the access point receives a packet in the voice queue with an RSSI value below the value that you enter here, a potential coverage hole has been detected. The valid range is –90 to –60 dBm, and the default value is –75 dBm. The access point takes voice RSSI measurements every 5 seconds and reports them to the Cisco WLC in 90-second intervals. | ||
Step 6 | In the Min Failed Client Count per AP text box, enter the minimum number of clients on an access point with an RSSI value at or below the data or voice RSSI threshold. The valid range is 1 to 75, and the default value is 3. | ||
Step 7 | In the Coverage Exception Level per AP text box, enter the percentage of clients on an access point that are experiencing a low signal level but cannot roam to another access point. The valid range is 0 to 100%, and the default value is 25%.
| ||
Step 8 | Click Apply. | ||
Step 9 | Reenable the 802.11 network as follows: | ||
Step 10 | Click Save Configuration. |
Step 1 | Choose Wireless > 802.11a/n/ac or 802.11b/g/n > RRM > General to open the 802.11a/n/ac (or 802.11b/g/n) > RRM > General page. | ||||||
Step 2 | Configure profile thresholds
used for alarming as follows:
| ||||||
Step 3 | From the
Channel
List drop-down list, choose one of the following options to specify
the set of channels that the access point uses for RRM scanning:
| ||||||
Step 4 | Configure monitor intervals as follows:
| ||||||
Step 5 | Click Apply. | ||||||
Step 6 | Click
Save Configuration.
|
Cisco Client Extensions
The software supports CCX versions 1 through 5, which enables controllers and their access points to communicate wirelessly with third-party client devices that support CCX. CCX support is enabled automatically for every WLAN on the controller and cannot be disabled. However, you can configure Aironet information elements (IEs).
If Aironet IE support is enabled, the access point sends an Aironet IE 0x85 (which contains the access point name, load, number of associated clients, and so on) in the beacon and probe responses of this WLAN, and the controller sends Aironet IEs 0x85 and 0x95 (which contains the management IP address of the controller and the IP address of the access point) in the reassociation response if it receives Aironet IE 0x85 in the reassociation request.
The Cisco Client Extensions (CCX) software is licensed to manufacturers and vendors of third-party client devices. The CCX code resident on these clients enables them to communicate wirelessly with Cisco access points and to support Cisco features that other client devices do not, including those features that are related to increased security, enhanced performance, fast roaming, and power management.
CCX is not supported on Cisco OEAP 600 access points and all elements related to CCX are not supported.
With the 7.2 release, a new version of CCX, which is called CCX Lite, is available. For more information about CCX Lite, see http://www.cisco.com/c/en/us/products/wireless/compatible-extensions.html
Step 1 | Choose WLANs to open the WLANs page. |
Step 2 | Click the ID number of the desired WLAN to open the WLANs > Edit page. |
Step 3 | Choose the Advanced tab to open the WLANs > Edit (Advanced tab) page. |
Step 4 | Select the Aironet IE check box if you want to enable support for Aironet IEs for this WLAN. Otherwise, unselect this check box. The default value is enabled (or selected). |
Step 5 | Click Apply to commit your changes. |
Step 6 | Click Save Configuration to save your changes. |
A client device sends its CCX version in association request packets to the access point. The controller then stores the client’s CCX version in its database and uses it to limit the features for this client. For example, if a client supports CCX version 2, the controller does not allow the client to use CCX version 4 features.
Step 1 | Choose Monitor > Clients to open the Clients page. |
Step 2 | Click the MAC address of the desired client device to open the Clients > Detail page. The CCX Version text box shows the CCX version supported by this client device. Not Supported appears if the client does not support CCX. |
Step 3 | Click Back to return to the previous screen. |
Step 4 | Repeat this procedure to view the CCX version supported by any other client devices. |
Use this command to configure CCX Aironet IEs:
See the CCX version supported by a particular client device using the controller CLI by entering this command:
Client Profiling
When a client tries to associate with a WLAN, it is possible to determine the client type from the information received in the process. The controller acts as the collector of the information and sends the ISE with the required data in an optimal form. Local Client profiling (DHCP and HTTP) is enabled at WLAN level. Clients on the WLANS will be profiled as soon as profling is enabled.
Wireless LAN Controller has been enhanced with some of these following capabilities:
WLC does profiling of devices based on protocols like HTTP, DHCP, etc. to identify the end devices on the network.
You can configure device-based policies and enforce per user or per device end points, and policies applicable per device.
WLC displays statistics based on per user or per device end points, and policies applicable per device.
Profiling can be based on:
Role, defining the user type or the user group to which the user belongs.
Device type, such as Windows machine, Smart Phone, iPad, iPhone, Android, etc.
Username/ password pair.
Location, based on the AP group to which the endpoint is connected
Time of the day, based on what time of the day the endpoint is allowed on the network.
EAP type, to check what EAP method the client uses to get connected.
By default, client profiling will be disabled on all WLANs.
Client profiling is supported on access points that are in Local mode and FlexConnect mode.
Both DHCP Proxy and DHCP Bridging mode on the controller are supported.
Accounting Server configuration on the WLAN must be pointing at an ISE running 1.1 MnR or later releases. Cisco ACS does not support client profiling.
The type of DHCP server used does not affect client profiling.
If the DHCP_REQUEST packet contains a string that is found in the Profiled Devices list of the ISE, then the client will be profiled automatically.
The client is identified based on the MAC address sent in the Accounting request packet.
Only a MAC address should be sent as calling station ID in accounting packets when profiling is enabled.
To enable client profiling, you must enable the DHCP required flag and disable the local authentication flag.
Client profiling uses pre-existing profiles in the controller.
Note | DHCP is required for DHCP profiling and Webauth for HTTP user agent. |
With profiling enabled for local switching FlexConnect mode APs, only VLAN override is supported as an AAA override attribute.
While the controller parses the DHCP profiling information every time the client sends a request, the profiling information is sent to ISE only once.
Custom profiles cannot be created for this release.
This release contains 88 pre-existing policies where CLI is check only except if you create a policy.
When local profiling is enabled radius profiling is not allowed on a particular WLAN.
Only the first policy rule that matches is applied.
Only 16 policies per WLAN can be configured and globally 16 policies can be allowed.
Policy action is done only after L2/L3 authentication is complete or when the device sends http traffic and gets the device profiled. Profiling and policing actions will happen more than once per client.
If AAA override is enabled and if you get any AAA attributes from the AAA server other than role type, configured policy does not apply since the AAA override attributes have a higher precedence.
Custom HTTP Port for Profiling
Note | The HTTP port 80 is always open for gathering HTTP profiling data, irrespective of the custom HTTP port configuration. |
Step 1 | Configure custom
HTTP port by entering this command:
config network profiling http-port port number The default port value is 80. |
Step 2 | View the
configured HTTP profiling port and other inband connectivity settings by
entering this command:
show network summary The network configuration is displayed. |
Client Count per WLAN
You can set a limit to the number of clients that can connect to a WLAN, which is useful in scenarios where you have a limited number of clients that can connect to a controller. For example, consider a scenario where the controller can serve up to 256 clients on a WLAN and these clients can be shared between enterprise users (employees) and guest users. You can set a limit on the number of guest clients that can access a given WLAN. The number of clients that you can configure for each WLAN depends on the platform that you are using.
The maximum number of clients for each WLAN feature is not supported when you use FlexConnect local authentication.
The maximum number of clients for each WLAN feature is supported only for access points that are in connected mode.
When a WLAN has reached the limit on the maximum number of clients connected to it or an AP radio and a new client tries to join the WLAN, the client cannot connect to the WLAN until an existing client gets disconnected.
Roaming clients are considered as new clients. The new client can connect to a WLAN, which has reached the maximum limit on the number of connected clients, only when an existing client gets disconnected.
Note | For more information about the number of clients that are supported, see the product data sheet of your controller. |
Step 1 | Choose WLANs to open the WLANs page. |
Step 2 | Click the ID number of the WLAN for which you want to limit the number of clients. The WLANs > Edit page appears. |
Step 3 | Click the Advanced tab. |
Step 4 | In the Maximum Allowed Clients text box, enter the maximum number of clients that are to be allowed. |
Step 5 | Click Apply. |
Step 6 | Click Save Configuration. |
Step 1 | Choose WLANs to open the WLANs page. |
Step 2 | Click the ID number of the WLAN for which you want to limit the number of clients. The WLANs > Edit page appears. |
Step 3 | In the Advanced tab, enter the maximum allowed clients for each access point radio in the Maximum Allowed Clients Per AP Radio text box. You can configure up to 200 clients. |
Step 4 | Click Apply. |
Step 1 | Determine the WLAN ID for which you want to configure the maximum clients for each radio by entering this command:
show wlan summary Obtain the WLAN ID from the list. |
Step 2 | Configure the maximum number of clients for each WLAN by entering this command: config wlan max-radio-clients client_count You can configure up to 200 clients. |
Step 3 | See the configured maximum associated clients by entering the show 802.11a command. |
Using the controller, you can deauthenticate clients based on their user name, IP address, or MAC address. If there are multiple client sessions with the same user name, you can deauthenticate all the client sessions based on the user name. If there are overlapped IP addresses across different interfaces, you can use the MAC address to deauthenticate the clients.
Note | It is not possible to deauthenticate clients using the controller GUI. |
config client deauthenticate {mac-addr | ipv4-addr | ipv6-addr | user-name}