Virtual Wireless Controller | Virtual Wireless Controller | Services Modules | Wireless LAN Controller Software | 2500 Series Wireless Controllers | 5500 Series Wireless Controllers | 5508 Wireless Controller | User manual | Cisco Wireless Controller Configuration Guide, Release 8.3

Cisco Wireless Controller Configuration Guide, Release 8.3

First Published: 2016-07-29

Last Modified: 2017-05-02

Americas Headquarters

Cisco Systems, Inc.

170 West Tasman Drive

San Jose, CA 95134-1706

USA http://www.cisco.com

Tel: 408 526-4000

800 553-NETS (6387)

Fax: 408 527-0883

THE SPECIFICATIONS AND INFORMATION REGARDING THE PRODUCTS IN THIS MANUAL ARE SUBJECT TO CHANGE WITHOUT NOTICE. ALL STATEMENTS,

INFORMATION, AND RECOMMENDATIONS IN THIS MANUAL ARE BELIEVED TO BE ACCURATE BUT ARE PRESENTED WITHOUT WARRANTY OF ANY KIND,

EXPRESS OR IMPLIED. USERS MUST TAKE FULL RESPONSIBILITY FOR THEIR APPLICATION OF ANY PRODUCTS.

THE SOFTWARE LICENSE AND LIMITED WARRANTY FOR THE ACCOMPANYING PRODUCT ARE SET FORTH IN THE INFORMATION PACKET THAT SHIPPED WITH

THE PRODUCT AND ARE INCORPORATED HEREIN BY THIS REFERENCE. IF YOU ARE UNABLE TO LOCATE THE SOFTWARE LICENSE OR LIMITED WARRANTY,

CONTACT YOUR CISCO REPRESENTATIVE FOR A COPY.

The Cisco implementation of TCP header compression is an adaptation of a program developed by the University of California, Berkeley (UCB) as part of UCB's public domain version of the UNIX operating system. All rights reserved. Copyright

1981, Regents of the University of California.

NOTWITHSTANDING ANY OTHER WARRANTY HEREIN, ALL DOCUMENT FILES AND SOFTWARE OF THESE SUPPLIERS ARE PROVIDED “AS IS" WITH ALL FAULTS.

CISCO AND THE ABOVE-NAMED SUPPLIERS DISCLAIM ALL WARRANTIES, EXPRESSED OR IMPLIED, INCLUDING, WITHOUT LIMITATION, THOSE OF

MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OR ARISING FROM A COURSE OF DEALING, USAGE, OR TRADE PRACTICE.

IN NO EVENT SHALL CISCO OR ITS SUPPLIERS BE LIABLE FOR ANY INDIRECT, SPECIAL, CONSEQUENTIAL, OR INCIDENTAL DAMAGES, INCLUDING, WITHOUT

LIMITATION, LOST PROFITS OR LOSS OR DAMAGE TO DATA ARISING OUT OF THE USE OR INABILITY TO USE THIS MANUAL, EVEN IF CISCO OR ITS SUPPLIERS

HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.

Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: http:// www.cisco.com/go/trademarks

. Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R)

C O N T E N T S

P r e f a c e

P A R T I

C H A P T E R 1

C H A P T E R 2

Preface liii

Audience

liii

Conventions

liii

Preface

This preface describes the audience, organization, and conventions of this document. It also provides information on how to obtain other documentation. This chapter includes the following sections:

•

Audience, page liii

•

Conventions, page liii

•

Audience

This publication is for experienced network administrators who configure and maintain Cisco wireless controllers and Cisco lightweight access points.

Conventions

This document uses the following conventions:

Table 1: Conventions

Convention

bold font

italic font

[ ]

{x | y | z }

[ x | y | z ]

Indication

Commands and keywords and user-entered text appear in bold font.

Document titles, new or emphasized terms, and arguments for which you supply values are in italic font.

Elements in square brackets are optional.

Required alternative keywords are grouped in braces and separated by vertical bars.

Optional alternative keywords are grouped in brackets and separated by vertical bars.

Cisco Wireless Controller Configuration Guide, Release 8.3 liii

Preface

Related Documentation

Convention

string courier font

[]

!, #

Indication

A nonquoted set of characters. Do not use quotation marks around the string.

Otherwise, the string will include the quotation marks.

Terminal sessions and information the system displays appear in courier font.

Nonprinting characters such as passwords are in angle brackets.

Default responses to system prompts are in square brackets.

An exclamation point (!) or a pound sign (#) at the beginning of a line of code indicates a comment line.

Note

Means reader take note. Notes contain helpful suggestions or references to material not covered in the manual.

Tip

Means the following information will help you solve a problem.

Caution

Means reader be careful. In this situation, you might perform an action that could result in equipment damage or loss of data.

Obtaining Documentation and Submitting a Service Request

For information on obtaining documentation, using the Cisco Bug Search Tool (BST), submitting a service request, and gathering additional information, see What's New in Cisco Product Documentation .

To receive new and revised Cisco technical content directly to your desktop, you can subscribe to the What's

New in Cisco Product Documentation RSS feed . RSS feeds are a free service.

Cisco Wireless Controller Configuration Guide, Release 8.3 lv

Obtaining Documentation and Submitting a Service Request

Preface lvi

Cisco Wireless Controller Configuration Guide, Release 8.3

P A R T

Overview

•

Cisco Wireless Solution Overview, page 3

•

Initial Setup, page 7

C H A P T E R

Cisco Wireless Solution Overview

•

Introduction, page 3

•

Cisco Wireless Controllers, page 4

•

Cisco Wireless Solution WLANs, page 5

Introduction

Cisco Wireless is designed to provide 802.11 wireless networking solutions for enterprises and service providers. Cisco Wireless simplifies deploying and managing large-scale wireless LANs and enables a unique best-in-class security infrastructure. The operating system manages all data client, communications, and system administration functions, performs radio resource management (RRM) functions, manages system-wide mobility policies using the operating system security solution, and coordinates all security functions using the operating system security framework.

Cisco Wireless solution consists of Cisco wireless controllers (Cisco WLCs) and their associated lightweight access points controlled by the operating system, all concurrently managed by any or all of the operating system user interfaces:

• An HTTP and/or HTTPS full-featured Web User Interface hosted by Cisco WLCs can be used to configure and monitor individual Cisco WLCs.

• A full-featured command-line interface (CLI) can be used to configure and monitor individual Cisco

Cisco WLCs.

• The Cisco Prime Infrastructure, which you use to configure and monitor one or more Cisco WLCs and associated access points. The Prime Infrastructure has tools to facilitate large-system monitoring and control. For more information about Cisco Prime Infrastructure, see http://www.cisco.com/c/en/us/support/cloud-systems-management/prime-infrastructure/tsd-products-support-series-home.html

• An industry-standard SNMP V1, V2c, and V3 interface can be used with any SNMP-compliant third-party network management system.

The Cisco Wireless solution supports client data services, client monitoring and control, and all rogue access point detection, monitoring, and containment functions. It uses lightweight access points, Cisco WLCs, and the optional Cisco Prime Infrastructure to provide wireless services to enterprises and service providers.

Cisco Wireless Controller Configuration Guide, Release 8.3

Cisco Wireless Controllers

For detailed information about Cisco Wireless solution, see the Enterprise Mobility Design Guide at http:// www.cisco.com/c/en/us/td/docs/wireless/controller/8-1/Enterprise-Mobility-8-1-Design-Guide/Enterprise_

Mobility_8-1_Deployment_Guide.html

Cisco Wireless Controllers

When you are adding lightweight access points to a multiple-Cisco WLC deployment network, it is convenient to have all lightweight access points associate with one master Cisco WLC on the same subnet. That way, you do not have to log into multiple Cisco WLCs to find out which controller the newly-added lightweight access points associated with.

One Cisco WLC in each subnet can be assigned as the master Cisco WLC while adding lightweight access points. As long as a master Cisco WLC is active on the same subnet, all new access points without a primary, secondary, and tertiary controller assigned automatically attempt to associate with the master Cisco WLC.

You can monitor the master Cisco WLC using the Cisco Prime Infrastructure and watch as access points associate with the master Cisco WLC. You can then verify the access point configuration and assign a primary, secondary, and tertiary Cisco WLC to the access point, and reboot the access point so it reassociates with its primary, secondary, or tertiary Cisco WLC.

Note

Lightweight access points without a primary, secondary, and tertiary Cisco WLC assigned always search for a master Cisco WLC first upon reboot. After adding lightweight access points through the master Cisco

WLC, you should assign primary, secondary, and tertiary Cisco WLCs to each access point. We recommend that you disable the master setting on all Cisco WLCs after initial configuration.

Client Location

When you use Cisco Prime Infrastructure in your Cisco wireless LAN solution, controllers periodically determine the client, rogue access point, rogue access point client, radio frequency ID (RFID) tag location and store the locations in the Cisco Prime Infrastructure database.

Cisco WLC Platforms

Cisco WLCs are enterprise-class high-performance wireless switching platforms that support 802.11a/n/ac and 802.11b/g/n protocols. They operate under control of the operating system, which includes the radio resource management (RRM), creating a Cisco Wireless solution that can automatically adjust to real-time changes in the 802.11 RF environment. Cisco WLCs are built around high-performance network and security hardware, resulting in highly reliable 802.11 enterprise networks with unparalleled security.

The following Cisco WLCs are supported:

• Cisco 2504 Wireless Controller

• Cisco 5508 Wireless Controller

• Cisco 5520 Wireless Controller

• Cisco Flex 7510 Wireless Controller

• Cisco 8510 Wireless Controller

Cisco Wireless Controller Configuration Guide, Release 8.3

Cisco Wireless Solution WLANs

• Cisco 8540 Wireless Controller

• Cisco Virtual Wireless Controller

• Catalyst Wireless Services Module 2 (WiSM2)

Cisco Wireless Solution WLANs

The Cisco Wireless solution can control up to 512 WLANs for lightweight access points. Each WLAN has a separate WLAN ID (1 through 512), a separate profile name, and a WLAN SSID and can be assigned with unique security policies. The lightweight access points broadcast all active Cisco Wireless solution WLAN

SSIDs and enforce the policies defined for each WLAN.

Note

We recommend that you assign one set of VLANs for WLANs and a different set of VLANs for management interfaces to ensure that controllers operate with optimum performance and ease of management.

If management over wireless is enabled across the Cisco Wireless solution, you can manage the system across the enabled WLAN using CLI and Telnet, HTTP/HTTPS, and SNMP.

Cisco Wireless Controller Configuration Guide, Release 8.3

Cisco Wireless Solution WLANs

Cisco Wireless Controller Configuration Guide, Release 8.3

C H A P T E R

Initial Setup

•

Cisco WLAN Express for Cisco Wireless Controllers, page 7

•

Configuring the Controller Using the Configuration Wizard, page 14

•

Using the AutoInstall Feature for Controllers Without a Configuration, page 27

•

Managing the Controller System Date and Time, page 30

Cisco WLAN Express for Cisco Wireless Controllers

Overview of Cisco WLAN Express

Cisco WLAN Express is a simplified, out-of-the-box installation and configuration interface for Cisco Wireless

Controllers. This section provides instructions to set up a Cisco WLC to operate in a small, medium, or large network wireless environment, where access points can join and together as a simple solution provide various services such as corporate employee or guest wireless access on the network.

There are two methods:

• Wired method

• Wireless method

With this, there are three ways to set up Cisco WLC:

• Cisco WLAN Express

• Traditional command line interface (CLI) via serial console

• Updated method using network connection directly to the WLC GUI setup wizard

Note

Cisco WLAN Express can be used only for the first time in out-of-the-box installations or when WLC configuration is reset to factory defaults.

Cisco Wireless Controller Configuration Guide, Release 8.3

Cisco WLAN Express for Cisco Wireless Controllers

Feature History

• Release 7.6.120.0—This feature was introduced and supported only on Cisco 2500 Series Wireless

Controller. It includes an easy-to-use GUI Configuration Wizard, an intuitive monitoring dashboard and several Cisco Wireless LAN best practices enabled by default.

• Release 8.0.110.0—The following enhancements were made:

• Connect to any port—You can connect a client device to any port on the Cisco 2500 Series WLC and access the GUI configuration wizard to run Cisco WLAN Express. Previously, you were required to connect the client device to only port 2.

• Wireless Support to run Cisco WLAN Express—You can connect an AP to any of the ports on the Cisco 2500 Series WLC, associate a client device with the AP, and run Cisco WLAN Express.

When the AP is associated with the Cisco 2500 Series WLC, only 802.11b and 802.11g radios are enabled; the 802.11a radio is disabled. The AP broadcasts an SSID named “CiscoAirProvision,” which is of WPA2-PSK type with the key being “password.” After a client device associates with this SSID, the client device automatically gets an IP address in the 192.168.x.x range. On the web browser of the client device, go to http://192.168.1.1 to open the GUI configuration wizard.

This feature is supported only on the following web browsers:

• Microsoft Internet Explorer 10 and later versions

• Mozilla Firefox 32 and later versions

Note

This feature is not supported on mobile devices such as smartphones and tablet computers.

• Release 8.1—The following enhancements are made:

• Added support for the Cisco WLAN Express using the wired method to Cisco 5500, Flex 7500,

8500 Series Wireless Controllers and Virtual Controller.

• Introduced the Main Dashboard view and compliance assessment and best practices. For more details, see the Cisco WLC Online Help.

Configuration Checklist

The following checklist is for your reference to make the installation process easy. Ensure that you have these requirements ready before you proceed:

Network switch requirements:

WLC switch port number assigned

WLC assigned switch port

Is the switch port configured as trunk or access?

Is there a management VLAN? If yes, Management VLAN ID

Is there a guest VLAN? If yes, Guest VLAN ID

Cisco Wireless Controller Configuration Guide, Release 8.3

Cisco WLAN Express for Cisco Wireless Controllers

WLC Settings:

New admin account name

Admin account password

System name for the WLC

Current time zone

Is there an NTP server available? If yes, NTP server IP address

WLC Management Interface:

IP address

Subnet Mask

Default gateway

Management VLAN ID

Corporate wireless network

Corporate wireless name/SSID

Is a RADIUS server required?

Security authentication option to select:

WPA/WPA2 Personal

Corporate passphrase (PSK)

WPA/WPA2 (Enterprise)

RADIUS server IP address and shared secret

Is a DHCP server known? If yes, DHCP server IP address

Guest Wireless Network - optional

Guest wireless name/SSID

Is a password required for guest?

Guest passphrase (PSK)

Guest VLAN ID

Guest networking

IP address

Subnet Mask

Default gateway

Advanced option—Configure RF Parameters for Client Density as Low, Medium, or High.

Cisco Wireless Controller Configuration Guide, Release 8.3

Cisco WLAN Express for Cisco Wireless Controllers

Preparing for Setup Using Cisco WLAN Express

• Do not auto-configure the WLC or use the wizard for configuration.

• Do not use console interface; the only connection to the WLC should be client connected to service port.

• Configure DHCP or assign static IP 192.168.1.X to laptop interface connected to service port.

Related Documentation

For more information about Cisco WLAN Express, see the WLAN Express Setup and Best Practices

Deployment Guide .

Restrictions on Cisco WLAN Express

• As of Release 8.1, the Cisco WLAN Express using the wireless method is supported only on Cisco 2500

Series WLC.

• If you use the CLI configuration wizard or AutoInstall, Cisco WLAN Express is bypassed and associated features are enabled.

• If you upgrade to Release 7.6.120.0 or a later release and do not perform a new configuration of the controller using the GUI Configuration Wizard, Cisco WLAN Express is not enabled. You must use the

GUI Configuration Wizard to enable the Cisco WLAN Express features.

• After you upgrade to Release 7.6.120.0 or a later release, you can clear the controller configuration and use the GUI Configuration Wizard to enable Cisco WLAN Express features.

• If you downgrade from Release 7.6.120.0 or a later release to an older release, Cisco WLAN Express features are disabled. However, the configurations generated through Cisco WLAN Express are not removed.

Setting up Cisco Wireless Controller using Cisco WLAN Express (Wired Method)

Step 1

Step 2

Step 3

Connect a laptop's wired Ethernet port directly to the Service port of the WLC. The port LEDs blink to indicate that both the machines are properly connected.

Note

It may take several minutes for the WLC to fully power on to make the GUI available to the PC. Do not auto-configure the WLC.

The LEDs on the front panel provide the system status:

• If the LED is off, it means that the WLC is not ready.

• If the LED is solid green, it means that the WLC is ready.

Configure DHCP option on the laptop that you have connected to the Service port. This assigns an IP address to the laptop from the WLC Service port 192.168.1.X, or you can assign a static IP address 192.168.1.X to the laptop to access the WLC GUI; both options are supported.

Open any one of the following supported web browsers and type http://192.168.1.1 in the address bar.

• Mozilla Firefox version 32 or later (Windows, MAC)

Cisco Wireless Controller Configuration Guide, Release 8.3

Cisco WLAN Express for Cisco Wireless Controllers

Step 4

Step 5

Step 6

Step 7

Step 8

Step 9

Step 10

• Microsoft Internet Explorer version 10 or later (Windows)

• Google Chrome version 38.x or later (Windows, MAC)

• Apple Safari version 7 or later (MAC)

Note

This feature is not supported on mobile devices such as smartphones and tablet computers.

Create an administrator account by providing the name and password. Click Start to continue.

In the Set Up Your Controller dialog box, enter the following details:

System Name for the WLC

Current time zone

NTP Server (optional)

Management IP Address

Subnet Mask

Default Gateway

Management VLAN ID—If left unchanged or set to 0, the network switch port must be configured with a native

VLAN 'X0'

Note

The setup attempts to import the clock information (date and time) from the computer via JavaScript. We recommend that you confirm this before continuing. Access points rely on correct clock settings to be able to join the WLC.

In the Create Your Wireless Networks dialog box, in the Employee Network area, use the checklist to enter the following data: a) Network name/SSID b) Security c) Pass Phrase, if Security is set to WPA/WPA2 Personal d) DHCP Server IP Address—If left empty, the DHCP processing is bridged to the management interface

(Optional) In the Create Your Wireless Networks dialog box, in the Guest Network area, use the checklist to enter the following data: a) Network name/SSID b) Security c) VLAN IP Address, VLAN Subnet Mask, VLAN Default Gateway, VLAN ID d) DHCP Server IP Address—If left empty, the DHCP processing is bridged to the management interface

In the Advanced Setting dialog box, in the RF Parameter Optimization area, do the following: a) Select the client density as Low, Typical, or High.

b) Configure the RF parameters for RF Traffic Type, such as Data and Voice.

c) Change the Service port IP address and subnet mask, if necessary.

Click Next.

Review your settings and then click Apply to confirm.

The WLC reboots automatically. You will be prompted that the WLC is fully configured and will be restarted. Sometimes, you might not be prompted with this message. In this scenario, do the following: a) Disconnect the laptop from the WLC service port and connect it to the Switch port.

Cisco Wireless Controller Configuration Guide, Release 8.3

Cisco WLAN Express for Cisco Wireless Controllers

b) Connect the WLC port 1 to the switch configured trunk port.

c) Connect access points to the switch if not already connected.

d) Wait until the access points join the WLC.

RF Profile Configurations

Step 1

Step 2

After a successful login as an administrator, choose Wireless > RF Profiles to verify whether the Cisco WLAN Express features are enabled by checking that the predefined RF profiles are created on this page.

You can define AP Groups and apply appropriate profile to a set of APs.

Choose Wireless > Advanced > Network Profile, verify the client density and traffic type details.

Note

We recommend that you use RF and Network profiles configuration even if Cisco WLAN Express was not used initially or if the WLC was upgraded from a release that is earlier than Release 8.1.

Setting up Cisco Wireless Controller using Cisco WLAN Express (Wireless Method)

This wireless method applies only to Cisco 2500 Series Wireless Controller.

Step 1

Step 2

Step 3

Step 4

Step 5

Plug in a Cisco AP to any one of the ports of Cisco 2500 Series WLC. If you do not have a separate power supply for the AP, you can use Port 3 or Port 4, which supports PoE.

After the AP boots up, the AP associates with the WLC and downloads the WLC software.

The AP starts provisioning a WPA2-PSK SSID "CiscoAirProvision" with the key "password."

Associate a client device to the "CiscoAirProvision" SSID.

The client device is assigned an IP address in the 192.168.x.x range.

On the web browser of the client device, go to http://192.168.1.1 to open the GUI configuration wizard.

Default Configurations

When you configure your Cisco Wireless Controller, the following parameters are enabled or disabled. These settings are different from the default settings obtained when you configure the controller using the CLI wizard.

Parameters in New Interface

Aironet IE

DHCP Address Assignment (Guest SSID)

Client Band Select

Value

Disabled

Enabled

Cisco Wireless Controller Configuration Guide, Release 8.3

Parameters in New Interface

Local HTTP and DHCP Profiling

Guest ACL

CleanAir

EDRRM

EDRRM Sensitivity Threshold

Channel Bonding (5 GHz)

DCA Channel Width mDNS Global Snooping

Default mDNS profile

AVC (only AV)

Management

Virtual IP Address

Multicast Address

Mobility Domain Name

RF Group Name

Cisco WLAN Express for Cisco Wireless Controllers

Value

Enabled

Applied.

Note

Guest ACL denies traffic to the management subnet.

Enabled

• Low sensitivity for 2.4 GHz.

• Medium sensitivity for 5 GHz.

Enabled

40 MHz

Enabled

Two new services added:

• Better printer support

• HTTP

Enabled only with following prerequisites:

• Bootloader version—1.0.18

• Field Upgradable Software version—1.8.0.0

and above

Note

If you upgrade the bootloader after you have setup the Cisco 2500 Series Controller using the GUI Wizard, you have to manually enable AVC on the previously created

WLAN.

• Via Wireless Clients—Enabled

• HTTP/HTTPS Access—Enabled

• WebAuth Secure Web—Enabled

192.0.2.1

Not configured

Name of employee SSID

Default

Cisco Wireless Controller Configuration Guide, Release 8.3

Configuring the Controller Using the Configuration Wizard

Configuring the Controller Using the Configuration Wizard

The configuration wizard enables you to configure basic settings on the controller. You can run the wizard after you receive the controller from the factory or after the controller has been reset to factory defaults. The configuration wizard is available in both GUI and CLI formats.

Configuring the Controller (GUI)

Step 1

Step 2

Connect your PC to the service port and configure it to use the same subnet as the controller.

Note

In case of Cisco 2504 WLC, connect your PC to the port 2 on the controller and configure to use the same subnet.

Browse to http://192.168.1.1. The configuration wizard appears.

Note

You can use both HTTP and HTTPS when using the service port interface. HTTPS is enabled by default and

Note

HTTP can also be enabled. The default IP address to connect to the service port interface is 192.168.1.1.

For the initial GUI Configuration Wizard only, you cannot access the Cisco WLC using IPv6 address.

Figure 1: Configuration Wizard — System Information Page

Step 3

Step 4

Step 5

In the System Name box, enter the name that you want to assign to this Cisco WLC. You can enter up to 31 ASCII characters.

In the User Name box, enter the administrative username to be assigned to this Cisco WLC. You can enter up to 24

ASCII characters. The default username is admin.

In the Password and Confirm Password boxes, enter the administrative password to be assigned to this Cisco WLC.

You can enter up to 24 ASCII characters. The default password is admin.

Cisco Wireless Controller Configuration Guide, Release 8.3

Configuring the Controller Using the Configuration Wizard

Step 6

Starting in release 7.0.116.0, the following password policy has been implemented:

• The password must contain characters from at least three of the following classes:

◦Lowercase letters

◦Uppercase letters

◦Digits

◦Special characters

• No character in the password must be repeated more than three times consecutively.

• The new password must not be the same as the associated username and not be the username reversed.

• The password must not be cisco, ocsic, or any variant obtained by changing the capitalization of letters of the word

Cisco. In addition, you cannot substitute 1, I, or ! for i, 0 for o, or $ for s.

Click Next. The SNMP Summary page is displayed.

Figure 2: Configuration Wizard—SNMP Summary Page

Step 7

If you want to enable Simple Network Management Protocol (SNMP) v1 mode for this Cisco WLC, choose Enable from the SNMP v1 Mode drop-down list. Otherwise, leave this parameter set to Disable.

Note

SNMP manages nodes (servers, workstations, routers, switches, and so on) on an IP network. Currently, there are three versions of SNMP: SNMPv1, SNMPv2c, and SNMPv3.

Cisco Wireless Controller Configuration Guide, Release 8.3

Configuring the Controller Using the Configuration Wizard

Step 8

Step 9

Step 10

Step 11

If you want to enable SNMPv2c mode for this Cisco WLC, leave this parameter set to Enable. Otherwise, choose Disable from the SNVP v2c Mode drop-down list.

If you want to enable SNMPv3 mode for this Cisco WLC, leave this parameter set to Enable. Otherwise, choose Disable from the SNVP v3 Mode drop-down list.

Click Next.

When the following message appears, click OK:

Default values are present for v1/v2c community strings.

Please make sure to create new v1/v2c community strings once the system comes up.

Please make sure to create new v3 users once the system comes up.

The Service Interface Configuration page is displayed.

Figure 3: Configuration Wizard-Service Interface Configuration Page

Step 12

Step 13

Step 14

If you want the Cisco WLC’s service-port interface to obtain an IP address from a DHCP server, check the DHCP

Protocol Enabled check box. If you do not want to use the service port or if you want to assign a static IP address to the service port, leave the check box unchecked.

Note

The service-port interface controls communications through the service port. Its IP address must be on a different subnet from the management interface. This configuration enables you to manage the controller directly or through a dedicated management network to ensure service access during network downtime.

Perform one of the following:

• If you enabled DHCP, clear out any entries in the IP Address and Netmask text boxes, leaving them blank.

• If you disabled DHCP, enter the static IP address and netmask for the service port in the IP Address and Netmask text boxes.

Click Next.

Cisco Wireless Controller Configuration Guide, Release 8.3

The LAG Configuration page is displayed.

Figure 4: Configuration Wizard—LAG Configuration Page

Configuring the Controller Using the Configuration Wizard

Step 15

Step 16

To enable link aggregation (LAG), choose Enabled from the Link Aggregation (LAG) Mode drop-down list. To disable

LAG, leave this text box set to Disabled.

Click Next.

The Management Interface Configuration page is displayed.

Note

The management interface is the default interface for in-band management of the controller and connectivity to enterprise services such as AAA servers.

Cisco Wireless Controller Configuration Guide, Release 8.3

Configuring the Controller Using the Configuration Wizard

Step 17

Step 18

Step 19

Step 20

Step 21

Step 22

Step 23

Step 24

Step 25

Step 26

Step 27

In the VLAN Identifier box, enter the VLAN identifier of the management interface (either a valid VLAN identifier or

0 for an untagged VLAN). The VLAN identifier should be set to match the switch interface configuration.

In the IP Address box, enter the IP address of the management interface.

In the Netmask box, enter the IP address of the management interface netmask.

In the Gateway box, enter the IP address of the default gateway.

In the Port Number box, enter the number of the port assigned to the management interface. Each interface is mapped to at least one primary port.

In the Backup Port box, enter the number of the backup port assigned to the management interface. If the primary port for the management interface fails, the interface automatically moves to the backup port.

In the Primary DHCP Server box, enter the IP address of the default DHCP server that will supply IP addresses to clients, the controller’s management interface, and optionally, the service port interface.

In the Secondary DHCP Server box, enter the IP address of an optional secondary DHCP server that will supply IP addresses to clients, the controller’s management interface, and optionally, the service port interface.

Click Next. The AP-Manager Interface Configuration page is displayed.

Note

This screen does not appear for Cisco 5508 WLCs because you are not required to configure an AP-manager interface. The management interface acts like an AP-manager interface by default.

In the IP Address box, enter the IP address of the AP-manager interface.

Click Next. The Miscellaneous Configuration page is displayed.

Figure 5: Configuration Wizard—Miscellaneous Configuration Page

Step 28

In the RF Mobility Domain Name box, enter the name of the mobility group/RF group to which you want the controller to belong.

Note

Although the name that you enter here is assigned to both the mobility group and the RF group, these groups are not identical. Both groups define clusters of controllers, but they have different purposes. All of the controllers in an RF group are usually also in the same mobility group and vice versa. However, a mobility group facilitates scalable, system-wide mobility and controller redundancy while an RF group facilitates scalable, system-wide dynamic RF management.

Cisco Wireless Controller Configuration Guide, Release 8.3

Configuring the Controller Using the Configuration Wizard

Step 29

Step 30

Step 31

The Configured Country Code(s) box shows the code for the country in which the controller will be used. If you want to change the country of operation, check the check box for the desired country.

Note

You can choose more than one country code if you want to manage access points in multiple countries from a single controller. After the configuration wizard runs, you must assign each access point joined to the controller to a specific country.

Click Next.

When the following message appears, click OK:

Warning! To maintain regulatory compliance functionality, the country code setting may only be modified by a network administrator or qualified IT professional.

Ensure that proper country codes are selected before proceeding.?

The Virtual Interface Configuration page is displayed.

Figure 6: Configuration Wizard — Virtual Interface Configuration Page

Step 32

Step 33

In the IP Address box, enter the IP address of the Cisco WLC’s virtual interface. You should enter a fictitious, unassigned

IP address.

Note

The virtual interface is used to support mobility management, DHCP relay, and embedded Layer 3 security such as guest web authentication and VPN termination. All controllers within a mobility group must be configured with the same virtual interface IP address.

In the DNS Host Name box, enter the name of the Domain Name System (DNS) gateway used to verify the source of certificates when Layer 3 web authorization is enabled.

Note

To ensure connectivity and web authentication, the DNS server should always point to the virtual interface. If a DNS hostname is configured for the virtual interface, then the same DNS hostname must be configured on the DNS servers used by the client.

Cisco Wireless Controller Configuration Guide, Release 8.3

Configuring the Controller Using the Configuration Wizard

Step 34

Click Next. The WLAN Configuration page is displayed.

Figure 7: Configuration Wizard — WLAN Configuration Page

Step 35

Step 36

Step 37

Step 38

In the Profile Name box, enter up to 32 alphanumeric characters for the profile name to be assigned to this WLAN.

In the WLAN SSID box, enter up to 32 alphanumeric characters for the network name, or service set identifier (SSID).

The SSID enables basic functionality of the Cisco WLC and allows access points that have joined the controller to enable their radios.

Click Next.

When the following message appears, click OK:

Default Security applied to WLAN is: [WPA2(AES)][Auth(802.1x)]. You can change this after the wizard is complete and the system is rebooted.?

Cisco Wireless Controller Configuration Guide, Release 8.3

The RADIUS Server Configuration page is displayed.

Figure 8: Configuration Wizard-RADIUS Server Configuration Page

Configuring the Controller Using the Configuration Wizard

Step 39

Step 40

In the Server IP Address box, enter the IP address of the RADIUS server.

From the Shared Secret Format drop-down list, choose ASCII or Hex to specify the format of the shared secret.

Note

Due to security reasons, the RADIUS shared secret key reverts to ASCII mode even if you have selected HEX as the shared secret format from the Shared Secret Format drop-down list.

Cisco Wireless Controller Configuration Guide, Release 8.3

Configuring the Controller Using the Configuration Wizard

Step 41

Step 42

Step 43

Step 44

In the Shared Secret and Confirm Shared Secret boxes, enter the secret key used by the RADIUS server.

In the Port Number box, enter the communication port of the RADIUS server. The default value is 1812.

To enable the RADIUS server, choose Enabled from the Server Status drop-down list. To disable the RADIUS server, leave this box set to Disabled.

Click Apply. The 802.11 Configuration page is displayed.

Figure 9: Configuration Wizard—802.11 Configuration Page

Step 45

Step 46

To enable the 802.11a, 802.11b, and 802.11g lightweight access point networks, leave the 802.11a Network Status,

802.11b Network Status, and 802.11g Network Status check boxes checked. To disable support for any of these networks, uncheck the check boxes.

To enable the controller’s radio resource management (RRM) auto-RF feature, leave the Auto RF check box selected.

To disable support for the auto-RF feature, uncheck this check box.

Note

The auto-RF feature enables the controller to automatically form an RF group with other controllers. The group dynamically elects a leader to optimize RRM parameter settings, such as channel and transmit power assignment, for the group.

Cisco Wireless Controller Configuration Guide, Release 8.3

Step 47

Click Next. The Set Time page is displayed.

Figure 10: Configuration Wizard — Set Time Screen

Configuring the Controller Using the Configuration Wizard

Step 48

Step 49

To manually configure the system time on your controller, enter the current date in Month/DD/YYYY format and the current time in HH:MM:SS format.

To manually set the time zone so that Daylight Saving Time (DST) is not set automatically, enter the local hour difference from Greenwich Mean Time (GMT) in the Delta Hours box and the local minute difference from GMT in the Delta

Mins box.

Note

When manually setting the time zone, enter the time difference of the local current time zone with respect to

GMT (+/–). For example, Pacific time in the United States is 8 hours behind GMT. Therefore, it is entered as

–8.

Cisco Wireless Controller Configuration Guide, Release 8.3

Configuring the Controller Using the Configuration Wizard

Step 50

Click Next. The Configuration Wizard Completed page is displayed.

Figure 11: Configuration Wizard—Configuration Wizard Completed Page

Step 51

Step 52

Click Save and Reboot to save your configuration and reboot the Cisco WLC.

When the following message appears, click OK:

Configuration will be saved and the controller will be rebooted. Click ok to confirm.?

The Cisco WLC saves your configuration, reboots, and prompts you to log on.

Configuring the Controller—Using the CLI Configuration Wizard

Before You Begin

• The available options appear in brackets after each configuration parameter. The default value appears in all uppercase letters.

• If you enter an incorrect response, the controller provides you with an appropriate error message, such as “Invalid Response,” and returns you to the wizard prompt.

• Press the hyphen key if you ever need to return to the previous command line.

Step 1

When prompted to terminate the AutoInstall process, enter yes. If you do not enter yes, the AutoInstall process begins after 30 seconds.

Cisco Wireless Controller Configuration Guide, Release 8.3

Configuring the Controller Using the Configuration Wizard

Step 2

Step 3

Step 4

Step 5

Step 6

Step 7

Step 8

Step 9

Step 10

Step 11

Step 12

Step 13

Note

The AutoInstall feature downloads a configuration file from a TFTP server and then loads the configuration onto the controller automatically.

Enter the system name, which is the name that you want to assign to the controller. You can enter up to 31 ASCII characters.

Enter the administrative username and password to be assigned to this controller. You can enter up to 24 ASCII characters for each.

Starting in release 7.0.116.0, the following password policy has been implemented:

• The password must contain characters from at least three of the following classes:

• Lowercase letters

• Uppercase letters

• Digits

• Special characters

• No character in the password must be repeated more than three times consecutively.

• The new password must not be the same as the associated username and not be the username reversed.

• The password must not be cisco, ocsic, or any variant obtained by changing the capitalization of letters of the word

Cisco. In addition, you cannot substitute 1, I, or ! for i, 0 for o, or $ for s.

If you want the controller’s service-port interface to obtain an IP address from a DHCP server, enter DHCP. If you do not want to use the service port or if you want to assign a static IP address to the service port, enter none.

Note

If you entered none in Step 4, enter the IP address and netmask for the service-port interface on the next two lines.

Enable or disable link aggregation (LAG) by choosing yes or NO.

Enter the IP address of the management interface.

Note

The management interface is the default interface for in-band management of the controller and connectivity to enterprise services such as AAA servers.

Enter the IP address of the management interface netmask.

Enter the IP address of the default router.

Enter the VLAN identifier of the management interface (either a valid VLAN identifier or 0 for an untagged VLAN).

The VLAN identifier should be set to match the switch interface configuration.

Enter the IP address of the default DHCP server that will supply IP addresses to clients, the management interface of the controller, and optionally, the service port interface. Enter the IP address of the AP-manager interface.

Note

This prompt does not appear for Cisco 5500 Series Controllers because you are not required to configure an

AP-manager interface. The management interface acts like an AP-manager interface by default.

Enter the IP address of the controller’s virtual interface. You should enter a fictitious unassigned IP address.

Note

If desired, enter the name of the mobility group/RF group to which you want the controller to belong.

Cisco Wireless Controller Configuration Guide, Release 8.3

Configuring the Controller Using the Configuration Wizard

Step 14

Step 15

Step 16

Step 17

Step 18

Step 19

Step 20

Step 21

Step 22

Step 23

Step 24

Step 25

Step 26

Step 27

Step 28

Step 29

Note

Enter the network name or service set identifier (SSID). The SSID enables basic functionality of the controller and allows access points that have joined the controller to enable their radios.

Enter YES to allow clients to assign their own IP address or no to require clients to request an IP address from a DHCP server.

To configure a RADIUS server now, enter YES and then enter the IP address, communication port, and secret key of the RADIUS server. Otherwise, enter no. If you enter no, the following message appears: “Warning! The default WLAN security policy requires a RADIUS server. Please see the documentation for more details.”

Enter the code for the country in which the controller will be used.

Note

Enter help to view the list of available country

Note

codes.

You can enter more than one country code if you want to manage access points in multiple countries from a single controller. To do so, separate the country codes with a comma (for example, US,CA,MX). After the configuration wizard runs, you need to assign each access point joined to the controller to a specific country.

Enable or disable the 802.11b, 802.11a, and 802.11g lightweight access point networks by entering YES or no.

Enable or disable the controller’s radio resource management (RRM) auto-RF feature by entering YES or no.

Note

If you want the controller to receive its time setting from an external Network Time Protocol (NTP) server when it powers up, enter YES to configure an NTP server. Otherwise, enter no.

Note

The controller network module installed in a Cisco Integrated Services Router does not have a battery and cannot save a time setting. Therefore, it must receive a time setting from an external NTP server when it powers up.

If you entered no in Step 20 and want to manually configure the system time on your controller now, enter YES. If you do not want to configure the system time now, enter no.

If you entered YES in Step 21, enter the current date in the MM/DD/YY format and the current time in the HH:MM:SS format.

After you have completed step 22, the wizard prompts you to configure IPv6 parameters. Enter yes to proceed.

Enter the service port interface IPv6 address configuration. You can enter either static or SLAAC.

• If you entered, SLAAC, then IPv6 address is autoconfigured.

• If you entered, static, you need to enter the IPv6 address and its prefix length of the service interface.

Enter the IPv6 address of the management interface.

Enter the IPv6 address prefix length of the management interface.

Enter the gateway IPv6 address of the management interface .

Once the management interface configuration is complete, the wizard prompts to configure IPv6 parameters for RADIUS server. Enter yes.

Enter the IPv6 address of the RADIUS server.

Enter the communication port number of the RADIUS server. The default value is 1812.

Enter the secret key for IPv6 address of the RADIUS server.

Cisco Wireless Controller Configuration Guide, Release 8.3

Using the AutoInstall Feature for Controllers Without a Configuration

Step 30

Step 31

Once the RADIUS server configuration is complete, the wizard prompts to configure IPv6 NTP server. Enter yes.

Enter the IPv6 address of the NTP server.

When prompted to verify that the configuration is correct, enter yes or NO.

The Cisco WLC saves your configuration when you enter yes, reboots, and prompts you to log on.

Using the AutoInstall Feature for Controllers Without a Configuration

This section describes how to use the AutoInstall feature for controllers without a configuration.

Information About the AutoInstall Feature

When you boot up a controller that does not have a configuration, the AutoInstall feature can download a configuration file from a TFTP server and then load the configuration onto the controller automatically.

If you create a configuration file on a controller that is already on the network (or through a Prime Infrastructure filter), place that configuration file on a TFTP server, and configure a DHCP server so that a new controller can get an IP address and TFTP server information, the AutoInstall feature can obtain the configuration file for the new controller automatically.

When the controller boots, the AutoInstall process starts. The controller does not take any action until

AutoInstall is notified that the configuration wizard has started. If the wizard has not started, the controller has a valid configuration.

If AutoInstall is notified that the configuration wizard has started (which means that the controller does not have a configuration), AutoInstall waits for an additional 30 seconds. This time period gives you an opportunity to respond to the first prompt from the configuration wizard:

Would you like to terminate autoinstall? [yes]:

When the 30-second abort timeout expires, AutoInstall starts the DHCP client. You can abort the AutoInstall task even after this 30-second timeout if you enter Yes at the prompt. However, AutoInstall cannot be aborted if the TFTP task has locked the flash and is in the process of downloading and installing a valid configuration file.

Note

The AutoInstall process and manual configuration using both the GUI and CLI of Cisco WLC can occur in parallel. As part of the AutoInstall cleanup process, the service port IP address is set to 192.168.1.1 and the service port protocol configuration is modified. Because the AutoInstall process takes precedence over the manual configuration, whatever manual configuration is performed is overwritten by the AutoInstall process.

Restrictions on AutoInstall

• In Cisco 5508 WLCs, the following interfaces are used:

◦eth0—Service port (untagged)

◦dtl0—Gigabit port 1 through the NPU (untagged)

Cisco Wireless Controller Configuration Guide, Release 8.3

Using the AutoInstall Feature for Controllers Without a Configuration

• AutoInstall is not supported on Cisco 2504 WLC.

Obtaining an IP Address Through DHCP and Downloading a Configuration File from a TFTP Server

AutoInstall attempts to obtain an IP address from the DHCP server until the DHCP process is successful or until you abort the AutoInstall process. The first interface to successfully obtain an IP address from the DHCP server registers with the AutoInstall task. The registration of this interface causes AutoInstall to begin the process of obtaining TFTP server information and downloading the configuration file.

Following the acquisition of the DHCP IP address for an interface, AutoInstall begins a short sequence of events to determine the host name of the controller and the IP address of the TFTP server. Each phase of this sequence gives preference to explicitly configured information over default or implied information and to explicit host names over explicit IP addresses.

The process is as follows:

• If at least one Domain Name System (DNS) server IP address is learned through DHCP, AutoInstall creates a /etc/resolv.conf file. This file includes the domain name and the list of DNS servers that have been received. The Domain Name Server option provides the list of DNS servers, and the Domain Name option provides the domain name.

• If the domain servers are not on the same subnet as the controller, static route entries are installed for each domain server. These static routes point to the gateway that is learned through the DHCP Router option.

• The host name of the controller is determined in this order by one of the following:

◦If the DHCP Host Name option was received, this information (truncated at the first period [.]) is used as the host name for the controller.

◦A reverse DNS lookup is performed on the controller IP address. If DNS returns a hostname, this name (truncated at the first period [.]) is used as the hostname for the controller.

• The IP address of the TFTP server is determined in this order by one of the following:

◦If AutoInstall received the DHCP TFTP Server Name option, AutoInstall performs a DNS lookup on this server name. If the DNS lookup is successful, the returned IP address is used as the IP address of the TFTP server.

◦If the DHCP Server Host Name (sname) text box is valid, AutoInstall performs a DNS lookup on this name. If the DNS lookup is successful, the IP address that is returned is used as the IP address of the TFTP server.

◦If AutoInstall received the DHCP TFTP Server Address option, this address is used as the IP address of the TFTP server.

◦AutoInstall performs a DNS lookup on the default TFTP server name (cisco-wlc-tftp). If the DNS lookup is successful, the IP address that is received is used as the IP address of the TFTP server.

◦If the DHCP server IP address (siaddr) text box is nonzero, this address is used as the IP address of the TFTP server.

◦The limited broadcast address (255.255.255.255) is used as the IP address of the TFTP server.

Cisco Wireless Controller Configuration Guide, Release 8.3

Using the AutoInstall Feature for Controllers Without a Configuration

• If the TFTP server is not on the same subnet as the controller, a static route (/32) is installed for the IP address of the TFTP server. This static route points to the gateway that is learned through the DHCP

Router option.

Selecting a Configuration File

After the hostname and TFTP server have been determined, AutoInstall attempts to download a configuration file. AutoInstall performs three full download iterations on each interface that obtains a DHCP IP address. If the interface cannot download a configuration file successfully after three attempts, the interface does not attempt further.

The first configuration file that is downloaded and installed successfully triggers a reboot of the controller.

After the reboot, the controller runs the newly downloaded configuration.

AutoInstall searches for configuration files in the order in which the names are listed:

• The filename that is provided by the DHCP Boot File Name option

• The filename that is provided by the DHCP File text box

• host name-confg

• host name.cfg

• base MAC address-confg (for example, 0011.2233.4455-confg)

• serial number-confg

• ciscowlc-confg

• ciscowlc.cfg

AutoInstall runs through this list until it finds a configuration file. It stops running if it does not find a configuration file after it cycles through this list three times on each registered interface.

Note

The downloaded configuration file can be a complete configuration, or it can be a minimal configuration that provides enough information for the controller to be managed by the Cisco Prime Infrastructure. Full configuration can then be deployed directly from the Prime Infrastructure.

Note

AutoInstall does not expect the switch connected to the controller to be configured for either channels.

AutoInstall works with a service port in LAG configuration.

Note

Cisco Prime Infrastructure provides AutoInstall capabilities for controllers. A Cisco Prime Infrastructure administrator can create a filter that includes the host name, the MAC address, or the serial number of the controller and associate a group of templates (a configuration group) to this filter rule. The Prime

Infrastructure pushes the initial configuration to the controller when the controller boots up initially. After the controller is discovered, the Prime Infrastructure pushes the templates that are defined in the configuration group. For more information about the AutoInstall feature and Cisco Prime Infrastructure, see the Cisco Prime Infrastructure documentation.

Cisco Wireless Controller Configuration Guide, Release 8.3

Managing the Controller System Date and Time

Example: AutoInstall Operation

The following is an example of an AutoInstall process from start to finish:

Welcome to the Cisco Wizard Configuration Tool

Use the '-' character to backup

Would you like to terminate autoinstall? [yes]:

AUTO-INSTALL: starting now...

AUTO-INSTALL: interface 'service-port' - setting DHCP TFTP Filename ==> 'abcd-confg'

AUTO-INSTALL: interface 'service-port' - setting DHCP TFTP Server IP ==> 1.100.108.2

AUTO-INSTALL: interface 'service-port' - setting DHCP siaddr ==> 1.100.108.2

AUTO-INSTALL: interface 'service-port' - setting DHCP Domain Server[0] ==> 1.100.108.2

AUTO-INSTALL: interface 'service-port' - setting DHCP Domain Name ==> 'engtest.com'

AUTO-INSTALL: interface 'service-port' - setting DHCP yiaddr ==> 172.19.29.253

AUTO-INSTALL: interface 'service-port' - setting DHCP Netmask ==> 255.255.255.0

AUTO-INSTALL: interface 'service-port' - setting DHCP Gateway ==> 172.19.29.1

AUTO-INSTALL: interface 'service-port' registered

AUTO-INSTALL: interation 1 -- interface 'service-port'

AUTO-INSTALL: DNS reverse lookup 172.19.29.253 ===> 'wlc-1'

AUTO-INSTALL: hostname 'wlc-1'

AUTO-INSTALL: TFTP server 1.100.108.2 (from DHCP Option 150)

AUTO-INSTALL: attempting download of 'abcd-confg'

AUTO-INSTALL: TFTP status - 'TFTP Config transfer starting.' (2)

AUTO-INSTALL: interface 'management' - setting DHCP file ==> 'bootfile1'

AUTO-INSTALL: interface 'management' - setting DHCP TFTP Filename ==> 'bootfile2-confg'

AUTO-INSTALL: interface 'management' - setting DHCP siaddr ==> 1.100.108.2

AUTO-INSTALL: interface 'management' - setting DHCP Domain Server[0] ==> 1.100.108.2

AUTO-INSTALL: interface 'management' - setting DHCP Domain Server[1] ==> 1.100.108.3

AUTO-INSTALL: interface 'management' - setting DHCP Domain Server[2] ==> 1.100.108.4

AUTO-INSTALL: interface 'management' - setting DHCP Domain Name ==> 'engtest.com'

AUTO-INSTALL: interface 'management' - setting DHCP yiaddr ==> 1.100.108.238

AUTO-INSTALL: interface 'management' - setting DHCP Netmask ==> 255.255.254.0

AUTO-INSTALL: interface 'management' - setting DHCP Gateway ==> 1.100.108.1

AUTO-INSTALL: interface 'management' registered

AUTO-INSTALL: TFTP status - 'Config file transfer failed - Error from server: File not found' (3)

AUTO-INSTALL: attempting download of 'wlc-1-confg'

AUTO-INSTALL: TFTP status - 'TFTP Config transfer starting.' (2)

AUTO-INSTALL: TFTP status - 'TFTP receive complete... updating configuration.' (2)

AUTO-INSTALL: TFTP status - 'TFTP receive complete... storing in flash.' (2)

AUTO-INSTALL: TFTP status - 'System being reset.' (2)

Resetting system

Managing the Controller System Date and Time

This section describes how to manage the date and time of a controller system.

Information About Controller System Date and Time

You can configure the controller system date and time at the time of configuring the controller using the configuration wizard. If you did not configure the system date and time through the configuration wizard or if you want to change your configuration, you can follow the instructions in this section to configure the controller to obtain the date and time from a Network Time Protocol (NTP) server or to configure the date and time manually. Greenwich Mean Time (GMT) is used as the standard for setting the time zone on the controller.

You can also configure an authentication mechanism between various NTP servers.

Cisco Wireless Controller Configuration Guide, Release 8.3

Managing the Controller System Date and Time

Restrictions on Configuring the Cisco WLC Date and Time

• If you are configuring wIPS, you must set the controller time zone to UTC.

• Cisco Aironet lightweight access points might not connect to the controller if the date and time are not set properly. Set the current date and time on the controller before allowing the access points to connect to it.

• You can configure an authentication channel between the controller and the NTP server.

Configuring the Date and Time (GUI)

Step 1

Choose Commands > Set Time to open the Set Time page.

Figure 12: Set Time Page

Step 2

Step 3

Step 4

Step 5

The current date and time appear at the top of the page.

In the Timezone area, choose your local time zone from the Location drop-down list.

Note

When you choose a time zone that uses Daylight Saving Time (DST), the controller automatically sets its system clock to reflect the time change when DST occurs. In the United States, DST starts on the second Sunday in

March and ends on the first Sunday in November.

Note

You cannot set the time zone delta on the controller GUI. However, if you do so on the Cisco WLC CLI, the change is reflected in the Delta Hours and Mins boxes on the Cisco WLC GUI.

Click Set Timezone to apply your changes.

In the Date area, choose the current local month and day from the Month and Day drop-down lists, and enter the year in the Year box.

In the Time area, choose the current local hour from the Hour drop-down list, and enter the minutes and seconds in the

Minutes and Seconds boxes.

Cisco Wireless Controller Configuration Guide, Release 8.3

Managing the Controller System Date and Time

Step 6

Step 7

Note

If you change the time zone location after setting the date and time, the values in the Time area are updated to reflect the time in the new time zone location. For example, if the controller is currently configured for noon

Eastern time and you change the time zone to Pacific time, the time automatically changes to 9:00 a.m.

Click Set Date and Time to apply your changes.

Click Save Configuration.

Configuring the Date and Time (CLI)

Step 1

Step 2

Configure the current local date and time in GMT on the controller by entering this command:

config time manual mm/dd/yy hh:mm:ss

Note

When setting the time, the current local time is entered in terms of GMT and as a value between 00:00 and

24:00. For example, if it is 8:00 a.m. Pacific time in the United States, you would enter 16:00 because the Pacific time zone is 8 hours behind GMT.

Perform one of the following to set the time zone for the controller:

• Set the time zone location in order to have Daylight Saving Time (DST) set automatically when it occurs by entering this command:

config time timezone location location_index where location_index is a number representing one of the following time zone locations:

(GMT-12:00) International Date Line West

(GMT-11:00) Samoa

(GMT-10:00) Hawaii

(GMT-9:00) Alaska

(GMT-8:00) Pacific Time (US and Canada)

(GMT-7:00) Mountain Time (US and Canada)

(GMT-6:00) Central Time (US and Canada)

(GMT-5:00) Eastern Time (US and Canada)

(GMT-4:00) Atlantic Time (Canada)

10 (GMT-3:00) Buenos Aires (Argentina)

11 (GMT-2:00) Mid-Atlantic

12 (GMT-1:00) Azores

13 (GMT) London, Lisbon, Dublin, Edinburgh (default value)

14 (GMT +1:00) Amsterdam, Berlin, Rome, Vienna

15 (GMT +2:00) Jerusalem

16 (GMT +3:00) Baghdad

Cisco Wireless Controller Configuration Guide, Release 8.3

Managing the Controller System Date and Time

Step 3

Step 4

17 (GMT +4:00) Muscat, Abu Dhabi

18 (GMT +4:30) Kabul

19 (GMT +5:00) Karachi, Islamabad, Tashkent

20 (GMT +5:30) Colombo, Kolkata, Mumbai, New Delhi

21 (GMT +5:45) Katmandu

22 (GMT +6:00) Almaty, Novosibirsk

23 (GMT +6:30) Rangoon

24 (GMT +7:00) Saigon, Hanoi, Bangkok, Jakarta

25 (GMT +8:00) Hong Kong, Beijing, Chongqing

26 (GMT +9:00) Tokyo, Osaka, Sapporo

27 (GMT +9:30) Darwin

28 (GMT+10:00) Sydney, Melbourne, Canberra

29 (GMT+11:00) Magadan, Solomon Is., New Caledonia

30 (GMT+12:00) Kamchatka, Marshall Is., Fiji

31 (GMT+12:00) Auckland (New Zealand)

Note

If you enter this command, the controller automatically sets its system clock to reflect DST when it occurs.

In the United States, DST starts on the second Sunday in March and ends on the first Sunday in November.

• Manually set the time zone so that DST is not set automatically by entering this command:

config time timezone delta_hours delta_mins where delta_hours is the local hour difference from GMT, and delta_mins is the local minute difference from GMT.

When manually setting the time zone, enter the time difference of the local current time zone with respect to GMT

(+/–). For example, Pacific time in the United States is 8 hours behind GMT. Therefore, it is entered as –8.

Note

You can manually set the time zone and prevent DST from being set only on the controller

CLI.

Save your changes by entering this command:

save config

Verify that the controller shows the current local time with respect to the local time zone by entering this command:

show time

Information similar to the following appears:

Time.................................... Thu Apr 7 13:56:37 2011

Timezone delta........................... 0:0

Timezone location....................... (GMT +5:30) Colombo, New Delhi, Chennai, Kolkata

NTP Servers

NTP Polling Interval.........................

3600

Cisco Wireless Controller Configuration Guide, Release 8.3

Managing the Controller System Date and Time

Note

Index NTP Key Index NTP Server NTP Msg Auth Status

---------------------------------------------------------------------

1 1 209.165.200.225

AUTH SUCCESS

If you configured the time zone location, the Timezone Delta value is set to “0:0.” If you manually configured the time zone using the time zone delta, the Timezone Location is blank.

Cisco Wireless Controller Configuration Guide, Release 8.3

P A R T

Management of Cisco WLC

•

Administration of Cisco WLC, page 37

•

Managing Licenses, page 51

•

Managing Software, page 75

•

Managing Configuration, page 91

•

Network Time Protocol Setup, page 105

•

High Availability, page 109

•

Managing Certificates, page 123

•

AAA Administration, page 137

•

Managing Users, page 175

•

Ports and Interfaces, page 183

•

IPv6, page 219

•

Access Control Lists, page 225

•

Multicast/Broadcast Setup, page 247

•

Cisco WLC Security, page 271

C H A P T E R

Administration of Cisco WLC

•

HTTP/HTTPS, SSH/Telnet to Cisco WLC, page 37

HTTP/HTTPS, SSH/Telnet to Cisco WLC

Using the Controller GUI

A browser-based GUI is built into each controller.

It allows up to five users to simultaneously browse into the controller HTTP or HTTPS (HTTP + SSL) management pages to configure parameters and monitor the operational status for the controller and its associated access points.

For detailed descriptions of the Controller GUI, see the Online Help. To access the online help, click Help on the Controller GUI.

Note

We recommend that you enable the HTTPS interface and disable the HTTP interface to ensure more robust security.

Restrictions on using Controller GUI

Follow these guidelines when using the controller GUI:

• The controller Web UI is compatible with the following web browsers

◦Microsoft Internet Explorer 11 and later versions

◦Mozilla Firefox 32 and later versions

• To view the Main Dashboard that is introduced in Release 8.1.102.0, you must enable JavaScript on the web browser.

Cisco Wireless Controller Configuration Guide, Release 8.3

HTTP/HTTPS, SSH/Telnet to Cisco WLC

Note

Ensure that the screen resolution is set to 1280x800 or more. Lesser resolutions are not supported.

• You can use either the service port interface or the management interface to access the GUI.

• You can use both HTTP and HTTPS when using the service port interface. HTTPS is enabled by default and HTTP can also be enabled. The default IP address to connect to the service port interface is

192.168.1.1.

• Click Help at the top of any page in the GUI to display online help. You might need to disable your browser’s pop-up blocker to view the online help.

Logging On to the GUI

Note

Do not configure TACACS authentication when the controller is set to use local authentication.

Step 1

Step 2

Enter the controller IP address in your browser’s address bar. For a secure connection, enter https://ip-address. For a less secure connection, enter http://ip-address.

When prompted, enter a valid username and password, and click OK.

The Summary page is displayed.

Note

The administrative username and password that you created in the configuration wizard are case sensitive. The default username is admin, and the default password is admin.

Logging out of the GUI

Step 1

Step 2

Step 3

Click Logout in the top right corner of the page.

Click Close to complete the log out process and prevent unauthorized users from accessing the controllercontroller GUI.

When prompted to confirm your decision, click Yes.

Enabling Web and Secure Web Modes

This section provides instructions to enable the distribution system port as a web port (using HTTP) or as a secure web port (using HTTPS). You can protect communication with the GUI by enabling HTTPS. HTTPS protects HTTP browser sessions by using the Secure Sockets Layer (SSL) protocol. When you enable HTTPS, the controller generates its own local web administration SSL certificate and automatically applies it to the

GUI. You also have the option of downloading an externally generated certificate.

Cisco Wireless Controller Configuration Guide, Release 8.3

HTTP/HTTPS, SSH/Telnet to Cisco WLC

You can configure web and secure web mode using the controller GUI or CLI.

Enabling Web and Secure Web Modes (GUI)

Step 1

Step 2

Step 3

Step 4

Step 5

Step 6

Step 7

Step 8

Step 9

Choose Management > HTTP-HTTPS.

The HTTP-HTTPS Configuration page is displayed.

To enable web mode, which allows users to access the controller GUI using “http://ip-address,” choose Enabled from the HTTP Access drop-down list. Otherwise, choose Disabled. The default value is Disabled. Web mode is not a secure connection.

To enable secure web mode, which allows users to access the controller GUI using “https://ip-address,” choose Enabled from the HTTPS Access drop-down list. Otherwise, choose Disabled. The default value is Enabled. Secure web mode is a secure connection.

In the Web Session Timeout text box, enter the amount of time, in minutes, before the web session times out due to inactivity. You can enter a value between 10 and 160 minutes (inclusive). The default value is 30 minutes.

Click Apply.

If you enabled secure web mode in Step 3, the controller generates a local web administration SSL certificate and automatically applies it to the GUI. The details of the current certificate appear in the middle of the HTTP-HTTPS

Configuration page.

Note

If desired, you can delete the current certificate by clicking Delete Certificate and have the controller generate a new certificate by clicking Regenerate Certificate.

Choose Controller > General to open the General page.

Choose one of the following options from the Web Color Theme drop-down list:

• Default—Configures the default web color theme for the controller GUI.

• Red—Configures the web color theme as red for the controller GUI.

Click Apply.

Click Save Configuration.

Enabling Web and Secure Web Modes (CLI)

Step 1

Step 2

Step 3

Enable or disable web mode by entering this command:

config network webmode {enable | disable}

This command allows users to access the controller GUI using "http://ip-address." The default value is disabled. Web mode is not a secure connection.

Configure the web color theme for the controller GUI by entering this command:

config network webcolor {default | red}

The default color theme for the controller GUI is enabled. You can change the default color scheme as red using the red option. If you are changing the color theme from the controller CLI, you need to reload the controller GUI screen to apply your changes.

Enable or disable secure web mode by entering this command:

config network secureweb {enable | disable}

Cisco Wireless Controller Configuration Guide, Release 8.3

HTTP/HTTPS, SSH/Telnet to Cisco WLC

Step 4

Step 5

Step 6

Step 7

Step 8

Step 9

Step 10

This command allows users to access the controller GUI using “https://ip-address.” The default value is enabled. Secure web mode is a secure connection.

Enable or disable secure web mode with increased security by entering this command:

config network secureweb cipher-option high {enable | disable}

This command allows users to access the controller GUI using “https://ip-address” but only from browsers that support

128-bit (or larger) ciphers. The default value is disabled.

Enable or disable SSLv2 for web administration by entering this command:

config network secureweb cipher-option sslv2 {enable | disable}

If you disable SSLv2, users cannot connect using a browser configured with SSLv2 only. They must use a browser that is configured to use a more secure protocol such as SSLv3 or later. The default value is disabled.

Enable or disable preference for RC4-SHA (Rivest Cipher 4-Secure Hash Algorithm) cipher suites (over CBC cipher suites) for web authentication and web administration by entering this command:

config network secureweb cipher-option rc4-preference {enable | disable}

Verify that the controller has generated a certificate by entering this command:

show certificate summary

Information similar to the following appears:

Web Administration Certificate................. Locally Generated

Web Authentication Certificate................. Locally Generated

Certificate compatibility mode:................ off

(Optional) Generate a new certificate by entering this command:

config certificate generate webadmin

After a few seconds, the controller verifies that the certificate has been generated.

Save the SSL certificate, key, and secure web password to nonvolatile RAM (NVRAM) so that your changes are retained across reboots by entering this command:

save config

Reboot the controller by entering this command:

reset system

Using the Controller CLI

A Cisco UWN solution command-line interface (CLI) is built into each controller. The CLI enables you to use a VT-100 terminal emulation program to locally or remotely configure, monitor, and control individual controllers and its associated lightweight access points. The CLI is a simple text-based, tree-structured interface that allows up to five users with Telnet-capable terminal emulation programs to access the controller.

Note

See the Cisco Wireless Controller Command Reference for information about specific commands.

Cisco Wireless Controller Configuration Guide, Release 8.3

HTTP/HTTPS, SSH/Telnet to Cisco WLC

Note

If you want to input any strings from the XML configuration into CLI commands, you must enclose the strings in quotation marks.

Logging on to the Controller CLI

You can access the controller CLI using one of the following two methods:

• A direct serial connection to the controller console port

• A remote console session over Ethernet through the preconfigured service port or the distribution system ports

Before you log on to the CLI, configure your connectivity and environment variables based on the type of connection you use.

Guidelines and Limitations

On Cisco 5500 Series Controllers, you can use either the RJ-45 console port or the USB console port. If you use the USB console port, plug the 5-pin mini Type B connector into the controller’s USB console port and the other end of the cable into the PC’s USB Type A port. The first time that you connect a Windows PC to the USB console port, you are prompted to install the USB console driver. Follow the installation prompts to install the driver. The USB console driver maps to a COM port on your PC; you then need to map the terminal emulator application to the COM port.

See the

Telnet and Secure Shell Sessions

section for information on enabling Telnet sessions.

Using a Local Serial Connection

Before You Begin

You need these items to connect to the serial port:

• A PC that is running a VT-100 terminal emulation program (such as HyperTerminal, ProComm, Minicom, or Tip)

• A null-modem serial cable

To log on to the controller CLI through the serial port, follow these steps:

Step 1

Step 2

Connect one end of a null-modem serial cable to the controller’s console port and the other end to your PC’s serial port.

Start the PC’s VT-100 terminal emulation program. Configure the terminal emulation program for these parameters:

• 9600 baud

• 8 data bits

• 1 stop bit

• No parity

• No hardware flow control

Note

Minimum serial timeout on Controller is 15 seconds instead of 1 minute.

Cisco Wireless Controller Configuration Guide, Release 8.3

HTTP/HTTPS, SSH/Telnet to Cisco WLC

Step 3

Note

The controller serial port is set for a 9600 baud rate and a short timeout. If you would like to change either of these values, enter config serial baudrate baudrate and config serial timeout timeout to make your changes. If you enter config serial timeout 0, serial sessions never time out.

When prompted, enter a valid username and password to log into the controller. The administrative username and password that you created in the configuration wizard are case sensitive.

Note

The default username is admin, and the default password is admin.

The CLI displays the root level system prompt:

#(system prompt)>

Note

The system prompt can be any alphanumeric string up to 31 characters. You can change it by entering the config

prompt command.

Using a Remote Ethernet Connection

Before You Begin

You need these items to connect to a controller remotely:

• A PC with access to the controller over the Ethernet network

• The IP address of the controller

• A VT-100 terminal emulation program or a DOS shell for the Telnet session

Note

By default, controllers block Telnet sessions. You must use a local connection to the serial port to enable

Telnet sessions.

Step 1

Step 2

Step 3

Verify that your VT-100 terminal emulation program or DOS shell interface is configured with these parameters:

• Ethernet address

• Port 23

Use the controller IP address to Telnet to the CLI.

When prompted, enter a valid username and password to log into the controller. The administrative username and password that you created in the configuration wizard are case sensitive.

Note

The default username is admin, and the default password is admin.

The CLI displays the root level system prompt.

Note

The system prompt can be any alphanumeric string up to 31 characters. You can change it by entering the config

prompt command.

Cisco Wireless Controller Configuration Guide, Release 8.3

HTTP/HTTPS, SSH/Telnet to Cisco WLC

Logging Out of the CLI

When you finish using the CLI, navigate to the root level and enter logout. The system prompts you to save any changes you made to the volatile RAM.

Note

The CLI automatically logs you out without saving any changes after 5 minutes of inactivity. You can set the automatic logout from 0 (never log out) to 160 minutes using the config serial timeout command.

Navigating the CLI

The CLI is organized into five levels:

• Root Level

• Level 2

• Level 3

• Level 4

• Level 5

When you log into the CLI, you are at the root level. From the root level, you can enter any full command without first navigating to the correct command level.

The following table lists commands you use to navigate the CLI and to perform common tasks.

Table 2: Commands for CLI Navigation and Common Tasks

Command

help

command ?

exit

Ctrl-Z save config reset system

Action

At the root level, view system wide navigation commands

View commands available at the current level

View parameters for a specific command

Move down one level

Return from any level to the root level

At the root level, save configuration changes from active working RAM to nonvolatile RAM (NVRAM) so they are retained after reboot

At the root level, reset the controller without logging out

Cisco Wireless Controller Configuration Guide, Release 8.3

HTTP/HTTPS, SSH/Telnet to Cisco WLC

Telnet and Secure Shell Sessions

Information About Telnet and SSH

Telnet is a network protocol used to provide access to the controller’s CLI. Secure Shell (SSH) is a more secure version of Telnet that uses data encryption and a secure channel for data transfer. You can use the controller GUI or CLI to configure Telnet and SSH sessions.

Restrictions on Telnet and SSH

• Only the FIPS approved algorithm aes128-cbc is supported when using SSH to control WLANs.

• The controller does not support raw Telnet mode.

Configuring Telnet and SSH Sessions (GUI)

Step 1

Choose Management > Telnet-SSH to open the Telnet-SSH Configuration page.

Figure 13: Telnet-SSH Configuration Page

Cisco Wireless Controller Configuration Guide, Release 8.3

HTTP/HTTPS, SSH/Telnet to Cisco WLC

Step 2

Step 3

Step 4

Step 5

Step 6

Step 7

Step 8

Step 9

In the Telnet Login Timeout text box, enter the number of minutes that a Telnet session is allowed to remain inactive before being terminated. The valid range is 0 to 160 minutes (inclusive), and the default value is 5 minutes. A value of

0 indicates no timeout.

From the Maximum Number of Sessions drop-down list, choose the number of simultaneous Telnet or SSH sessions allowed. The valid range is 0 to 5 sessions (inclusive), and the default value is 5 sessions. A value of zero indicates that

Telnet/SSH sessions are disallowed.

To forcefully close current login sessions, choose Management > User Sessions > close from the CLI session drop-down list.

From the Allow New Telnet Sessions drop-down list, choose Yes or No to allow or disallow new Telnet sessions on the controller. The default value is No.

From the \ drop-down list, choose Yes or No to allow or disallow new SSH sessions on the controller. The default value is Yes.

Click Apply.

Click Save Configuration.

To see a summary of the Telnet configuration settings, choose Management > Summary. The Summary page appears.

Figure 14: Summary Page

This page shows whether additional Telnet and SSH sessions are permitted.

Note

If you are unable to create a new telnet session, close the existing sessions by following the steps:

Configuring Telnet and SSH Sessions (CLI)

Step 1

Allow or disallow new Telnet sessions on the controller by entering this command:

config network telnet {enable | disable}

Cisco Wireless Controller Configuration Guide, Release 8.3

HTTP/HTTPS, SSH/Telnet to Cisco WLC

Step 2

Step 3

Step 4

Step 5

Step 6

Step 7

Step 8

The default value is disabled.

Allow or disallow new SSH sessions on the controller by entering this command:

config network ssh {enable | disable}

The default value is enabled.

Note

Use the config network ssh cipher-option high {enable | disable} command to enable sha2 which is supported in WLC.

Configure SSH access host-key by entering these commands:

• Generate or regenerate SSH host key by entering this command:

config network ssh host-key generate

This command generates a 1024-bit key.

• Use device certificate private key as SSH host key by entering this command:

config network ssh host-key use-device-certificate-key

This command generates a 2048-bit key.

Specify the number of minutes that a Telnet session is allowed to remain inactive before being terminated by entering this command:

config sessions timeout timeout where timeout is a value between 0 and 160 minutes (inclusive). The default value is 5 minutes. A value of 0 indicates no timeout.

Specify the number of simultaneous Telnet or SSH sessions allowed by entering this command:

config sessions maxsessions session_num where session_num is a value between 0 and 5 (inclusive). The default value is 5 sessions. A value of zero indicates that

Telnet/SSH sessions are disallowed.

Save your changes by entering this command:

save config

See the Telnet and SSH configuration settings by entering this command:

show network summary

Information similar to the following appears:

RF-Network Name............................. TestNetwork1

Web Mode.................................... Enable

Secure Web Mode............................. Enable

Secure Web Mode Cipher-Option High.......... Disable

Secure Web Mode Cipher-Option SSLv2......... Disable

Secure Shell (ssh).......................... Enable

Telnet................................... Disable

...

See the Telnet session configuration settings by entering this command:

show sessions

Cisco Wireless Controller Configuration Guide, Release 8.3

HTTP/HTTPS, SSH/Telnet to Cisco WLC

Step 9

Step 10

Step 11

Information similar to the following appears:

CLI Login Timeout (minutes)............ 5

Maximum Number of CLI Sessions....... 5

See all active Telnet sessions by entering this command:

show login-session

Information similar to the following appears:

ID User Name Connection From Idle Time Session Time

-- ---------------------------------------------------

00 admin EIA-232 00:00:00 00:19:04

You can clear Telnet or SSH sessions by entering this command:

clear session session-id

The session-id for the clearing the session should be taken from the show login-session command.

You can close all the Telnet or SSH sessions by entering this command:

config loginsession close {session-id | all}

The session-id can be taken from the show login-session command.

Configuring Telnet Privileges for Selected Management Users (GUI)

Using the controller, you can configure Telnet privileges to selected management users. To do this, you must have enabled Telnet privileges at the global level. By default, all management users have Telnet privileges enabled.

Note

SSH sessions are not affected by this feature.

Step 1

Step 2

Step 3

Step 4

Choose Management > Local Management Users.

On the Local Management Users page, select or unselect the Telnet Capable check box for a management user.

Click Apply.

Click Save Configuration.

Configuring Telnet Privileges for Selected Management Users (CLI)

• Configure Telnet privileges for a selected management user by entering this command:

config mgmtuser telnet user-name {enable | disable}

Cisco Wireless Controller Configuration Guide, Release 8.3

HTTP/HTTPS, SSH/Telnet to Cisco WLC

Management over Wireless

Information About Management over Wireless

The management over wireless feature allows you to monitor and configure local controllers using a wireless client. This feature is supported for all management tasks except uploads to and downloads from (transfers to and from) the controller.

Restrictions on Management over Wireless

• Management over Wireless can be disabled only if clients are on central switching.

Enabling Management over Wireless (GUI)

Step 1

Step 2

Step 3

Step 4

Choose Management > Mgmt Via Wireless to open the Management Via Wireless page.

Select the Enable Controller Management to be accessible from Wireless Clients check box to enable management over wireless for the WLAN or unselect it to disable this feature. The default value is unselected.

Click Apply to commit your changes.

Click Save Configuration to save your changes.

Enabling Management over Wireless (CLI)

Step 1

Step 2

Verify whether the management over wireless interface is enabled or disabled by entering this command:

show network summary

• If disabled: Enable management over wireless by entering this command:config network mgmt-via-wireless

enable

• Otherwise, use a wireless client to associate with an access point connected to the controller that you want to manage.

Log into the CLI to verify that you can manage the WLAN using a wireless client by entering this command:

telnet controller-ip-address command

Cisco Wireless Controller Configuration Guide, Release 8.3

HTTP/HTTPS, SSH/Telnet to Cisco WLC

Management by Dynamic Interface

Information About Using Dynamic Interfaces for Management

You can access the controller with one of its dynamic interface IP addresses. Both the wired and wireless clients can access the dynamic interface of the controller using the CLI and GUI. To access the GUI of the controller enter the dynamic interface IP address of the controller in the address field of either Internet Explorer or Mozilla Firefox browser. For wired clients, you must enable management of dynamic interface and must ensure that the wired client is in the VLAN that is mapped to the dynamic interface.

A device, when the management using dynamic interfaces is disabled, can open an SSH connection, if the protocol is enabled. However, you are not prompted to log on. Additionally, the management address remains accessible from a dynamic interface VLAN, unless a CPU ACL is in place. When management using dynamic interface is enabled along with CPU ACL, the CPU ACL has more priority.

The following are some examples of management access and management access using dynamic interfaces, here the management VLAN IP address of the Cisco WLC is 209.165. 201.1 and dynamic VLAN IP address of the Cisco WLC is 209.165. 202.129:

• Source wired client from Cisco WLC's dynamic interface VLAN accesses the management interface

VLAN and tries for management access.

• Source wired client from Cisco WLC's management interface VLAN accesses the dynamic interface

VLAN and tries for management access.

• Source wired client from Cisco WLC's dynamic interface VLAN accesses the dynamic interface VLAN tries and tries for management access.

• Source wired client from Layer 3 VLAN interface accesses the dynamic interface or the management interface and tries for management access.

Here, management is not the management interface but the configuration access. If the Cisco WLC configuration is accessed from any other IP address on the Cisco WLC other than the management IP, it is management using dynamic interface.

Configuring Management using Dynamic Interfaces (CLI)

Enable or disable management using dynamic interfaces by entering this command:

config network mgmt-via-dynamic-interface {enable | disable}

Cisco Wireless Controller Configuration Guide, Release 8.3

HTTP/HTTPS, SSH/Telnet to Cisco WLC

Cisco Wireless Controller Configuration Guide, Release 8.3

C H A P T E R

Managing Licenses

•

Installing and Configuring Licenses, page 51

•

Configuring Right to Use Licensing, page 62

•

Rehosting Licenses, page 64

•

Cisco Smart Software Licensing, page 68

•

Call-Home, page 71

•

Retrieving the Unique Device Identifier on WLCs and APs, page 73

Installing and Configuring Licenses

Information About Installing and Configuring Licenses

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.

• Cisco Flex 7500 and Cisco 8500 Series Controllers—The DTLS license is in-built. You are not required to install DTLS license separately.

Cisco Wireless Controller Configuration Guide, Release 8.3

Installing and Configuring Licenses

• 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.

Restrictions for Using Licenses

The following are the restrictions you must keep in mind when using licenses for the controllers:

• The licensing change can affect features on your wireless LAN when you upgrade or downgrade software releases, so you should be aware of these guidelines:

◦If you have a WPlus license and you upgrade from 6.0.x.x to 7.x.x.x, your license file contains both Basic and WPlus license features. There is no disruption in feature availability and operation.

◦If you have a WPlus license and you downgrade from 7.x.x.x to 6.0.196.0 or 6.0.188.0 or 6.0.182.0, your license file contains only base license, and you will lose all WPlus features.

◦If you have a base license and you downgrade from 6.0.196.0 to 6.0.188.0 or 6.0.182.0, when you downgrade, you lose all WPlus features.

• In the controller software 7.0.116.0 and later releases, the AP association trap is ciscoLwappApAssociated.

In prior releases, the trap was bsnAPAssociated.

• The ap-count licenses and their corresponding image-based licenses are installed together. The controller keeps track of the licensed access point count and does not allow more than the number of access points to associate to it.

• The Cisco 5500 Series Controller is shipped with both permanent and evaluation base and base-ap-count licenses. If desired, you can activate the evaluation licenses, which are designed for temporary use and set to expire after 60 days.

• No licensing steps are required after you receive your Cisco 5500 Series Controller because the licenses you ordered are installed at the factory. In addition, licenses and product authorization keys (PAKs) are preregistered to serial numbers. However, as your wireless network evolves, you might want to add support for additional access points or upgrade from the standard software set to the base software set.

To do so, you must obtain and install an upgrade license.

Obtaining an Upgrade or Capacity Adder License

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

Information About Obtaining an Upgrade or Capacity Adder License

A certificate with a product authorization key (PAK) is required before you can obtain an upgrade license.

Cisco Wireless Controller Configuration Guide, Release 8.3

Installing and Configuring Licenses

You can use the capacity adder licenses to increase the number of access points supported by the controller up to a maximum of 500 access points. The capacity adder licenses are available in access point capacities of

10, 25, 50, 100 and 250 access points. You can add these licenses to any of the base capacity licenses of 12,

25, 50, 100 and 250 access points.

For example, if your controller was initially ordered with support for 100 access points (base license

AIR-CT5508-100-K9), you could increase the capacity to 500 access points by purchasing a 250 access point,

100 access point, and a 50 access point additive capacity license (LIC-CT5508-250A, LIC-CT5508-100A, and LIC-CT5508-50A).

You can find more information on ordering capacity adder licenses at this URL: http://www.cisco.com/c/en/us/products/wireless/5500-series-wireless-controllers/datasheet-listing.html

Note

If you skip any tiers when upgrading (for example, if you do not install the -25U and -50U licenses along with the -100U), the license registration for the upgraded capacity fails.

For a single controller, you can order different upgrade licenses in one transaction (for example, -25U, -50U,

-100U, and -250U), for which you receive one PAK with one license. Then you have only one license (instead of four) to install on your controller.

If you have multiple controllers and want to upgrade all of them, you can order multiple quantities of each upgrade license in one transaction (for example, you can order 10 each of the -25U, -50U, -100U, and -250 upgrade licenses), for which you receive one PAK with one license. You can continue to register the PAK for multiple controllers until it is exhausted.

For more information about the base license SKUs and capacity adder licenses, see the respective controller’s data sheet.

Obtaining and Registering a PAK Certificate

Step 1

Step 2

Step 3

Order the PAK certificate for an upgrade license through your Cisco channel partner or your Cisco sales representative, or order it online at this URL: http://www.cisco.com/go/ordering

If you are ordering online, begin by choosing the primary upgrade SKU L-LIC-CT5508-UPG or LIC CT5508-UPG.

Then, choose any number of the following options to upgrade one or more controllers under one PAK. After you receive the certificate, use one of the following methods to register the PAK:

• Licensing portal—This alternative method enables you to manually obtain and install licenses on your controller.

If you want to use the licensing portal to register the PAK, follow the instructions in Step 3.

Use the licensing portal to register the PAK as follows: a) Go to http://tools.cisco.com/SWIFT/Licensing/PrivateRegistrationServlet b) On the main Product License Registration page, enter the PAK mailed with the certificate in the Product Authorization

Key (PAK) text box and click Submit.

c) On the Validate Features page, enter the number of licenses that you want to register in the Qty text box and click

Update.

d) To determine the controller’s product ID and serial number, choose Controller > Inventory on the controller GUI or enter the show license udi command on the controller CLI.

Cisco Wireless Controller Configuration Guide, Release 8.3

Installing and Configuring Licenses

Information similar to the following appears on the controller CLI:

Device# PID SN UDI

------------------------- -------------------------------------

*0 AIR-CT5508-K9 CW1308L030 AIR-CT5508-K9:FCW1308L030 e) On the Designate Licensee page, enter the product ID and serial number of the controller on which you plan to install the license, read and accept the conditions of the end-user license agreement (EULA), complete the rest of the text boxes on this page, and click Submit.

f) On the Finish and Submit page, verify that all information is correct and click Submit.

g) When a message appears indicating that the registration is complete, click Download License. The license is e-mailed within 1 hour to the address that you specified.

h) When the e-mail arrives, follow the instructions provided.

i) Copy the license file to your TFTP server.

Installing a License

Installing a License (GUI)

Step 1

Step 2

Step 3

Step 4

Step 5

Step 6

Step 7

Choose Management > Software Activation > Commands to open the License Commands page.

From the Action drop-down list, choose Install License. The Install License from a File section appears.

In the File Name to Install text box, enter the path to the license (*.lic) on the TFTP server.

Click Install License. A message appears to show whether the license was installed successfully. If the installation fails, the message provides the reason for the failure, such as the license is an existing license, the path was not found, the license does not belong to this device, you do not have correct permissions for the license, and so on.

If the end-user license agreement (EULA) acceptance dialog box appears, read the agreement and click Accept to accept the terms of the agreement.

Note

Typically, you are prompted to accept the EULA for evaluation, extension, and rehost licenses. The EULA is also required for permanent licenses, but it is accepted during license generation.

Save a backup copy of all installed licenses as follows: a) From the Action drop-down list, choose Save License.

b) In the File Name to Save text box, enter the path on the TFTP server where you want the licenses to be saved.

Note

You cannot save evaluation licenses.

c) Click Save Licenses.

Reboot the controller.

Note

We recommend that you reset the system to ensure that the newly installed license file is saved in the

WLC.

Cisco Wireless Controller Configuration Guide, Release 8.3

Installing and Configuring Licenses

Installing a License (CLI)

Step 1

Step 2

Step 3

Step 4

Step 5

Install a license on the controller by entering this command:

license install url where url is tftp://server_ip/path/filename.

Note

To remove a license from the controller, enter the license clear license_name command. For example, you might want to delete an expired evaluation license or any unused license. You cannot delete unexpired evaluation licenses, the permanent base image license, or licenses that are in use by the controller.

If you are prompted to accept the end-user license agreement (EULA), read and accept the terms of the agreement.

Note

Typically, you are prompted to accept the EULA for evaluation, extension, and rehost licenses. The EULA is also required for permanent licenses, but it is accepted during license generation.

Add comments to a license or delete comments from a license by entering this command:

license comment {add | delete} license_name comment_string

Save a backup copy of all installed licenses by entering this command:

license save url where url is tftp://server_ip/path/filename.

Reboot the controller by entering this command:

reset system.

Note

We recommend that you reset the system to ensure that the newly installed license file is saved in the

WLC.

Viewing Licenses

Viewing Licenses (GUI)

Step 1

Step 2

Choose Management > Software Activation > Licenses to open the Licenses page.

This page lists all of the licenses installed on the controller. For each license, it shows the license type, expiration, count

(the maximum number of access points allowed for this license), priority (low, medium, or high), and status (in use, not in use, inactive, or EULA not accepted).

Note

Controller platforms do not support the status of “grace period” or “extension” as a license type. The license status will always show “evaluation” even if a grace period or an extension evaluation license is installed.

Note

If you ever want to remove a license from the controller, hover your cursor over the blue drop-down arrow for the license and click Remove. For example, you might want to delete an expired evaluation license or any unused license. You cannot delete unexpired evaluation licenses, the permanent base image license, or licenses that are in use by the controller.

Click the link for the desired license to view more details for a particular license. The License Detail page appears.

This page shows the following additional information for the license:

Cisco Wireless Controller Configuration Guide, Release 8.3

Installing and Configuring Licenses

Step 3

Step 4

• The license type (permanent, evaluation, or extension)

• The license version

• The status of the license (in use, not in use, inactive, or EULA not accepted)

• The length of time before the license expires

Note

Permanent licenses never expire.

• Whether the license is a built-in license

• The maximum number of access points allowed for this license

• The number of access points currently using this license

If you want to enter a comment for this license, type it in the Comment text box and click Apply.

Click Save Configuration to save your changes.

Viewing Licenses (CLI)

Before You Begin

• See the license level, license type, and number of access points licensed on the controller by entering this command:

show sysinfo

This example shows a sample output of the command run on Cisco 8540 Wireless Controller using

Release 8.3:

Manufacturer's Name.............................. Cisco Systems Inc.

Product Name..................................... Cisco Controller

Product Version.................................. 8.3.100.0

RTOS Version..................................... 8.3.100.0

Bootloader Version............................... 8.0.110.0

Emergency Image Version.......................... 8.0.110.0

OUI File Last Update Time........................ Sun Sep 07 10:44:07 IST 2014

Build Type....................................... DATA + WPS

System Name...................................... TestSpartan8500Dev1

System Location..................................

System Contact...................................

System ObjectID.................................. 1.3.6.1.4.1.9.1.1615

Redundancy Mode.................................. Disabled

IP Address....................................... 8.1.4.2

IPv6 Address..................................... ::

System Up Time................................... 0 days 17 hrs 20 mins 58 secs

--More-- or (q)uit

System Timezone Location.........................

System Stats Realtime Interval................... 5

System Stats Normal Interval..................... 180

Configured Country............................... Multiple Countries : IN,US

Operating Environment............................ Commercial (10 to 35 C)

Cisco Wireless Controller Configuration Guide, Release 8.3

Installing and Configuring Licenses

Internal Temp Alarm Limits....................... 10 to 38 C

Internal Temperature............................. +21 C

Fan Status....................................... OK

RAID Volume Status

Drive 0.......................................... Good

Drive 1.......................................... Good

State of 802.11b Network......................... Enabled

State of 802.11a Network......................... Enabled

Number of WLANs.................................. 7

Number of Active Clients......................... 1

OUI Classification Failure Count................. 0

Burned-in MAC Address............................ F4:CF:E2:0A:27:00

Power Supply 1................................... Present, OK

--More-- or (q)uit

Power Supply 2................................... Present, OK

Maximum number of APs supported.................. 6000

System Nas-Id....................................

WLC MIC Certificate Types........................ SHA1/SHA2

Licensing Type................................... RTU

Note

The Operating Environment and Internal Temp Alarm Limits data are not displayed for

Cisco Flex 7500 Series Controllers.

• See a brief summary of all active licenses installed on the controller by entering this command:

show license summary

Information similar to the following appears:

Index 1 Feature: wplus

Period left: 0 minute 0 second

Index 2 Feature: wplus-ap-count

Period left: 0 minute 0 second

Index3 Feature: base

Period left: Life time

License Type: Permanent

License State: Active, In Use

License Count: Non-Counted

License Priority: Medium

Index 4 Feature: base-ap-count

Period left: 6 weeks, 4 days

License Type: Evaluation

License State: Active, In Use

License Count: 250/250/0

License Priority: High

• See all of the licenses installed on the controller by entering this command:

show license all

Information similar to the following appears:

License Store: Primary License Storage

StoreIndex: 1 Feature: base Version: 1.0

License Type: Permanent

License State: Active, Not in Use

License Count: Non-Counted

License Priority: Medium

StoreIndex: 3 Feature: base-ap-count Version: 1.0

Cisco Wireless Controller Configuration Guide, Release 8.3

Installing and Configuring Licenses

License Type: Evaluation

License State: Active, In Use

Evaluation total period: 8 weeks 4 days

Evaluation period left: 8 weeks 3 days

License Count: 250/0/0

License Priority: High

• See the details for a particular license by entering this command:

show license detail license_name

Information similar to the following appears:

Index: 1 Feature: base-ap-count Version: 1.0

License Type: Permanent

License State: Active, Not in Use

License Count: 12/0/0

License Priority: Medium

Store Index: 0

Store Name: Primary License Storage

Index: 2 Feature: base-ap-count Version: 1.0

License Type: Evaluation

License State: Inactive

Evaluation total period: 8 weeks 4 days

Evaluation period left: 8 weeks 4 days

License Count: 250/0/0

License Priority: Low

Store Index: 3

Store Name: Evaluation License Storage

• See all expiring, evaluation, permanent, or in-use licenses by entering this command:

show license {expiring | evaluation | permanent | in-use}

Information similar to the following appears for the show license in-use command:

StoreIndex: 2 Feature: base-ap-count Version: 1.0

License Type: Permanent

License State: Active, In Use

License Count: 12/12/0

License Priority: Medium

StoreIndex: 3 Feature: base Version: 1.0

License Type: Permanent

License State: Active, In Use

License Count: Non-Counted License Priority: Medium

Note

• See the maximum number of access points allowed for this license on the controller, the number of access points currently joined to the controller, and the number of access points that can still join the controller by entering this command:

show license capacity

Information similar to the following appears:

Licensed Feature

----------------

AP Count

Max Count

---------

250

Current Count

-------------

Remaining Count

---------------

246

Cisco Wireless Controller Configuration Guide, Release 8.3

Installing and Configuring Licenses

• See statistics for all licenses on the controller by entering this command:

show license statistics

• See a summary of license-enabled features by entering this command:

show license feature

Configuring the Maximum Number of Access Points Supported

Configuring Maximum Number of Access Points to be Supported (GUI)

You can configure the maximum number APs that can be supported on a controller. The controller limits the number of APs that are supported based on the licensing information and the controller model. The maximum number of APs supported that is specified in the licensing information overrides the number that you configure if the configured value is greater than the licensed value. By default, this feature is disabled. You must reboot the controller if you change the configuration.

Step 1

Step 2

Step 3

Step 4

Choose Controller > General.

Enter a value in the Maximum Allowed APs text box.

Click Apply.

Click Save Configuration.

Configuring Maximum Number of Access Points to be Supported (CLI)

• Configure the maximum number of access points to be supported on a controller by entering this command:

config ap max-count count

• See the maximum number of access points that are supported on the controller by entering this command:

show ap max-count summary

Troubleshooting Licensing Issues

• 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}

Cisco Wireless Controller Configuration Guide, Release 8.3

Installing and Configuring Licenses

Activating an AP-Count Evaluation License

Information About Activating an AP-Count Evaluation License

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.

Activating an AP-Count Evaluation License (GUI)

Step 1

Step 2

Step 3

Choose Management > Software Activation > Licenses to open the Licenses page.

The Status column shows which licenses are currently in use, and the Priority column shows the current priority of each license.

Activate an ap-count evaluation license as follows: a) Click the link for the ap-count evaluation license that you want to activate. The License Detail page appears.

b) Choose High from the Priority drop-down list and click Set Priority.

Note

You can set the priority only for ap-count evaluation licenses. AP-count permanent licenses always have a medium priority, which cannot be configured.

c) Click OK when prompted to confirm your decision about changing the priority of the license.

d) When the EULA appears, read the terms of the agreement and then click Accept.

e) When prompted to reboot the controller, click OK.

f) Reboot the controller in order for the priority change to take effect.

g) Click Licenses to open the Licenses page and verify that the ap-count evaluation license now has a high priority and is in use. You can use the evaluation license until it expires.

If you decide to stop using the ap-count evaluation license and want to revert to using an ap-count permanent license, follow these steps: a) On the Licenses page, click the link for the ap-count evaluation license that is in use.

b) Choose Low from the Priority drop-down list and click Set Priority.

Note

You can set the priority only for ap-count evaluation licenses. AP-count permanent licenses always have a medium priority, which cannot be configured.

c) Click OK when prompted to confirm your decision about changing the priority of the license.

Cisco Wireless Controller Configuration Guide, Release 8.3

Installing and Configuring Licenses

d) When the EULA appears, read the terms of the agreement and then click Accept.

e) When prompted to reboot the controller, click OK.

f) Reboot the controller in order for the priority change to take effect.

g) Click Licenses to open the Licenses page and verify that the ap-count evaluation license now has a low priority and is not in use. Instead, the ap-count permanent license should be in use.

Activating an AP-Count Evaluation License (CLI)

Step 1

Step 2

See the current status of all the licenses on your controller by entering this command:

show license all

Information similar to the following appears:

License Store: Primary License Storage

StoreIndex: 0 Feature: base-ap-count Version: 1.0

License Type: Permanent

License State: Active, In Use

License Count: 12/0/0

License Priority: Medium

StoreIndex: 1 Feature: base Version: 1.0

License Type: Permanent

License State: Active, In Use

License Count: Non-Counted

License Priority: Medium

StoreIndex: 2 Feature: base Version: 1.0

License Type: Evaluation

License State: Inactive

Evaluation total period: 8 weeks 4 days

Evaluation period left: 8 weeks 4 days

License Count: Non-Counted

License Priority: Low

StoreIndex: 3 Feature: base-ap-count Version: 1.0

License Type: Evaluation

License State: Inactive

Evaluation total period: 8 weeks 4 days

Evaluation period left: 8 weeks 4 days

License Count: 250/0/0

License Priority: Low

The License State text box shows the licenses that are in use, and the License Priority text box shows the current priority of each license.

Note

In the 7.2.110.0 release, the command output displays the full in-use count for active base-ap-count license even though there are no APs connected.

Activate an ap-count evaluation license as follows: a) Raise the priority of the base-ap-count evaluation license by entering this command:

license modify priority license_name high

Cisco Wireless Controller Configuration Guide, Release 8.3

Configuring Right to Use Licensing

Step 3

Note

You can set the priority only for ap-count evaluation licenses. AP-count permanent licenses always have a medium priority, which cannot be configured.

b) Reboot the controller in order for the priority change to take effect by entering this command:

reset system

c) Verify that the ap-count evaluation license now has a high priority and is in use by entering this command:

show license all

You can use the evaluation license until it expires.

If you decide to stop using the ap-count evaluation license and want to revert to using an ap-count permanent license, follow these steps: a) Lower the priority of the ap-count evaluation license by entering this command:

license modify priority license_name low b) Reboot the controller in order for the priority change to take effect by entering this command:

reset system

c) Verify that the ap-count evaluation license now has a low priority and is not in use by entering this command:

show license all

Instead, the ap-count permanent license should be in use.

Configuring Right to Use Licensing

Information About Right to Use Licensing

Right to Use (RTU) licensing is a model in which licenses are not tied to a unique device identifier (UDI), product ID, or serial number. Use RTU licensing to enable a desired AP license count on the controller after you accept the End User License Agreement (EULA). This allows you to add AP counts on a controller interacting with external tools.

RTU licensing is supported only on the following Cisco Wireless Controller platforms:

• Cisco 5520 WLC

• Cisco Flex 7510 WLC

• Cisco 8510 WLC

• Cisco 8540 WLC

• Cisco vWLC

In the RTU licensing model, the following types of licenses are available:

• Permanent or base licenses—These licenses are programmed into the controller hardware at the time of manufacturing. These licenses are base count licenses that cannot be deleted or transferred.

• Adder licenses—These licenses are wireless access point count licenses that you can activate by accepting the RTU EULA. The EULA states that you are obliged to purchase the specified access point count

Cisco Wireless Controller Configuration Guide, Release 8.3

Configuring Right to Use Licensing

licenses at the time of activation. You must activate these licenses for the purchased access points count and accept the EULA.

You can remove an adder license from one controller and transfer the license to another controller in the same product family. For example, an adder license such as LIC-CT7500-100A can be transferred

(partially or fully) from one Cisco Flex 7500 Series Controller to another Cisco Flex 7500 Series

Controller.

Note

Licenses embedded in the controller at the time of shipment is not transferrable.

• Evaluation licenses—These licenses are demo or trial mode licenses that are valid for 90 days. Fifteen days prior to the expiry of the 90-day period, you are notified about the requirement to buy the permanent license. These evaluation licenses are installed with the license image. You can activate the evaluation licenses anytime with a command. A EULA is prompted after you run the activation command on the controller CLI. The EULA states that you are obligated to pay for the specified license count within 90 days of usage. The countdown starts after you accept the EULA.

Whenever you add or delete an access point adder license on the controller, you are prompted with an RTU

EULA. You can either accept or decline the RTU EULA for each add or delete operation.

For high-availability (HA) controllers when you enable HA, the controllers synchronize with the enabled license count of the primary controller and support high availability for up to the license count enabled on the primary controller.

You can view the RTU licenses through the controller GUI or CLI. You can also view these licenses across multiple wireless controllers through Cisco Prime Infrastructure.

With Release 8.1, the license management for Cisco Virtual Wireless Controller is changed from license-file based management to Right-to-Use-based management. The previous licenses are still valid, and when you upgrade to Release 8.1 from an earlier release, you are required to only accept an end-user license agreement again to the quantity installed before.

Configuring Right to Use Licensing (GUI)

Step 1

Step 2

Step 3

Choose Management > Software Activation > Licenses to open the Licenses page.

In the Adder License area, choose to add or delete the number of APs that an AP license can support, enter a value, and click Set Count.

Click Save Configuration.

Configuring Right to Use Licensing (CLI)

• Add or delete the number of APs that an AP license can support by entering this command:

license {add | delete} ap-count count

• Add or delete a license for a feature by entering this command:

Cisco Wireless Controller Configuration Guide, Release 8.3

Rehosting Licenses

license {add | delete} feature license_name

• Activate or deactivate an evaluation AP count license by entering this command:

license {activate | deactivate} ap-count eval

Note

When you activate the license, you are prompted to accept or reject the End User License

Agreement (EULA) for the given license. If you activate a license that supports fewer number of APs than the current number of APs connected to the controller, the activation command fails.

• Activate or deactivate a feature license by entering this command:

license {activate | deactivate} feature license_name

• See the licensing information by entering this command:

show license all

Note

After you add or delete the license, WLC must use the save config command to save the license.

Rehosting Licenses

This section describes how to rehost licenses.

Information About Rehosting Licenses

Revoking a license from one controller and installing it on another is called rehosting. You might want to rehost a license in order to change the purpose of a controller. For example, if you want to move your

OfficeExtend or indoor mesh access points to a different controller, you could transfer the adder license from one controller to another controller of the same model (intramodel transfer). This can be done in the case of

RMA or a network rearchitecture that requires you to transfer licenses from one appliance to another. It is not possible to rehost base licenses in normal scenarios of network rearchitecture. The only exception where the transfer of base licenses is allowed is for RMA when you get a replacement hardware when your existing appliance has a failure.

Evaluation licenses cannot be rehosted.

In order to rehost a license, you must generate credential information from the controller and use it to obtain a permission ticket to revoke the license from the Cisco licensing site. Next, you must obtain a rehost ticket and use it to obtain a license installation file for the controller on which you want to install the license.

Note

A revoked license cannot be reinstalled on the same controller.

Cisco Wireless Controller Configuration Guide, Release 8.3

Rehosting Licenses

Note

Starting in the release 7.3, the Right-to-Use licensing is supported on the Cisco Flex 7500 Series Controllers, thereby the rehosting behavior changes on these controllers. If you require to rehost licenses, you need to plan rehosting the installed adder licenses prior to an upgrade.

Rehosting a License

Rehosting a License (GUI)

Step 1

Step 2

Step 3

Step 4

Step 5

Choose Management > Software Activation > Commands to open the License Commands page.

From the Action drop-down list, choose Rehost. The Revoke a License from the Device and Generate Rehost Ticket area appears.

In the File Name to Save Credentials text box, enter the path on the TFTP server where you want the device credentials to be saved and click Save Credentials.

To obtain a permission ticket to revoke the license, follow these steps: a) Click Cisco Licensing ( https://tools.cisco.com/SWIFT/Licensing/PrivateRegistrationServlet).

b) On the Product License Registration page, click Look Up a License under Manage Licenses.

c) Enter the product ID and serial number for your controller.

Note

To find the controller’s product ID and serial number, choose Controller > Inventory on the controller

GUI.

d) Open the device credential information file that you saved in

Step 3

and copy and paste the contents of the file into the Device Credentials text box.

e) Enter the security code in the blank box and click Continue.

f) Choose the licenses that you want to revoke from this controller and click Start License Transfer.

g) On the Rehost Quantities page, enter the number of licenses that you want to revoke in the To Rehost text box and click Continue.

h) On the Designate Licensee page, enter the product ID and serial number of the controller for which you plan to revoke the license, read and accept the conditions of the End User License Agreement (EULA), complete the rest of the text boxes on this page, and click Continue.

i) On the Review and Submit page, verify that all information is correct and click Submit.

j) When a message appears indicating that the registration is complete, click Download Permission Ticket. The rehost permission ticket is e-mailed within 1 hour to the address that you specified.

k) After the e-mail arrives, copy the rehost permission ticket to your TFTP server.

Use the rehost permission ticket to revoke the license from this controller and generate a rehost ticket as follows: a) In the Enter Saved Permission Ticket File Name text box, enter the TFTP path and filename (*.lic) for the rehost permission ticket that you generated in

Step 4 .

b) In the Rehost Ticket File Name text box, enter the TFTP path and filename (*.lic) for the ticket that will be used to rehost this license on another controller.

c) Click Generate Rehost Ticket.

Cisco Wireless Controller Configuration Guide, Release 8.3

Rehosting Licenses

Step 6

Step 7

d) When the End User License Agreement (EULA) acceptance dialog box appears, read the agreement and click Accept to accept the terms of the agreement.

Use the rehost ticket generated in

Step 5

to obtain a license installation file, which can then be installed on another controller as follows: a) Click Cisco Licensing.

b) On the Product License Registration page, click Upload Rehost Ticket under Manage Licenses.

c) On the Upload Ticket page, enter the rehost ticket that you generated in

Step 5

in the Enter Rehost Ticket text box and click Continue.

d) On the Validate Features page, verify that the license information for your controller is correct, enter the rehost quantity, and click Continue.

e) On the Designate Licensee page, enter the product ID and serial number of the controller on which you plan to use the license, read and accept the conditions of the End User License Agreement (EULA), complete the rest of the text boxes on this page, and click Continue.

f) On the Review and Submit page, verify that all information is correct and click Submit.

g) When a message appears indicating that the registration is complete, click Download License. The rehost license key is e-mailed within 1 hour to the address that you specified.

h) After the e-mail arrives, copy the rehost license key to your TFTP server.

i) Follow the instructions in the Installing a License section to install this on another controller.

After revoking the license on original controller, correspondent evaluation licence appear with High pritority. Lower the priority of the evaluation license so that the parmanent license is in "In Use" status.

Rehosting a License (CLI)

Step 1

Step 2

Save device credential information to a file by entering this command:

license save credential url where url is tftp://server_ip/path/filename.

Obtain a permission ticket to revoke the license as follows: a) Go to https://tools.cisco.com/SWIFT/Licensing/PrivateRegistrationServlet . The Product License Registration page appears.

b) Under Manage Licenses, click Look Up a License.

c) Enter the product ID and serial number for your controller.

Note

To find the controller’s product ID and serial number, enter the show license udi command on the controller

CLI.

d) Open the device credential information file that you saved in

Step 1

and copy and paste the contents of the file into the Device Credentials text box.

e) Enter the security code in the blank box and click Continue.

f) Choose the licenses that you want to revoke from this controller and click Start License Transfer.

g) On the Rehost Quantities page, enter the number of licenses that you want to revoke in the To Rehost text box and click Continue.

Cisco Wireless Controller Configuration Guide, Release 8.3

Rehosting Licenses

Step 3

Step 4

Step 5

h) On the Designate Licensee page, enter the product ID and serial number of the controller for which you plan to revoke the license, read and accept the conditions of the End-User License Agreement (EULA), complete the rest of the text boxes on this page, and click Continue.

i) On the Review and Submit page, verify that all information is correct and click Submit.

j) When a message appears indicating that the registration is complete, click Download Permission Ticket. The rehost permission ticket is e-mailed within 1 hour to the address that you specified.

k) After the e-mail arrives, copy the rehost permission ticket to your TFTP server.

Use the rehost permission ticket to revoke the license from this controller and generate a rehost ticket as follows: a) Revoke the license from the controller by entering this command:

license revoke permission_ticket_url where permission_ticket_url is tftp://server_ip/path/filename.

b) Generate the rehost ticket by entering this command:

license revoke rehost rehost_ticket_url where rehost_ticket_url is tftp://server_ip/path/filename.

c) If prompted, read and accept the terms of the End-User License Agreement (EULA).

Use the rehost ticket generated in

Step 3

to obtain a license installation file, which can then be installed on another controller as follows: a) Go to https://tools.cisco.com/SWIFT/Licensing/PrivateRegistrationServlet.

b) On the Product License Registration page, click Upload Rehost Ticket under Manage Licenses.

c) On the Upload Ticket page, enter the rehost ticket that you generated in

Step 3

in the Enter Rehost Ticket text box and click Continue.

d) On the Validate Features page, verify that the license information for your controller is correct, enter the rehost quantity, and click Continue.

e) On the Designate Licensee page, enter the product ID and serial number of the controller on which you plan to use the license, read and accept the conditions of the End-User License Agreement (EULA), complete the rest of the text boxes on this page, and click Continue.

f) On the Review and Submit page, verify that all information is correct and click Submit.

g) When a message appears indicating that the registration is complete, click Download License. The rehost license key is e-mailed within 1 hour to the address that you specified.

h) After the e-mail arrives, copy the rehost license key to your TFTP server.

i) Follow the instructions in the

Installing a License (GUI), on page 54

section to install this license on another controller.

Transferring Licenses to a Replacement Controller after an RMA

Information About Transferring Licenses to a Replacement Controller after an RMA

If you return a Cisco 5500 Series Controller to Cisco as part of the Return Material Authorization (RMA) process, you must transfer that controller’s licenses within 60 days to a replacement controller that you receive from Cisco.

Cisco Wireless Controller Configuration Guide, Release 8.3

Cisco Smart Software Licensing

Replacement controllers come preinstalled with the following licenses: permanent base and evaluation base, base-ap-count. No other permanent licenses are installed. The SKU for replacement controllers is

AIR-CT5508-CA-K9.

Because licenses are registered to the serial number of a controller, you can use the licensing portal on

Cisco.com to request that the license from your returned controller be revoked and authorized for use on the replacement controller. After your request is approved, you can install the old license on the replacement controller. Any additional ap-count licenses if installed in the returned controller has to be rehosted on the replacement controller. Before you begin, you need the product ID and serial number of both the returned controller and the replacement controller. This information is included in your purchase records.

Note

The evaluation licenses on the replacement controller are designed for temporary use and expire after 60 days. 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. If the evaluation licenses expire before you transfer the permanent licenses from your defective controller to your replacement controller, the replacement controller remains up and running using the permanent base license, but access points are no longer able to join the controller.

Transferring a License to a Replacement Controller after an RMA

Step 1

Step 2

Step 3

Step 4

Step 5

Step 6

Step 7

Browse to https://tools.cisco.com/SWIFT/LicensingUI/Quickstart .

Log on to the site.

In the Manage tab, click Devices.

Choose Actions > Rehost/Transfer.

Follow the on-screen instructions to generate the license file.

The license is provided online or in an e-mail.

Copy the license file to the TFTP server.

Install the license by choosing Management > Software Activation > Commands > Action > Install License.

Cisco Smart Software Licensing

Information About Smart Licensing

Cisco started the initiative of simplifying customer license management by building a Cisco Smart Software

Manager portal. It helps the customers understand what licenses they have purchased and what licenses they are using. Various other Cisco products are already Smart Enabled and with the introduction of this release,

Smart Licensing will now be available on the following platforms:

• Cisco 5520 WLC (AIR-CT5520-K9)

• Cisco 8540 WLC (AIR-CT8540-K9)

Cisco Wireless Controller Configuration Guide, Release 8.3

Cisco Smart Software Licensing

• Cisco vWLC (L-AIR-CTVM-5-K9)

You need to register for your own Smart Account, which is a one time activity. Using the Smart Account you can activate, monitor usage and track the purchased licenses. To know more about creating the Cisco Smart

Account see Smart Account Quick Reference Guide .

Note

For information about migrating from RTU Licensing mechanism to Smart Licensing mechanism, consult

Cisco Technical Assistance Center.

Restrictions for Using Cisco Smart Software Licensing

• Token-id generated for Cisco 5520 or 8450 WLC cannot be used with Cisco vWLC.

• Call-Home supports only HTTP and HTTPS mode of communication.

• Call-Home does not support email mode of communication.

• After the switch over to Smart Licensing mechanism some of the parameter reports, for example: runtime statistics will not be cumulative reports.

• You can create up to two profiles, allowing you to separately configure Smart Licensing messages and

Call-Home events.

• There might be a difference in the time stamps when the WLC is in a different time zone, as the WLC is set to local time zone time, whereas the Smart License server is set to UTC time.

• In a Smart License active HA pair, when the primary WLC stops functioning, and the standby WLC takes over as the new primary, and initiates a reboot. After reboot, the device losses its registration information. This can be resolved by manually registering the device with the Cisco Smart License

Manager or rebooting and re-pairing the primary and stand-by devices.

• On a Smart License active HA pair, any attempt to de-register before the switch over to active secondary from active primary is complete, and the renew message is sent, the de-registration process may fail.

• In a Smart License active HA pair, the stand-by device displays evaluation authorization state, this parameter gets updated to display the correct values after the switch over is complete and the WLC is the active controller.

• To free the license on the server in a situation, where the license mechanism is changed to Right To Use

(RTU) from Smart Licensing, it is mandatary to manually de-register the device.

Configuring Cisco Smart Software Licensing (GUI)

Step 1

To activate Smart Licensing mechanism, follow the steps: a) Choose Management > Software Activation > License Type to open the Smart-License page.

b) From the Licensing Type drop-down list, choose Smart-Licensing option.

c) Enter the DNS Server IP address in the DNS Server IP address field.

d) Click Apply

Cisco Wireless Controller Configuration Guide, Release 8.3

Cisco Smart Software Licensing

Step 2

Step 3

Step 4

e) Reboot the controller.

To register a device, follow the steps: a) Choose Management > Smart-license > Device registration to open the device registration page.

b) From the Action drop-down list choose Registration to register a new device.

c) Enter the device Token-id in the Smart License registration in the field field.

d) Click Apply

To de-register a device, follow the steps: a) Choose Management > Smart-license > Device registration to open the device registration page.

b) From the Action drop-down list choose De-registration to remove a registered device.

c) Click Apply

To view the current Smart Licensing parameters, follow the steps: a) Choose Management > Smart-license > Status to open the Status page.

b) To view the Smart-Licensing Parameters , choose from the following options in the drop-down list:

• Status

• Summary

• all

• Udi

• Usage

• Tech-suport

Configuring the Cisco Smart Software Licensing on WLC (CLI)

Step 1

Step 2

Step 3

Step 4

Enable Cisco Smart Software Licensing by entering the following command:

config licensing {rtu | smart-license} dns-server ip-address

Note

Device reboot is required to activate the chosen license mechanism.

To register or deregister a device and to retain the state of device registration after device reboots enter the following command:

license smart {register | deregister} idtoken

View the license status by entering the following command:

show license {status | summary | udi | all}

Clear the Cisco Smart Software Licensing statistics by entering the following command:

clear stats smart-lic

Cisco Wireless Controller Configuration Guide, Release 8.3

Call-Home

Call-Home

Information About Call-Home

You can create reporting profiles of your choice for the Smart Licensing messages and Call-Home events.

Call-Home reports Smart Licensing messages based on the active profile. At any time only one profile can be active. The messages use XML format, hence, ensure XML message format is chosen for all profiles created

Configuring Call-Home (GUI)

Step 1

Step 2

Step 3

Step 4

Step 5

Step 6

Step 7

To enable or disable the Call-Home reporting function, follow the steps: a) Choose Management > Smart-License > Call-home > configuration to open the Call-Home > Configuration page.

b) From the Events drop-down list choose from the following options in the drop-down list:

• Enabled–enables Call-Home reporting

• Disabled–disables Call-Home reporting c) Click Apply

To set the Data privacy level, follow the steps: a) From the Reporting Data-privacy-level drop-down list choose from the following options in the drop-down list:

• normal–scrubs normal level commands

• high–scrubs all normal level commands, IP domain name and IP address commands b) Click Apply

Enter the hostname in the Reporting Hostname text box.

To configure the http-proxy settings, following the steps: a) In the HTTP-proxy field, enter the IP-Address and port number b) Click Apply

To enable or disable the TAC Profile Status, follow the steps: a) From the TAC Profile Status drop-down list, choose from the following options in the drop-down list:

• Enabled–enables the TAC profile

• Disabled–disables the TAC profile b) Click Apply

Enter the email address in the Contact person's email address text box.

To create a new profile, follow the steps: a) Enter the name for the new profile in the Name text box.

b) From the Status drop-down list choose from the following options in the drop-down list:

Cisco Wireless Controller Configuration Guide, Release 8.3

Call-Home

Step 8

Step 9

•

Enabled–activates the profile

• Disabled–deactivates the profile c) From the Module drop-down list, choose from the following options in the drop-down list:

• sm-license-data–smart license data

• all–combines smart license and call-home data

• call-home-data–call-home data d) From the Reporting Format drop-down list, choose from the following options in the drop-down list:

• short-text–data reporting in short-text format

• long-text–data reporting in long-text format

• xml–call-data reporting in xml format

Note

The messages use XML format, hence, ensure XML message format is chosen for all profiles created.

e) The current default is xml format.

f) Enter the url in the url text box.

g) Click Add

To update an existing profile, follow the steps: a) Place the mouse cursor over the blue down arrow icon in front of the Profile to edit.

b) Choose update from the drop-down list which appears.

c) Update the fields as required from the options available:

• Status

• Module

• Url d) Click Apply

To delete a profile, follow the steps: a) Place the mouse cursor over the blue down arrow icon in front of the Profile to edit.

b) Choose delete from the drop-down list which appears.

Configuring Call-Home Parameters (CLI)

Configure Call-Home parameters by entering the following commands:

Step 1

Enable or disable Call-Home reporting by entering the following command:

config call-home events {enable | disable}

Cisco Wireless Controller Configuration Guide, Release 8.3

Retrieving the Unique Device Identifier on WLCs and APs

Step 6

Step 7

Step 8

Step 9

Step 2

Step 3

Step 4

Step 5

Step 10

The default value is enable.

Create a new profile or update an existing profile by entering the following command:

config call-home profile {create | update} profile-name {sm-license-data | all | call-home-data} XML url

Note

Currently, only XML format is supported. Hence, when call-home-data profile option is selected, choose XML format from the drop-down menu.

Delete an existing profile by entering the following command:

config call-home profile delete profile-name

Configure the proxy settings by adding the IP address and port number by entering the following command:

config call-home http-proxy ipaddr ip-address port port

Reset the proxy settings by entering the following command:

config call-home http-proxy ipaddr 0.0.0.0

Enable user data privacy by entering the following command:

config call-home reporting data-privacy-level {normal | high} hostname host-name

Enable or disable the user profile by entering the following command:

config call-home profile status {enable | disable}

Configure the contact email address by entering the following command:

config call-home contact-email-addr e-mail address

Enable or disable the status of the TAC profile by entering the following command:

config call-home tac-profile status {enable | disable}

The default value is enable.

View the Call-Home settings by entering the following command:

config call-home summary

Retrieving the Unique Device Identifier on WLCs and APs

Information About Retrieving the Unique Device Identifier on Controllers and Access Points

The Unique Device Identifier (UDI) standard uniquely identifies products across all Cisco hardware product families, enabling customers to identify and track Cisco products throughout their business and network operations and to automate their asset management systems. The standard is consistent across all electronic, physical, and standard business communications. The UDI consists of five data elements:

• The orderable product identifier (PID)

• The version of the product identifier (VID)

• The serial number (SN)

• The entity name

• The product description

The UDI is burned into the EEPROM of controllers and lightweight access points at the factory. It can be retrieved through either the GUI or the CLI.

Cisco Wireless Controller Configuration Guide, Release 8.3

Retrieving the Unique Device Identifier on WLCs and APs

Retrieving the Unique Device Identifier on Controllers and Access Points (GUI)

Step 1

Step 2

Step 3

Step 4

Choose Controller > Inventory to open the Inventory page.

This page shows the five data elements of the controller UDI.

Choose Wireless > Access Points > All APs to open the All APs page.

Click the name of the desired access point.

Choose the Inventory tab to open the All APs > Details for (Inventory) page.

This page shows the inventory information for the access point.

Retrieving the Unique Device Identifier on Controllers and Access Points (CLI)

Use these commands to retrieve the UDI on controllers and access points using the controller CLI:

• show inventory—Shows the UDI string of the controller. Information similar to the following appears:

...

NAME: "Chassis" , DESCR: "Cisco 5500 Series Wireless LAN Controller"

PID: AIR-CT5508-K9, VID: V01, SN: XXXXXXXXXXX

• show inventory ap ap_id—Shows the UDI string of the access point specified.

Cisco Wireless Controller Configuration Guide, Release 8.3

C H A P T E R

Managing Software

•

Upgrading the Controller Software, page 75

Upgrading the Controller Software

When you upgrade the controller software, the software on the access points associated with the controller is also automatically upgraded. When an access point is loading software, each of its LEDs blinks in succession.

Caution

Do not power down the controller or any access point during this process; otherwise, you might corrupt the software image. Upgrading a controller with a large number of access points can take as long as 30 minutes, depending on the size of your network. However, with the increased number of concurrent access point upgrades supported in the controller software release, the upgrade time should be significantly reduced. The access points must remain powered, and the controller must not be reset during this time.

Restrictions for Upgrading Controller Software

• Before upgrading or downgrading the controller image, you must close all open web pages and clear the browser cache.

• If you require a downgrade from one release to another, you might lose the configuration from your current release. The workaround is to reload the previous controller configuration files saved on the backup server or to reconfigure the controller.

• It is not possible to directly upgrade to this release from a release that is older than 6.0.182.0.

• You can upgrade or downgrade the controller software only between certain releases. In some instances, you must first install an intermediate release prior to upgrading to the latest software release.

• When you upgrade the controller to an intermediate software release, you must wait until all of the access points that are associated with the controller are upgraded to the intermediate release before you install the latest controller software. In large networks, it can take some time to download the software on each access point.

Cisco Wireless Controller Configuration Guide, Release 8.3

Upgrading the Controller Software

• When you upgrade to the latest software release, the software on the access points associated with the controller is also automatically upgraded. When an access point is loading software, each of its LEDs blinks in succession.

• We recommend that you access the Cisco WLC GUI using Microsoft Internet Explorer 11 or a later version, or Mozilla Firefox 32 or a later version.

• Cisco controllers support standard SNMP Management Information Base (MIB) files. MIBs can be downloaded from the Software Center on Cisco.com.

• The controller software is factory installed on your controller and automatically downloaded to the access points after a release upgrade and whenever an access point joins a controller. We recommend that you install the latest software version available for maximum operational benefit.

• We recommend that you install Wireless LAN Controller Field Upgrade Software for Release 1.7.0.0-FUS, which is a special AES package that contains several system-related component upgrades. These include the bootloader, field recovery image, and FPGA/MCU firmware. Installing the FUS image requires special attention because it installs some critical firmware. The FUS image is independent of the runtime image. For more information, see http://www.cisco.com/c/en/us/td/docs/wireless/controller/release/notes/fus_rn_1_7_0_0.html

• Ensure that you have a TFTP or FTP server available for the software upgrade. Follow these guidelines when setting up a TFTP or FTP server:

◦Ensure that your TFTP server supports files that are larger than the size of the controller software release. Some TFTP servers that support files of this size are tftpd32 and the TFTP server within the Cisco Prime Infrastructure. If you attempt to download the controller software and your TFTP server does not support files of this size, the following error message appears: “TFTP failure while storing in flash.”

◦If you are upgrading through the distribution system network port, the TFTP or FTP server can be on the same or a different subnet because the distribution system port is routable

• When you plug a controller into an AC power source, the bootup script and power-on self-test run to initialize the system. During this time, you can press Esc to display the bootloader Boot Options Menu.

The menu options for the 5500 and Flex 7500 series controllers are different than for other controller platforms.

Bootloader menu for 5500 Series Controllers:

Boot Options

Please choose an option from below:

1. Run primary image

2. Run backup image

3. Change active boot image

4. Clear Configuration

5. Format FLASH Drive

6. Manually update images

Please enter your choice:

Bootloader menu for other controller platforms:

Boot Options

Please choose an option from below:

1. Run primary image

2. Run backup image

3. Manually update images

4. Change active boot image

5. Clear Configuration

Please enter your choice:

Cisco Wireless Controller Configuration Guide, Release 8.3

Upgrading the Controller Software

Enter 1 to run the current software, enter 2 to run the previous software, enter 4 (on a 5500 series controller), or enter 5 (on another controller platform) to run the current software and set the controller configuration to factory defaults. Do not choose the other options unless directed to do so.

Note

See the Installation Guide or the Quick Start Guide for your controller for more details on running the bootup script and power-on self-test.

• Control which address(es) are sent in CAPWAP discovery responses when NAT is enabled on the

Management Interface using the following command:

config network ap-discovery nat-ip-only {enable | disable} where

◦enable—Enables use of NAT IP only in Discovery response. This is the default. Use this command if all APs are outside of the NAT gateway.

◦disable—Enables use of both NAT IP and non-NAT IP in discovery response. Use this command if APs are on the inside and outside of the NAT gateway; for example, Local Mode and OfficeExtend

APs on the same controller.

Note

To avoid stranding APs, you must disable AP link-latency (if enabled) before you use the disable option for the config network ap-discovery nat-ip-only command. To disable AP link-latency, use the config ap link-latency disable all command.

• You can configure 802.1p tagging by using the config qos dot1p-tag {bronze | silver | gold | platinum} tag. For the 7.2.103.0 and later releases, if you tag 802.1p packets, the tagging has impact only on wired packets. Wireless packets are impacted only by the maximum priority level set for QoS.

• You can reduce the network downtime using the following options:

◦You can predownload the AP image.

◦For FlexConnect access points, use the FlexConnect Efficient AP upgrade feature to reduce traffic between the controller and the AP (main site and the branch).

• Do not power down the controller or any access point during the upgrade process; otherwise, you might corrupt the software image. Upgrading a controller with a large number of access points can take as long as 30 minutes, depending on the size of your network. However, with the increased number of concurrent access point upgrades supported, the upgrade time should be significantly reduced. The access points must remain powered, and the controller must not be reset during this time.

• If you want to downgrade to a previous release, do either of the following:

◦Delete all WLANs that are mapped to interface groups and create new ones.

◦Ensure that all WLANs are mapped to interfaces rather than interface groups.

• After you perform these functions on the controller, you must reboot the controller for the changes to take effect:

Cisco Wireless Controller Configuration Guide, Release 8.3

Upgrading the Controller Software

◦Enable or disable link aggregation (LAG)

◦Enable a feature that is dependent on certificates (such as HTTPS and web authentication)

◦Add new or modify existing SNMP v3 users

◦Modify an existing SNMP v3 engine ID

◦Add a new license or modify an existing license

◦Increase the priority for a license

• The controller bootloader stores a copy of the active primary image and the backup image. If the primary image becomes corrupted, you can use the bootloader to boot with the backup image.

With the backup image stored before rebooting, be sure to choose Option 2: Run Backup Image from the boot menu to boot from the backup image. Then, upgrade with a known working image and reboot the controller.

• The recovery image provides a backup image that can be used if an access point power-cycles during an image upgrade. The best way to avoid the need for access point recovery is to prevent an access point from power-cycling during a system upgrade. If a power-cycle occurs during an upgrade to an oversized access point image, you can recover the access point using the TFTP recovery procedure.

To recover the access point using the TFTP recovery procedure, follow these steps:

Download the required recovery image from Cisco.com (c1100-rcvk9w8-mx, c1200-rcvk9w8-mx, or c1310-rcvk9w8-mx) and install it in the root directory of your TFTP server.

Connect the TFTP server to the same subnet as the target access point and power-cycle the access point. The access point boots from the TFTP image and then joins the controller to download the oversized access point image and complete the upgrade procedure.

After the access point has been recovered, you can remove the TFTP server.

• You can upgrade to a new release of the controller software or downgrade to an older release even if

Federal Information Processing Standard (FIPS) is enabled.

• If you upgrade from a release that is prior to Release 7.5 directly to Release 7.6.X or a later release, the predownload process on Cisco AP2600 and AP3600 fails. After the Cisco WLC is upgraded to Release

7.6.X or a later release, the new image is loaded on Cisco AP2600 and AP3600. After the upgrade to a

Release 7.6.X image, the predownload functionality works as expected. The predownload failure is only a one-time failure.

• Applicable to Release 8.3 or a later release: Ensure that the configuration file that you back up does not contain < or > special character. If either of the special characters is present, then the download of the backed up configuration file fails.

Upgrading Controller Software (GUI)

Step 1

Upload your controller configuration files to a server to back them up.

Note

We highly recommend that you back up your configuration files of the controller prior to upgrading the controller software. Otherwise, you must manually reconfigure the controller.

Cisco Wireless Controller Configuration Guide, Release 8.3

Upgrading the Controller Software

Step 2

Step 3

Step 4

Step 5

Step 6

Step 7

Step 8

Step 9

Get the controller software image by following these steps: a) Browse to http://www.cisco.com/cisco/software/navigator.html

b) Choose Wireless > Wireless LAN Controller.

The following options are available: Integrated Controllers and Controller Modules, Mobility Express, and

Standalone Controllers.

c) Depending on your controller platform, click one of the above options.

d) Click the controller model number or name. The Download Software page is displayed.

e) Click a controller software release. The software releases are labeled as follows to help you determine which release to download:

Early Deployment (ED)—These software releases provide new features, new hardware platform support, and bug fixes.

Maintenance Deployment (MD)—These software releases provide bug fixes and ongoing software maintenance.

Deferred (DF)—These software releases have been deferred. We recommend that you migrate to an upgraded release.

f) Choose a software release number.

g) Click the filename (filename.aes).

h) Click Download.

i) Read Cisco’s End User Software License Agreement and then click Agree.

j) Save the file to your hard drive.

k) Repeat steps a through k to download the remaining file.

Copy the controller software image (filename.aes) to the default directory on your TFTP or FTP server.

Note

In Release 8.3, for Cisco 2504 WLC, 5508 WLC, and WiSM2, the Cisco WLC software image is split into two images: Base Install Image and Supplementary AP Bundle Image. Therefore, to upgrade to Release 8.3, you must repeat Step 2 through Step 14 to complete the installation of both Base Install Image and Supplementary

AP Bundle Image.

Download the Supplementary AP Bundle Image only if you are using any of these APs: AP801, AP802, Cisco

Aironet 1550 Series AP (with 64-MB memory), Cisco Aironet 1550 Series AP (with 128-MB memory), and/or

Cisco Aironet 1570 Series APs.

(Optional) Disable the 802.11 networks.

Note

For busy networks, controllers on high utilization, or small controller platforms, we recommend that you disable the 802.11 networks as a precautionary measure.

Disable any WLANs on the controller.

Choose Commands > Download File to open the Download File to Controller page.

From the File Type drop-down list, choose Code.

From the Transfer Mode drop-down list, choose from the following options:

• TFTP

• FTP

• SFTP (available in 7.4 and later releases)

• HTTP (available in 8.1 and later releases)

In the IP Address text box, enter the IP address of the server.

If you are using a TFTP server, the default values of 10 retries and 6 seconds for the Maximum Retries and Timeout text boxes should work correctly without any adjustment. However, you can change these values.

Cisco Wireless Controller Configuration Guide, Release 8.3

Upgrading the Controller Software

Step 10

Step 11

Step 12

Step 13

Step 14

Step 15

Step 16

Step 17

Step 18

Step 19

Step 20

Step 21

Step 22

If you are using a TFTP server, the default values of 10 retries for the Maximum Retries text field, and 6 seconds for the

Timeout text field should work correctly without any adjustment. However, you can change these values if desired. To do so, enter the maximum number of times that the TFTP server attempts to download the software in the Maximum

Retries text box and the amount of time (in seconds) that the TFTP server attempts to download the software in the

Timeout text box.

In the File Path text box, enter the directory path of the software.

In the File Name text box, enter the name of the controller software file (filename.aes).

If you are using an FTP server, follow these steps: a) In the Server Login Username text box, enter the username to log into the FTP server.

b) In the Server Login Password text box, enter the password to log into the FTP server.

c) In the Server Port Number text box, enter the port number on the FTP server through which the download occurs.

The default value is 21.

Click Download to download the software to the controller. A message appears indicating the status of the download.

Note

In Release 8.3, for Cisco 2504 WLC, 5508 WLC, and WiSM2, the Cisco WLC software image is split into two images: Base Install Image and Supplementary AP Bundle Image. Therefore, to upgrade to Release 8.3.100.0, you must repeat Step 2 through Step 14 to complete the installation of both Base Install Image and Supplementary

AP Bundle Image.

Download the Supplementary AP Bundle Image only if you are using any of these APs: AP801, AP802, Cisco

Aironet 1550 Series AP (with 64-MB memory), Cisco Aironet 1550 Series AP (with 128-MB memory), and/or

Cisco Aironet 1570 Series APs.

After the download is complete, click Reboot.

If prompted to save your changes, click Save and Reboot.

Click OK to confirm.

After the controller reboots, repeat step 6 to step 17 to install the remaining file.

Reenable the WLANs.

For Cisco WiSM2, reenable the controller port channel on the Catalyst switch.

If you have disabled the 802.11 networks in Step 4, reenable them.

To verify the controller software version, choose Monitor on the controller GUI and see Software Version in the

Controller Summary area.

Upgrading Controller Software (CLI)

Step 1

Step 2

Upload your controller configuration files to a server to back them up.

Note

We highly recommend that you back up your controller's configuration files prior to upgrading the controller software. Otherwise, you must manually reconfigure the controller.

Get the controller software image by following these steps: a) Browse to http://www.cisco.com/cisco/software/navigator.html

b) Choose Wireless > Wireless LAN Controller.

The following options are available: Integrated Controllers and Controller Modules, Mobility Express, and

Standalone Controllers.

Cisco Wireless Controller Configuration Guide, Release 8.3

Upgrading the Controller Software

Step 3

Step 4

Step 5

Step 6

Step 7

Step 8

Step 9

c) Depending on your controller platform, click one of the above options.

d) Click the controller model number or name. The Download Software page is displayed.

e) Click a controller software release. The software releases are labeled as follows to help you determine which release to download:

Early Deployment (ED)—These software releases provide new features, new hardware platform support, and bug fixes.

Maintenance Deployment (MD)—These software releases provide bug fixes and ongoing software maintenance.

Deferred (DF)—These software releases have been deferred. We recommend that you migrate to an upgraded release.

f) Choose a software release number.

g) Click the filename (filename.aes).

h) Click Download.

i) Read Cisco’s End User Software License Agreement and then click Agree.

j) Save the file to your hard drive.

k) Repeat steps a through k to download the remaining file.

Copy the controller software image (filename.aes) to the default directory on your TFTP or FTP server.

Note

In Release 8.3, for Cisco 2504 WLC, 5508 WLC, and WiSM2, the Cisco WLC software image is split into two images: Base Install Image and Supplementary AP Bundle Image. Therefore, to upgrade to Release 8.3, you must repeat Step 2 through Step 10 to complete the installation of both Base Install Image and Supplementary

AP Bundle Image.

Download the Supplementary AP Bundle Image only if you are using any of these APs: AP801, AP802, Cisco

Aironet 1550 Series AP (with 64-MB memory), Cisco Aironet 1550 Series AP (with 128-MB memory), and/or

Cisco Aironet 1570 Series APs.

(Optional) Disable the 802.11 networks.

Note

For busy networks, controllers on high utilization, or small controller platforms, we recommend that you disable the 802.11 networks as a precautionary measure.

Disable any WLANs on the controller (using the config wlan disable wlan_id command).

Log onto the controller CLI.

Enter the ping server-ip-address command to verify that the controller can contact the TFTP or FTP server.

View current download settings by entering the transfer download start command. Answer n to the prompt to view the current download settings.

Change the download settings, if necessary by entering these commands:

• transfer download mode {tftp | ftp | sftp}

• transfer download datatype code

• transfer download serverip server-ip-address

• transfer download filename filename

• transfer download path server-path-to-file

Note

Pathnames on a TFTP or FTP server are relative to the server’s default or root directory. For example, in the case of the Solaris TFTP server, the path is “/”.

If you are using a TFTP server, also enter these commands:

• transfer download tftpMaxRetries retries

• transfer download tftpPktTimeout timeout

Cisco Wireless Controller Configuration Guide, Release 8.3

Upgrading the Controller Software

Step 10

Step 11

Step 12

Step 13

Step 14

Step 15

Step 16

Step 17

Note

The default values of 10 retries and a 6-second timeout should work correctly without any adjustment.

However, you can change these values. To do so, enter the maximum number of times that the TFTP server attempts to download the software for the retries parameter and the amount of time (in seconds) that the TFTP server attempts to download the software for the timeout parameter.

If you are using an FTP server, also enter these commands:

• transfer download username username

• transfer download password password

• transfer download port port

Note

The default value for the port parameter is

21.

View the current updated settings by entering the transfer download start command. Answer y to the prompt to confirm the current download settings and start the software download.

Save the code update to nonvolatile NVRAM and reboot the controller by entering this command:

reset system

The controller completes the bootup process.

After the controller reboots, repeat Steps 6 through 11 to install the remaining file.

Reenable the WLANs by entering this command:

config wlan enable wlan_id

For Cisco WiSMs, re-enable the controller port channel on the Catalyst switch.

If you have disabled the 802.11 networks in Step 4, renable them.

To verify the controller software that is installed, enter the show sysinfo command and see Product Version.

To verify the Cisco Unified Wireless Network Controller Boot Software file that is installed on the controller, enter the

show sysinfo command on the controller CLI and see Recovery Image Version or Emergency Image Version.

Note

If a Cisco Unified Wireless Network Controller Boot Software ER.aes file is not installed, Recovery Image

Version or Emergency Image Version show 'N/A.'

Predownloading an Image to an Access Point

To minimize network outages, you can download an upgrade image to the access point from the Cisco WLC without resetting the access point or losing network connectivity. Previously, you would download an upgrade image to the controller and reset it, which causes the access point to go into discovery mode. After the access point discovers the Cisco WLC with the new image, the access point downloads the new image, resets, goes into discovery mode, and rejoins the Cisco WLC.

You can now download the upgrade image to the Cisco WLC and then download the image to the access point while the network is still operational. You can also schedule a reboot of the Cisco WLC and access points, either after a specified amount of time or at a specific date and time. When both devices are up, the access point discovers and rejoins the Cisco WLC.

Concurrent Cisco WLC to AP Image Upgrade

This table lists the Cisco WLCs and their maximum concurrent AP image download support.

Cisco Wireless Controller Configuration Guide, Release 8.3

Upgrading the Controller Software

Cisco WLC

Cisco 2504 WLC

Cisco 5508 WLC

Cisco 5520 WLC

Cisco Flex 7510 WLC

Cisco 8510 WLC

Cisco 8540 WLC

Cisco WiSM2

Cisco vWLC

Maximum Number of Concurrent AP Image Download

Supported

500

1000

500

1000

Flash Memory Requirements on Access Points

This table lists the Cisco AP models and the minimum amount of free flash memory required for the predownload process to work:

Cisco AP Minimum Free Flash Memory Required

3502(I/E) 14 MB

2602(I/E)

1602(I/E)

14 MB

12 MB

1262

1142

14 MB

12 MB

Note

• The required flash memory can vary based on the radio type and the number of antennas used.

• This predownload feature is not supported on 1242 and 1131 Cisco AP models.

• Cisco AP1142 has 32 MB of total flash memory and can support the predownload feature.

Access Point Predownload Process

The access point predownload feature works as follows:

• The controller image is downloaded.

Cisco Wireless Controller Configuration Guide, Release 8.3

Upgrading the Controller Software

◦The primary image becomes the backup image of the controller and the downloaded image becomes the new primary image. Change the current boot image as the backup image by using the config

boot backup command to ensure that if a system failure occurs, the controller boots with the last working image of the controller.

◦To switch over to the new downloaded image, start predownload of the upgraded image using the

config ap image predownload primary all command.

◦The upgrade image is downloaded as the backup image on the access points. You can verify this by using the show ap image all command.

◦Change the boot image to primary image manually using the config boot primary command and reboot the controller for the upgrade image to be activated.

◦You issue a scheduled reboot with the swap keyword. The swap keyword has the following importance: The swapping occurs to the primary and backup images on the access point and the currently active image on controller with the backup image.

◦When the controller reboots, the access points are disassociated and eventually come up with an upgraded image. Once the controller responds to the discovery request sent by an access point with its discovery response packet, the access point sends a join request.

• The actual upgrade of the images occur. The following sequence of actions occur:

◦During boot time, the access point sends a join request.

◦The controller responds with the join response with the image version that the controller is running.

◦The access point compares its running image with the running image on the controller. If the versions match, the access point joins the controller.

◦If the versions do not match, the access point compares the version of the backup image and if they match, the access point swaps the primary and backup images and reloads and subsequently joins the controller.

◦If the primary image of the access point is the same as the controller image, the access point reloads and joins the controller.

◦If none of the above conditions are true, the access point sends an image data request to the controller, downloads the latest image, reloads, and joins the controller.

Restrictions for Predownloading an Image to an Access Point

• The 2600, 3500, and 3600 AP models can store only a single image in the flash. When you reboot the

AP (without rebooting the controller after a pre-download), it will download the current image from the controller as the current image will be overwritten by the pre-downloaded image in the flash.

• The maximum number of concurrent predownloads is limited to half the number of concurrent normal image downloads. This limitation allows new access points to join the controller during image downloading.

If you reach the predownload limit, then the access points that cannot get an image sleep for a time between 180 to 600 seconds and then reattempt the predownload.

Cisco Wireless Controller Configuration Guide, Release 8.3

Upgrading the Controller Software

• Before you predownload, you should change the active controller boot image to the backup image to ensure that if the controller reboots for some reason, it comes back up with the earlier running image, not the partially downloaded upgrade image.

• This predownload feature is not supported on 1242 and 1131 Cisco AP models.

• When the system time is changed by using the config time command, the time set for a scheduled reset is not valid and the scheduled system reset is canceled. You are given an option either to cancel the scheduled reset before configuring the time or retain the scheduled reset and not configure the time.

• All the primary, secondary, and tertiary controllers should run the same images as the primary and backup images. That is, the primary image of all three controllers should be X and the secondary image of all three controllers should be Y or the feature is not effective.

• At the time of the reset, if any AP is downloading the controller image, the scheduled reset is canceled.

The following message appears with the reason why the scheduled reset was canceled:

%OSAPI-3-RESETSYSTEM_FAILED: osapi_task.c:4458 System will not reset as software is being upgraded.

• Predownloading a 7.2 or later version of image on a Cisco Aironet 1240 access point is not supported when upgrading from a previous controller release. If predownloading is attempted to the Cisco Aironet

1240 access point, the AP gets disconnected.

• There are two images for the1550 Mesh AP - 1550 with 64 MB memory and 1550 with 128 MB memory.

During the controller upgrade to 7.6 and higher versions, the AP images are downloaded and there are two reboots.

7.6.X or a later release, the new image is loaded on Cisco AP2600 and AP3600. After the upgrade to a

Release 7.6.X image, the predownload functionality works as expected. The predownload failure is only a one-time failure.

Predownloading an Image to Access Points—Global Configuration (GUI)

Step 1

Step 2

Upload your controller configuration files to a server to back them up.

Note

We highly recommend that you back up your controller's configuration files prior to upgrading the controller software. Otherwise, you must manually reconfigure the controller.

Follow these steps to obtain the controller software: a) Browse to the Cisco Software Center: http://www.cisco.com/cisco/software/navigator.html

b) Choose Wireless from the center selection window.

c) Click Wireless LAN Controllers.

The following options are available: Integrated Controllers and Controller Modules and Standalone Controllers.

d) Depending on your controller platform, click one of the above options.

e) Click the controller model number or name. The Download Software page is displayed.

f) Click a controller software release. The software releases are labeled as follows to help you determine which release to download:

Early Deployment (ED)—These software releases provide new features, new hardware platform support, and bug fixes.

Cisco Wireless Controller Configuration Guide, Release 8.3

Upgrading the Controller Software

Step 3

Step 4

Step 5

Step 6

Step 7

Step 8

Step 9

Step 10

Step 11

Step 12

Step 13

Step 14

Step 15

Maintenance Deployment (MD)—These software releases provide bug fixes and ongoing software maintenance.

Deferred (DF)—These software releases have been deferred. We recommend that you migrate to an upgraded release.

g) Choose a software release number.

h) Click the filename (filename.aes).

i) Click Download.

j) Read Cisco’s End User Software License Agreement and then click Agree.

k) Save the file to your hard drive.

l) Repeat steps a through k to download the remaining file.

Copy the controller software file (filename.aes) to the default directory on your TFTP or FTP server.

(Optional) Disable the controller 802.11X networks.

Note

For busy networks, controllers on high utilization, or small controller platforms, we recommend that you disable the 802.11X networks as a precautionary measure.

Choose Commands > Download File to open the Download File to Controller page.

From the File Type drop-down list, choose Code.

From the Transfer Mode drop-down list, choose from the following options:

• TFTP

• FTP

• SFTP (available in 7.4 and later releases)

In the IP Address text box, enter the IP address of the server.

If you are using a TFTP server, the default values of 10 retries and 6 seconds for the Maximum Retries and Timeout text boxes should work correctly without any adjustment. However, you can change these values.

Enter the maximum number of times that the TFTP server attempts to download the software in the Maximum Retries text box and the amount of time (in seconds) that the TFTP server attempts to download the software in the Timeout text box.

In the File Path text box, enter the directory path of the software.

In the File Name text box, enter the name of the controller software file (filename.aes).

If you are using an FTP server, follow these steps: a) In the Server Login Username text box, enter the username to log into the FTP server.

b) In the Server Login Password text box, enter the password to log into the FTP server.

c) In the Server Port Number text box, enter the port number on the FTP server through which the download occurs.

The default value is 21.

Click Download to download the software to the controller. A message appears indicating the status of the download.

To configure the predownloading of access point images globally, choose Wireless > Access Points > Global

Configuration to open the Global Configuration page.

In the AP Image Pre-download section, perform one of the following:

• To instruct all the access points to predownload a primary image from the controller, click Download Primary under the AP Image Pre-download.

• To instruct all the access points to swap their primary and backup images, click Interchange Image.

• To download an image from the controller and store it as a backup image, click Download Backup.

Cisco Wireless Controller Configuration Guide, Release 8.3

Upgrading the Controller Software

Step 16

Step 17

• To abort the predownload operation, click Abort Predownload.

Click OK.

Click Apply.

Predownloading an Image to Access Points (CLI)

Using the CLI, you can predownload an image to a specific access point or to all access points.

Step 1

Step 2

Step 3

Step 4

Step 5

Step 6

Follow these steps to obtain the controller software: a) Browse to the Cisco Software Center: http://www.cisco.com/cisco/software/navigator.html

b) Select Wireless from the center selection window.

c) Click Wireless LAN Controllers.

The following options are available: Integrated Controllers and Controller Modules and Standalone Controllers.

d) Depending on your controller platform, click one of the above options.

e) Click the controller model number or name. The Download Software page is displayed.

f) Click a controller software release. The software releases are labeled as follows to help you determine which release to download:

Early Deployment (ED)—These software releases provide new features, new hardware platform support, and bug fixes.

Maintenance Deployment (MD)—These software releases provide bug fixes and ongoing software maintenance.

Deferred (DF)—These software releases have been deferred. We recommend that you migrate to an upgraded release.

g) Choose a software release number.

h) Click the filename (filename.aes).

i) Click Download.

j) Read Cisco’s End User Software License Agreement and then click Agree.

k) Save the file to your hard drive.

l) Repeat steps a through n to download the remaining file.

Copy the controller software file (filename.aes) to the default directory on your TFTP or FTP server.

(Optional) Disable the 802.11 networks.

Note

For busy networks, controllers on high utilization, or small controller platforms, we recommend that you disable the 802.11a/n or 802.11b/g/n networks as a precautionary measure.

For Cisco WiSM2, shut down the controller port channel on the Catalyst switch to allow the controller to reboot before the access points start downloading the software.

Disable any WLANs on the controller using the config wlan disable wlan_id command.

Specify access points that will receive the predownload image.

Use one of these commands to specify access points for predownload:

• Specify access points for predownload by entering this command:

config ap image predownload {primary | backup} {ap_name | all}

Cisco Wireless Controller Configuration Guide, Release 8.3

Upgrading the Controller Software

Step 7

The primary image is the new image; the backup image is the existing image. Access points always boot with the primary image.

• Swap an access point’s primary and backup images by entering this command:

config ap image swap {ap_name | all}

• Display detailed information on access points specified for predownload by entering this command:

show ap image {all | ap-name}

The output lists access points that are specified for predownloading and provides for each access point, primary and secondary image versions, the version of the predownload image, the predownload retry time (if necessary), and the number of predownload attempts. The output also includes the predownload status for each device. The status of the access points is as follows:

• None—The access point is not scheduled for predownload.

• Predownloading—The access point is predownloading the image.

• Not supported—The access point (1120, 1230, and 1310) does not support predownloading.

• Initiated—The access point is waiting to get the predownload image because the concurrent download limit has been reached.

• Failed—The access point has failed 64 predownload attempts.

• Complete—The access point has completed predownloading.

Set a reboot time for the controller and the access points.

Use one of these commands to schedule a reboot of the controller and access points:

• Specify the amount of time delay before the devices reboot by entering this command:

reset system in HH:MM:SS image {swap | no-swap} reset-aps [save-config]

Note

The swap operand in the reset command will result in the swapping of the primary and backup images on both the controller and the access point.

The controller sends a reset message to all joined access points, and then the controller resets.

• Specify a date and time for the devices to reboot by entering this command:

reset system at YYYY-MM-DD HH:MM:SS image {swap | no-swap} reset-aps [save-config]

The controller sends a reset message to all joined access points, and then the controller resets.

Note

The swap operand in the reset command will result in the swapping of the primary and backup images on both the controller and the access point.

• Set up an SNMP trap message that announces the upcoming reset by entering this command:

reset system notify-time minutes

The controller sends the announcement trap the configured number of minutes before the reset.

• Cancel the scheduled reboot by entering this command:

reset system cancel

Cisco Wireless Controller Configuration Guide, Release 8.3

Upgrading the Controller Software

Note

If you configure reset times and then use the config time command to change the system time on the controller, the controller notifies you that any scheduled reset times will be canceled and must be reconfigured after you set the system time.

Use the show reset command to display scheduled resets.

Information similar to the following appears:

System reset is scheduled for Apr 08 01:01:01 2010.

Current local time and date is Apr 07 02:57:44 2010.

A trap will be generated 10 minutes before each scheduled system reset.

Use 'reset system cancel' to cancel the reset.

Configuration will be saved before the system reset.

Cisco Wireless Controller Configuration Guide, Release 8.3

Upgrading the Controller Software

Cisco Wireless Controller Configuration Guide, Release 8.3

C H A P T E R

Managing Configuration

•

Resetting the Cisco WLC to Default Settings, page 91

•

Saving Configurations, page 92

•

Editing Configuration Files, page 93

•

Clearing the Controller Configuration, page 94

•

Erasing the Controller Configuration, page 94

•

Resetting the Controller, page 94

•

Transferring Files to and from a Controller, page 95

Resetting the Cisco WLC to Default Settings

Information About Resetting the Controller to Default Settings

You can return the controller to its original configuration by resetting the controller to factory-default settings.

Cisco Wireless Controller Configuration Guide, Release 8.3

Saving Configurations

Resetting the Controller to Default Settings (GUI)

Step 1

Step 2

Step 3

Step 4

Step 5

Step 6

Step 7

Step 8

Step 9

Start your Internet browser.

Enter the controller IP address in the browser address line and press Enter. An Enter Network Password dialog box appears.

Enter your username in the User Name text box. The default username is admin.

Enter the wireless device password in the Password text box and press Enter. The default password is admin.

Choose Commands > Reset to Factory Default.

Click Reset.

When prompted, confirm the reset.

Reboot the controller without saving the configuration.

Use the configuration wizard to enter configuration settings. See the

Configuring the Controller—Using the CLI

Configuration Wizard

section for more information.

Resetting the Controller to Default Settings (CLI)

Step 1

Step 2

Step 3

Enter the reset system command. At the prompt that asks whether you need to save changes to the configuration, enter

N. The unit reboots.

When you are prompted for a username, enter the recover-config command to restore the factory-default configuration.

The controller reboots and displays this message:

Welcome to the Cisco WLAN Solution Wizard Configuration Tool

Use the configuration wizard to enter configuration settings. See the

Configuring the Controller—Using the CLI

Configuration Wizard

section for more information.

Saving Configurations

Controllers contain two kinds of memory: volatile RAM and NVRAM. At any time, you can save the configuration changes from active volatile RAM to nonvolatile RAM (NVRAM) using one of these commands:

• save config—Saves the configuration from volatile RAM to NVRAM without resetting the controller.

• reset system—Prompts you to confirm that you want to save configuration changes before the controller reboots.

• logout—Prompts you to confirm that you want to save configuration changes before you log out.

Cisco Wireless Controller Configuration Guide, Release 8.3

Editing Configuration Files

Editing Configuration Files

When you save the controller’s configuration, the controller stores it in XML format in flash memory. Controller software release 5.2 or later releases enable you to easily read and modify the configuration file by converting it to CLI format. When you upload the configuration file to a TFTP/FTP/SFTP server, the controller initiates the conversion from XML to CLI. You can then read or edit the configuration file in a CLI format on the server. When you are finished, you download the file back to the controller, where it is reconverted to an

XML format and saved.

Step 1

Step 2

Step 3

Step 4

Step 5

Step 6

Upload the configuration file to a TFTP/FTP/SFTP server by performing one of the following:

• Upload the file using the controller GUI.

• Upload the file using the controller CLI.

Read or edit the configuration file on the server. You can modify or delete existing CLI commands and add new CLI commands to the file.

Note

To edit the configuration file, you can use either Notepad or WordPad on Windows or the VI editor on

Linux.

Save your changes to the configuration file on the server.

Download the configuration file to the controller by performing one of the following:

• Download the file using the controller GUI.

• Download the file using the controller CLI.

The controller converts the configuration file to an XML format, saves it to flash memory, and then reboots using the new configuration. CLI commands with known keywords and proper syntax are converted to XML while improper CLI commands are ignored and saved to flash memory. Any CLI commands that have invalid values are replaced with default values. To see any ignored commands or invalid configuration values, enter this command:

show invalid-config

Note

You cannot execute this command after the clear config or save config command.

If the downloaded configuration contains a large number of invalid CLI commands, you might want to upload the invalid configuration to the TFTP or FTP server for analysis. To do so, perform one of the following:

• Upload the invalid configuration using the controller GUI. Follow the instructions in the Uploading Configuration

Files (GUI) section but choose Invalid Config from the File Type drop-down list in Step 2 and skip Step 3.

• Upload the invalid configuration using the controller CLI. Follow the instructions in the Uploading Configuration

Files (CLI) section but enter the transfer upload datatype invalid-config command in Step 2 and skip Step 3.

The controller does not support the uploading and downloading of port configuration CLI commands. If you want to configure the controller ports, enter these commands:

• config port linktrap {port | all} {enable | disable}—Enables or disables the up and down link traps for a specific controller port or for all ports.

• config port adminmode {port | all} {enable | disable}—Enables or disables the administrative mode for a specific controller port or for all ports.

Cisco Wireless Controller Configuration Guide, Release 8.3

Clearing the Controller Configuration

Step 7

Save your changes by entering this command:

save config

Clearing the Controller Configuration

Step 1

Step 2

Step 3

Clear the configuration by entering this command:

clear config

Enter y at the confirmation prompt to confirm the action.

Reboot the system by entering this command:

reset system

Enter n to reboot without saving configuration changes. When the controller reboots, the configuration wizard starts automatically.

Follow the instructions in the Configuring the Controller-Using the Configuration Wizard section to complete the initial configuration.

Erasing the Controller Configuration

Step 1

Step 2

Step 3

Reset the configuration by entering this command:

reset system

At the confirmation prompt, enter y to save configuration changes to NVRAM. The controller reboots.

When you are prompted for a username, restore the factory-default settings by entering this command:

recover-config

The controller reboots and the configuration wizard starts automatically.

Follow the instructions in the Configuring the Controller-Using the Configuration Wizard section to complete the initial configuration.

Resetting the Controller

You can reset the controller and view the reboot process on the CLI console using one of the following two methods:

• Turn the controller off and then turn it back on.

Cisco Wireless Controller Configuration Guide, Release 8.3

Transferring Files to and from a Controller

• On the CLI, enter reset system. At the confirmation prompt, enter y to save configuration changes to

NVRAM. The controller reboots.

When the controller reboots, the CLI console displays the following reboot information:

• Initializing the system.

• Verifying the hardware configuration.

• Loading microcode into memory.

• Verifying the operating system software load.

• Initializing with its stored configurations.

• Displaying the login prompt.

Transferring Files to and from a Controller

Controllers have built-in utilities for uploading and downloading various files. Follow the instructions in these sections to import files using either the controller GUI or CLI:

Backing Up and Restoring Cisco WLC Configuration

We recommend that you upload your controller’s configuration file to a server to back it up. If you lose your configuration, you can then download the saved configuration to the controller.

Note

Do not download a configuration file to your controller that was uploaded from a different controller platform. For example, a Cisco 5500 Series Controller does not support the configuration file from a Cisco

2500 Series Controller.

Note

While Cisco WLC configuration backup is in progress, we recommend you do not initiate any new configuration or modify any existing configuration settings. This is to avoid corrupting the configuration file.

Follow these guidelines when working with configuration files:

• Any CLI with an invalid value is filtered out and set to default by the XML validation engine. Validation occurs during bootup. A configuration may be rejected if the validation fails. A configuration may fail if you have an invalid CLI. For example, if you have a CLI where you try to configure a WLAN without adding appropriate commands to add the WLAN.

• A configuration may be rejected if the dependencies are not addressed. For example, if you try to configure dependent parameters without using the add command. The XML validation may succeed but the configuration download infrastructure will immediately reject the configuration with no validation errors.

• An invalid configuration can be verified by using the show invalid-config command. The show

invalid-config command reports the configuration that is rejected by the controller either as part of download process or by XML validation infrastructure.

Cisco Wireless Controller Configuration Guide, Release 8.3

Transferring Files to and from a Controller

Note

You can also read and modify the configuration file.

• The FTP or the TFTP servers for transfer of configuration, image, and so on, must be reachable over a wired connection. The transfer cannot be performed over one of the wireless clients of the Cisco WLC.

If you try to use a wireless client of the Cisco WLC, you are prompted with a system message saying that the server is not reachable. However, if you use a wireless client that is associated with another

Cisco WLC, the FTP or the TFTP servers are reachable.

Uploading Configuration Files

You can upload configuration files using either the GUI or the CLI.

Uploading the Configuration Files (GUI)

Step 1

Step 2

Step 3

Step 4

Step 5

Step 6

Step 7

Step 8

Step 9

Choose Commands > Upload File to open the Upload File from Controller page.

From the File Type drop-down list, choose Configuration.

Encrypt the configuration file by selecting the Configuration File Encryption check box and entering the encryption key in the Encryption Key text box.

From the Transfer Mode drop-down list, choose from the following options:

• TFTP

• FTP

• SFTP (available in 7.4 and later releases)

In the IP Address text box, enter the IP address of the server.

In the File Path text box, enter the directory path of the configuration file.

In the File Name text box, enter the name of the configuration file.

If you are using an FTP server, follow these steps: a) In the Server Login Username text box, enter the username to log into the FTP server.

b) In the Server Login Password text box, enter the password to log into the FTP server.

c) In the Server Port Number text box, enter the port number on the FTP server through which the upload occurs. The default value is 21.

Click Upload to upload the configuration file to the server. A message appears indicating the status of the upload. If the upload fails, repeat this procedure and try again.

Uploading the Configuration Files (CLI)

Step 1

Step 2

Specify the transfer mode used to upload the configuration file by entering this command:

transfer upload mode {tftp | ftp | sftp}

Specify the type of file to be uploaded by entering this command:

Cisco Wireless Controller Configuration Guide, Release 8.3

Transferring Files to and from a Controller

Step 3

Step 4

Step 5

Step 6

Step 7

Step 8

Step 9 transfer upload datatype config

Encrypt the configuration file by entering these commands:

• transfer encrypt enable

• transfer encrypt set-key key, where key is the encryption key used to encrypt the file.

Specify the IP address of the server by entering this command:

transfer upload serverip server-ip-address

Specify the directory path of the configuration file by entering this command:

transfer upload path server-path-to-file

Specify the name of the configuration file to be uploaded by entering this command:

transfer upload filename filename

If you are using an FTP server, enter these commands to specify the username and password used to log into the FTP server and the port number through which the upload occurs:

• transfer upload username username

• transfer upload password password

• transfer upload port port

Note

The default value for the port parameter is

21.

Initiate the upload process by entering this command:

transfer upload start

When prompted to confirm the current settings, answer y.

Information similar to the following appears:

Mode............................................. TFTP

TFTP Server IP................................... 10.10.10.4

TFTP Path........................................ Config/

TFTP Filename.................................... AS_4402_4_2_55_8_Config.xml

Data Type........................................ Config File

Encryption....................................... Disabled

**************************************************

*** WARNING: Config File Encryption Disabled ***

**************************************************

Are you sure you want to start? (y/N)

File transfer operation completed successfully.

If the upload fails, repeat this procedure and try again.

Downloading Configuration Files

You can download configuration files using either the GUI or the CLI.

Cisco Wireless Controller Configuration Guide, Release 8.3

Transferring Files to and from a Controller

Downloading the Configuration Files (GUI)

Step 1

Step 2

Step 3

Step 4

Step 5

Step 6

Step 7

Step 8

Step 9

Step 10

Choose Commands > Download File to open the Download File to Controller page.

From the File Type drop-down list, choose Configuration.

If the configuration file is encrypted, select the Configuration File Encryption check box and enter the encryption key used to decrypt the file in the Encryption Key text box.

Note

The key that you enter here should match the one entered during the upload process.

From the Transfer Mode drop-down list, choose from the following options:

• TFTP

• FTP

• SFTP (available in 7.4 and later releases)

In the IP Address text box, enter the IP address of the server.

Enter the maximum number of times that the TFTP server attempts to download the configuration file in the Maximum

Retries text box and the amount of time (in seconds) that the TFTP server attempts to download the configuration file in the Timeout text box.

In the File Path text box, enter the directory path of the configuration file.

In the File Name text box, enter the name of the configuration file.

If you are using an FTP server, follow these steps: a) In the Server Login Username text box, enter the username to log into the FTP server.

b) In the Server Login Password text box, enter the password to log into the FTP server.

c) In the Server Port Number text box, enter the port number on the FTP server through which the download occurs.

The default value is 21.

Click Download to download the file to the controller. A message appears indicating the status of the download, and the controller reboots automatically. If the download fails, repeat this procedure and try again.

Downloading the Configuration Files (CLI)

Note

The controller does not support incremental configuration downloads. The configuration file contains all mandatory commands (all interface address commands, mgmtuser with read-write permission commands, and interface port or LAG enable or disable commands) required to successfully complete the download.

For example, if you download only the config time ntp server index server_address command as part of the configuration file, the download fails. Only the commands present in the configuration file are applied to the controller, and any configuration in the controller prior to the download is removed.

Step 1

Specify the transfer mode used to download the configuration file by entering this command:

Cisco Wireless Controller Configuration Guide, Release 8.3

Transferring Files to and from a Controller

Step 2

Step 3

transfer download mode {tftp | ftp | sftp}

Specify the type of file to be downloaded by entering this command:

transfer download datatype config

If the configuration file is encrypted, enter these commands:

• transfer encrypt enable

• transfer encrypt set-key key, where key is the encryption key used to decrypt the file.

Note

The key that you enter here should match the one entered during the upload process.

Step 4

Step 5

Step 6

Step 7

Step 8

Step 9

Step 10

Specify the IP address of the TFTP or FTP server by entering this command:

transfer download serverip server-ip-address

Specify the directory path of the configuration file by entering this command:

transfer download path server-path-to-file

Specify the name of the configuration file to be downloaded by entering this command:

transfer download filename filename

If you are using a TFTP server, enter these commands:

• transfer download tftpMaxRetries retries

• transfer download tftpPktTimeout timeout

Note

The default values of 10 retries and a 6-second timeout should work correctly without any adjustment.

If you are using an FTP server, enter these commands to specify the username and password used to log into the FTP server and the port number through which the download occurs:

• transfer upload username username

• transfer upload password password

• transfer upload port port

Note

The default value for the port parameter is

21.

View the updated settings by entering this command:

transfer download start

When prompted to confirm the current settings and start the download process, answer y.

Information similar to the following appears:

Mode............................................. TFTP

TFTP Server IP................................... 10.10.10.4

TFTP Path........................................ Config/

TFTP Filename.................................... AS_4402_4_2_55_8_Config.xml

Data Type........................................ Config File

Encryption....................................... Disabled

Cisco Wireless Controller Configuration Guide, Release 8.3

Transferring Files to and from a Controller

**************************************************

*** WARNING: Config File Encryption Disabled ***

**************************************************

Are you sure you want to start? (y/N)

File transfer operation completed successfully.

If the download fails, repeat this procedure and try again.

Downloading a Login Banner File

You can download a login banner file using either the GUI or the CLI. The login banner is the text that appears on the page before user authentication when you access the controller GUI or CLI using Telnet, SSH, or a console port connection.

You save the login banner information as a text (*.txt) file. The text file cannot be larger than 1296 characters and cannot have more than 16 lines of text.

Note

The ASCII character set consists of printable and nonprintable characters. The login banner supports only printable characters.

Here is an example of a login banner:

Welcome to the Cisco Wireless Controller!

Unauthorized access prohibited.

Contact [email protected] for access.

Follow the instructions in this section to download a login banner to the controller through the GUI or CLI.

However, before you begin, make sure that you have a TFTP or FTP server available for the file download.

Follow these guidelines when setting up a TFTP or FTP server:

• If you are downloading through the service port, the TFTP or FTP server must be on the same subnet as the service port because the service port is not routable, or you must create static routes on the controller.

• If you are downloading through the distribution system network port, the TFTP or FTP server can be on the same or a different subnet because the distribution system port is routable.

• A third-party TFTP or FTP server cannot run on the same computer as Cisco Prime Infrastructure because the Prime Infrastructure built-in TFTP or FTP server and the third-party TFTP or FTP server require the same communication port.

Note

Clearing the controller configuration does not remove the login banner. See the

Clearing the Login Banner (GUI)

section for information about clearing the login banner using the controller GUI or CLI.

100

Cisco Wireless Controller Configuration Guide, Release 8.3

Transferring Files to and from a Controller

Note

The controller can have only one login banner file. If you download another login banner file to the controller, the first login banner file is overwritten.

Downloading a Login Banner File (GUI)

Step 1

Step 2

Step 3

Step 4

Step 5

Step 6

Step 7

Step 8

Step 9

Step 10

Copy the login banner file to the default directory on your server.

Choose Commands > Download File to open the Download File to Controller page.

From the File Type drop-down list, choose Login Banner.

From the Transfer Mode drop-down list, choose from the following options:

• TFTP

• FTP

• SFTP (available in 7.4 and later releases)

In the IP Address text box, enter the IP address of the server type you chose in Step 4.

Enter the maximum number of times that the TFTP server attempts to download the certificate in the Maximum Retries text box and the amount of time (in seconds) that the TFTP server attempts to download the certificate in the Timeout text box.

In the File Path text box, enter the directory path of the login banner file.

In the File Name text box, enter the name of the login banner text (*.txt) file.

If you are using an FTP server, follow these steps: a) In the Server Login Username text box, enter the username to log into the FTP server.

b) In the Server Login Password text box, enter the password to log into the FTP server.

c) In the Server Port Number text box, enter the port number on the FTP server through which the download occurs.

The default value is 21.

Click Download to download the login banner file to the controller. A message appears indicating the status of the download.

Downloading a Login Banner File (CLI)

Step 1

Step 2

Log into the controller CLI.

Specify the transfer mode used to download the config file by entering this command:

transfer download mode {tftp | ftp | sftp}

Cisco Wireless Controller Configuration Guide, Release 8.3

101

Transferring Files to and from a Controller

Step 3

Step 4

Step 5

Step 6

Step 7

Step 8

Step 9

Download the controller login banner by entering this command:

transfer download datatype login-banner

Specify the IP address of the TFTP or FTP server by entering this command:

transfer download serverip server-ip-address

Specify the name of the config file to be downloaded by entering this command:

transfer download path server-path-to-file

Specify the directory path of the config file by entering this command:

transfer download filenamefilename.txt

If you are using a TFTP server, enter these commands:

• transfer download tftpMaxRetries retries

• transfer download tftpPktTimeout timeout

Note

The default values of 10 retries and a 6-second timeout should work correctly without any adjustment.

If you are using an FTP server, enter these commands:

• transfer download username username

• transfer download password password

• transfer download port port

Note

The default value for the port parameter is

21.

View the download settings by entering the transfer download start command. Enter y when prompted to confirm the current settings and start the download process.

Clearing the Login Banner (GUI)

Step 1

Step 2

Step 3

Choose Commands > Login Banner to open the Login Banner page.

Click Clear.

When prompted, click OK to clear the banner.

To clear the login banner from the controller using the controller CLI, enter the clear login-banner command.

102

Cisco Wireless Controller Configuration Guide, Release 8.3

Transferring Files to and from a Controller

Uploading PACs

Protected access credentials (PACs) are credentials that are either automatically or manually provisioned and used to perform mutual authentication with a local EAP authentication server during EAP-FAST authentication.

When manual PAC provisioning is enabled, the PAC file is manually generated on the controller.

Follow the instructions in this section to generate and load PACs from the controller through the GUI or CLI.

However, before you begin, make sure you have a TFTP or FTP server available for the PAC upload. Follow these guidelines when setting up a TFTP or FTP server:

• If you are uploading through the service port, the TFTP or FTP server must be on the same subnet as the service port because the service port is not routable, or you must create static routes on the controller.

• If you are uploading through the distribution system network port, the TFTP or FTP server can be on the same or a different subnet because the distribution system port is routable.

Uploading PACs (GUI)

Step 1

Step 2

Step 3

Step 4

Step 5

Step 6

Step 7

Step 8

Step 9

Step 10

Step 11

Step 12

Choose Commands > Upload File to open the Upload File from Controller page.

From the File Type drop-down list, choose PAC (Protected Access Credential).

In the User text box, enter the name of the user who will use the PAC.

In the Validity text box, enter the number of days for the PAC to remain valid. The default setting is zero (0).

In the Password and Confirm Password text boxes, enter a password to protect the PAC.

From the Transfer Mode drop-down list, choose from the following options:

• TFTP

• FTP

• SFTP (available in 7.4 and later releases)

In the IP Address (IPv4/IPv6) text box, enter the IPv4/IPv6 address of the server.

In the File Path text box, enter the directory path of the PAC.

In the File Name text box, enter the name of the PAC file. PAC files have a .pac extension.

If you are using an FTP server, follow these steps: a) In the Server Login Username text box, enter the username to log into the FTP server.

b) In the Server Login Password text box, enter the password to log into the FTP server.

c) In the Server Port Number text box, enter the port number on the FTP server through which the upload occurs. The default value is 21.

Click Upload to upload the PAC from the controller. A message appears indicating the status of the upload.

Follow the instructions for your wireless client to load the PAC on your client devices. Make sure to use the password that you entered above.

Cisco Wireless Controller Configuration Guide, Release 8.3

103

Transferring Files to and from a Controller

Uploading PACs (CLI)

Step 1

Step 2

Step 3

Step 4

Step 5

Step 6

Step 7

Step 8

Step 9

Step 10

Log on to the controller CLI.

Specify the transfer mode used to upload the config file by entering this command:

transfer upload mode {tftp | ftp | sftp}

Upload a Protected Access Credential (PAC) by entering this command:

transfer upload datatype pac

Specify the identification of the user by entering this command:

transfer upload pac username validity password

Specify the IP address of the TFTP or FTP server by entering this command:

transfer upload serverip server-ip-address

Note

The server supports both, IPv4 and

IPv6.

Specify the directory path of the config file by entering this command:

transfer upload path server-path-to-file

Specify the name of the config file to be uploaded by entering this command:

transfer upload filename manual.pac.

If you are using an FTP server, enter these commands:

• transfer upload username username

• transfer upload password password

• transfer upload port port

Note

The default value for the port parameter is

21.

View the updated settings by entering the transfer upload start command. Answer y when prompted to confirm the current settings and start the upload process.

Follow the instructions for your wireless client to load the PAC on your client devices. Make sure to use the password that you entered above.

104

Cisco Wireless Controller Configuration Guide, Release 8.3

C H A P T E R

Network Time Protocol Setup

•

Information About Configuring Authentication for the Controller and NTP/SNTP Server, page 105

•

Configuring the NTP/SNTP Server for Authentication (GUI), page 105

•

Configuring the NTP/SNTP Server for Authentication (CLI), page 106

•

Configuring an NTP/SNTP Server to Sync Date and Time, page 106

Information About Configuring Authentication for the Controller and NTP/SNTP

Server

Cisco WLCs must synchronize time with an NTP/SNTP server by authentication. By default, an MD5 checksum is used.

Configuring the NTP/SNTP Server for Authentication (GUI)

Step 1

Step 2

Step 3

Step 4

Choose Controller > NTP > Server to open the NTP Severs page.

Click New to add a new NTP/SNTP Server.

In the Server Index (Priority) text box, enter the NTP/SNTP server index.

The controller tries Index 1 first, then Index 2 through 3, in a descending order. Set this to 1 if your network is using only one NTP/SNTP server.

Enter the server IP address.

You can enter an IPv4 or an IPv6 address or a fully qualified domain name (FQDN), which should meet the following criteria:

• Contains only a-z , A-Z, and 0-9 characters.

• Does not start with a dot (.) or a hyphen (-).

• Does not end with a dot (.).

• Does not have 2 consecutive dots (..).

Cisco Wireless Controller Configuration Guide, Release 8.3

105

Configuring the NTP/SNTP Server for Authentication (CLI)

Step 5

Step 6

Step 7

Step 8

Step 9

Enable or disable the NTP/SNTP Authentication.

If you enable the NTP/SNTP Authentication, enter the Key Index.

Click Apply.

Delete an exisitng NTP server IP address or DNS server by hovering the cursor over the blue drop-down arrow for that server index and choose Remove.

Confirm the deletion by clicking on OK in the dialog box.

Configuring the NTP/SNTP Server for Authentication (CLI)

• config time ntp auth enable server-index key-index—Enables NTP/SNTP authentication on a given

NTP/SNTP server.

• config time ntp key-auth add key-index md5 key-format key—Adds an authentication key. By default

MD5 is used. The key format can be "ascii" or "hex".

• config time ntp key-auth delete key-index—Deletes authentication keys.

• config time ntp auth disable server-index—Disables NTP/SNTP authentication.

• show ntp-keys—Displays the NTP/SNTP authentication related parameter.

Configuring an NTP/SNTP Server to Sync Date and Time

Each NTP/SNTP server IP address is added to the controller database. Each controller searches for an

NTP/SNTP server and obtains the current time upon reboot and at each user-defined polling interval (daily to weekly).

Use these commands to configure an NTP/SNTP server to obtain the date and time:

• To specify the NTP/SNTP server for the controller, enter this command:

config time ntp server index ip_address or dns_domain

Note

To enter the DNS domain name, it should meet the following criteria:

• Contains only a-z , A-Z, and 0-9 characters.

• Does not start with a dot (.) or a hyphen (-).

• Does not end with a dot (.).

• Does not have 2 consecutive dots (..).

• To specify the polling interval (in seconds), enter this command:

config time ntp interval

• To delete an NTP server IP address or DNS server from the controller, enter this command:

106

Cisco Wireless Controller Configuration Guide, Release 8.3

config time ntp delete NTP_server index

Configuring an NTP/SNTP Server to Sync Date and Time

Cisco Wireless Controller Configuration Guide, Release 8.3

107

Configuring an NTP/SNTP Server to Sync Date and Time

108

Cisco Wireless Controller Configuration Guide, Release 8.3

C H A P T E R

High Availability

•

Information About High Availability, page 109

•

Restrictions on High Availability, page 114

•

Configuring High Availability (GUI), page 117

•

Configuring High Availability (CLI), page 118

•

Monitoring High Availability Standby WLC, page 120

Information About High Availability

High availability (HA) in controllers allows you to reduce the downtime of the wireless networks that occurs due to the failover of controllers.

A 1:1 (Active:Standby-Hot) stateful switchover of access points (AP SSO) is supported. In an HA architecture, one controller is configured as the primary controller and another controller as the secondary controller.

After you enable HA, the primary and secondary controllers are rebooted. During the boot process, the role of the primary controller is negotiated as active and the role of the secondary controller as standby-hot. After a switchover, the secondary controller becomes the active controller and the primary controller becomes the standby-hot controller. After subsequent switchovers, the roles are interchanged between the primary and the secondary controllers. The reason for switchovers are either because of manual trigger, or a controller, or network failure.

During an AP SSO, all the AP sessions statefully switch over and all the clients are deauthenticated and reassociated with the new active controller except for the locally switched clients in the FlexConnect mode.

The standby-hot controller continuously monitors the health of the active controller through a direct wired connection over a dedicated redundancy port. Both the controllers share the same configurations, including the IP address of the management interface.

Before you enable HA, ensure that both the controllers are physically connected through the redundant port using an Ethernet cable. Also, ensure that the uplink is connected to an infrastructure switch and that the gateway is reachable from both the controllers.

In HA architecture, the redundancy port and redundant management interfaces have been introduced.

A seamless transition of clients from the active controller to the standby controller is also supported. Clients that are not in the Run state are removed after the switchover. During the stateful switchover of a client (Client

SSO), the information of the client is synchronized with the standby controller when the client is associated

Cisco Wireless Controller Configuration Guide, Release 8.3

109

Information About High Availability

with the controller, or is configured. Clients that are fully authenticated, that is, clients that are in the Run state, are synchronized with the peer controller. The data structures of clients are synchronized based on the client state. Clients that are in the transient state are dissociated after a switchover.

In the Cisco Wireless LAN Controller Release 8.0 and later, the output of the show ap join stats summary command displays the status of the access points based on whether the access point joined the controller or it was synchronized from Active controller. One of the following statuses is displayed:

• Synched—The access point joined the controller before the SSO.

• Connected—The access point joined the controller after the SSO.

• Joined—The access point rejoined the controller, or a new AP has joined the controller after the SSO.

In Release 8.0 and later, the output of the show redundancy summary command displays the bulk synchronization status of access points and clients after the pair-up of active and standby controllers occurs.

The values are:

• Pending— Indicates that synchronization of access points and the corresponding clients details from the active to standby controller is yet to begin.

• In-progress— Indicates that synchronization of access points and the corresponding clients details from the active to standby controller has begun and synchronization is in progress.

• Complete—Indicates that synchronization is complete and the standby controller is ready for a switchover to resume the services of the active controller.

From release 8.0 and later, in a High Availability scenario, the sleeping timer is synchronized between active and standby.

ACL and NAT IP configurations are synchronized to the HA standby controller when these parameters are configured before HA pair-up. If the NAT IP is set on the management interface, the access point sets the AP manager IP address as the NAT IP address. This issue is seen only when the NAT IP address and ACL are set on the management interface before you enable high availability.

The following are some guidelines for high availability:

• We recommend that you do not pair two controllers of different hardware models. If they are paired, the higher controller model becomes the active controller and the other controller goes into maintenance mode.

• We recommend that you do not pair two controllers on different controller software releases. If they are paired, the controller with the lower redundancy management address becomes the active controller and the other controller goes into maintenance mode.

• It is recommended to disable HA and add license in Cisco 8510/7510/5520/8540 controllers (RTU based). However, it is not mandatory to disable HA as AP licenses added in Primary WLC will be inherited to Secondary WLC.

• All download file types, such as image, configuration, web-authentication bundle, and signature files– are downloaded on the active controller first and then pushed to the standby-hot controller.

• Certificates should be downloaded separately on each controller before they are paired.

• You can upload file types such as configuration files, event logs, crash files, and so on, from the standby-hot controller using the GUI or CLI of the active controller. You can also specify a suffix to the filename to identify the uploaded file.

110

Cisco Wireless Controller Configuration Guide, Release 8.3

Information About High Availability

• To perform a peer upload, use the service port. In a management network, you can also use the redundancy management interface (RMI) that is mapped to the redundancy port or RMI VLAN, or both, where the

RMI is the same as the management VLAN. Note that the RMI and the redundancy port should be in two separate Layer2 VLANs, which is a mandatory configuration.

• If the controllers cannot reach each other through the redundant port and the RMI, the primary controller becomes active and the standby-hot controller goes into the maintenance mode.

Note

To achieve HA between two Cisco Wireless Services Module 2 (WiSM2) platforms, the controllers should be deployed on a single chassis, or on multiple chassis using a virtual switching system (VSS) and extending a redundancy VLAN between the multiple chassis.

Note

A redundancy VLAN should be a nonroutable VLAN in which a Layer 3 interface should not be created for the VLAN, and the interface should be allowed on the trunk port to extend an HA setup between multiple chassis. Redundancy VLAN should be created like any other data VLAN on Cisco IOS-based switching software. A redundancy

VLAN is connected to the redundant port on Cisco WiSM2 through the backplane. It is not necessary to configure the IP address for the redundancy VLAN because the IP address is automatically generated. Also, ensure that the redundancy VLAN is not the same as the management VLAN.

Note

When the RMIs for two controllers that are a pair, and that are mapped to same VLAN and connected to same Layer3 switch stop working, the standby controller is restarted.

Note

The " mobilityHaMac is out of range" xml message is seen during the active/standby second switch over in HA setup. This occurs if mobility HA mac field is more than 128.

• When HA is enabled, the standby controller always uses the Remote Method Invocation (RMI), and all the other interfaces, dynamic and management, are invalid.

Note

The RMI is meant to be used only for active and standby communications and not for any other purpose.

• You must ensure that the maximum transmission unit (MTU) on RMI port is 1500 bytes or higher before you enable high availability.

• When HA is enabled, ensure that you do not use the backed-up image. If this image is used, the HA feature might not work as expected:

• The service port and route information that is configured is lost after you enable SSO. You must configure the service port and route information again after you enable SSO. You can configure the service port and route information for the standby-hot controller using the peer-service-port and peer-route commands.

Cisco Wireless Controller Configuration Guide, Release 8.3

111

Information About High Availability

• For Cisco WiSM2, service port reconfigurations are required after you enable redundancy.

Otherwise, Cisco WiSM2 might not be able to communicate with the supervisor. We recommend that you enable DHCP on the service port before you enable redundancy.

• We recommend that you do not use the reset command on the standby-hot controller directly. If you use this, unsaved configurations will be lost.

• We recommend that you enable link aggregation configuration on the controllers before you enable the port channel in the infrastructure switches.

• All the configurations that require reboot of the active controller results in the reboot of the standby-hot controller.

• The Ignore AP list is not synchronized from the active controller to the standby-hot controller. The list is relearned through SNMP messages from Cisco Prime Infrastructure after the standby-hot controller becomes active.

• Client SSO related guidelines:

• The standby controller maintains two client lists: one is a list of clients in the Run state and the other is a list of transient clients in all the other states.

• Only the clients that are in the Run state are maintained during failover. Clients that are in transition, such as roaming, 802.1X key regeneration, web authentication logout, and so on, are dissociated.

• As with AP SSO, Client SSO is supported only on WLANs. The controllers must be in the same subnet. Layer3 connection is not supported.

• In Release 7.3.x, AP SSO is supported, but client SSO is not supported, which means that after an HA setup that uses Release 7.3.x encounters a switchover, all the clients associated with the controller are deauthenticated and forced to reassociate.

• You must manually configure the mobility MAC address on the then active controller post switchover, when a peer controller has a controller software release that is prior to Release 7.2.

• To enable an access point to maintain controlled quality of service (QoS) for voice and video parameters, all the bandwidth-based or static call admission control (CAC) parameters are synchronized from active to standby when a switchover occurs.

• From 8.0 release and later, the standby controller does not reboot; instead enters the maintenance mode when unable to connect to the default gateway using the redundant port. Once the controller reconnects to the default gateway, the standby controller reboots and the HA pair with the active controller is initiated. However, the active controller still reboots before entering the maintenance mode.

• The following are supported from Release 8.0:

◦Static CAC synchronization—To maintain controlled Quality-of-Service (QoS) for voice and video parameters, all the bandwidth-based or static CAC parameters services are readily available for clients when a switchover occurs.

◦Internal DHCP server—To serve wireless clients of the controller, the internal DHCP server data is synchronized from the active controller to the standby controller. All the assigned IP addresses remain valid, and IP address assignation continues when the role changes from active to standby occurs.

◦Enhanced debugging and serviceability—All the debugging and serviceability services are enhanced for users.

112

Cisco Wireless Controller Configuration Guide, Release 8.3

Information About High Availability

• The physical connectivity or topology of the access points on the switch are not synchronized from the active to the standby controller. The standby controller learns the details only when the synchronization is complete. Hence, you must execute the show ap cdp neighbors all command only after synchronization is complete, and only when the standby becomes the then active controller.

• To enable access points to join the HA-SKU secondary controller that has been reset to factory defaults, you must:

◦Configure the HA SKU controller as secondary controller. To do this, you must execute the config

redundancy unit secondary command on the HA SKU controller.

◦Reboot the HA SKU controller after you successfully execute the config redundancy unit

secondary command.

Redundancy Management Interface

The active and standby-hot controllers use the RMI to check the health of the peer controller and the default gateway of the management interface through network infrastructure.

The RMI is also used to send notifications from the active controller to the standby-hot controller if a failure or manual reset occurs. The standby-hot controller uses the RMI to communicate to the syslog, NTP/SNTP server, FTP, and TFTP server.

It is mandatory to configure the IP addresses of the Redundancy Management Interface and the Management

Interface in the same subnet on both the primary and secondary controllers.

Redundancy Port

The redundancy port is used for configuration, operational data synchronization, and role negotiation between the primary and secondary controllers.

The redundancy port checks for peer reachability by sending UDP keepalive messages every 100 milliseconds

(default frequency) from the standby-hot controller to the active controller. If a failure of the active controller occurs, the redundancy port is used to notify the standby-hot controller.

If an NTP/SNTP server is not configured, the redundancy port performs a time synchronization from the active controller to the standby-hot controller.

In Cisco WiSM2, the redundancy VLAN must be configured on the Cisco Catalyst 6000 Supervisor Engine because there is no physical redundancy port available on Cisco WiSM2.

The redundancy port and the redundancy VLAN in Cisco WiSM2 are assigned an automatically generated

IP address in which the last two octets are obtained from the last two octets of the RMI. The first two octets are always 169.254. For example, if the IP address of the RMI is 209.165.200.225, the IP address of the redundancy port is 169.254.200.225.

The redundancy ports can connect over an L2 switch. Ensure that the redundancy port round-trip time is less than 80 milliseconds if the keepalive timer is set to default, that is, 100 milliseconds, or 80 percent of the keepalive timer if you have configured the keepalive timer in the range of 100 milliseconds to 400 milliseconds.

The failure detection time is calculated, for example, if the keepalive timer is set to 100 milliseconds, as follows: 3 * 100 = 300 + 60 = 360 + jitter (12 milliseconds) = ~400 milliseconds. Also, ensure that the bandwidth between redundancy ports is 60 Mbps or higher. Ensure that the maximum transmission unit (MTU) is 1500 bytes or higher.

Cisco Wireless Controller Configuration Guide, Release 8.3

113

Restrictions on High Availability

Restrictions on High Availability

• We recommend that you do not disable LAG physical ports when HA SSO is enabled.

• You should apply an access list for SSH to the redundancy interface on upper switch, if Cisco WLC is configured for HA SSO and redundancy management is configured over a dynamic interface. Failure to do so enables the SSH client to connect through the redundancy management interface regardless of the CPU ACL.

• In an HA environment using FlexConnect locally switched clients, the client information might not show the username. To get details about the client, you must use the MAC address of the client. This restriction does not apply to FlexConnect centrally switched clients or central (local) mode clients.

• It is not possible to access the Cisco WiSM2 GUI through the service interface when you have enabled

HA. The workaround is to create a service port interface again after HA is established.

• In an HA environment, an upgrade from an LDPE image to a non-LDPE image is not supported.

• It is not possible to pair two primary controllers or two secondary controllers.

• Standby controllers are unavailable on the APs connected switch port

• An HA-SKU controller with an evaluation license cannot become a standby controller. However, an

HA-SKU controller with zero license can become a standby controller.

• Service VLAN configuration is lost when moving from HA mode to non-HA mode and vice versa. You should configure the service IP address manually again.

• The following scenario is not supported: The primary controller has the management address and the redundancy management address in the same VLAN, and the secondary controller has the management address in the same VLAN as the primary one, and the redundancy management address in a different

VLAN.

• The following is a list of some software upgrade scenarios:

• A software upgrade on the active controller ensures the upgrade of the standby-hot controller.

• An in-service upgrade is not supported. Therefore, you should plan your network downtime before you upgrade the controllers in an HA environment.

• Rebooting the active controller after a software upgrade also reboots the standby-hot controller.

• If both active and standby-hot controllers have different software releases in the backup, and if you enter the config boot backup command in the active controller, both the controllers reboot with their respective backup images breaking the HA pair due to a software mismatch.

• A schedule reset applies to both the controllers in an HA environment. The peer controller reboots a minute before the scheduled time expires on the active controller.

• You can reboot the standby-hot controller from the active controller by entering the reset

peer-system command if the scheduled reset is not planned. If you reset only the standby-hot controller with this command, any unsaved configurations on the standby-hot controller is lost.

Therefore, ensure that you save the configurations on the active controller before you reset the standby-hot controller.

• A preimage download is reinitiated if an SSO is triggered at the time of the image transfer.

• Only debug and show commands are allowed on the standby-hot controller.

114

Cisco Wireless Controller Configuration Guide, Release 8.3

Restrictions on High Availability

• After a switchover, if a peer controller has a controller software release that is prior to Release 7.5, all the mobility clients are deauthenticated.

• It is not possible to access the standby-hot controller through the controller GUI, Cisco Prime

Infrastructure, or Telnet. You can access the standby-hot controller only on its console.

• When a failover occurs, the standby controller must be in a standby-hot state and the redundant port in a terminal state in SSO for successful switchover to occur.

• To enable or disable LAG, you must disable HA.

Note

If LAG is disabled and both primary and backup ports are connected to the management interface and if the primary port becomes nonoperational, a switchover might occur because the default gateway is not reachable and backup port failover might exceed 12 seconds.

• When a failover occurs and the standby controller becomes the new active controller, it takes approximately 15 to 20 minutes to synchronize the database (AP, client, and multicast) between the two controllers. If another failover occurs during this time, the HA structures would not yet be synchronized.

Therefore, the APs and clients would have to get reassociated and reauthenticated respectively.

• Pairwise Master Key (PMK) cache synchronization is not supported on FlexConnect local-authenticated clients.

• Client SSO restrictions:

• New mobility is not supported.

• Posture and network admission control out-of-band are not supported because the client is not in the Run state.

• The following are not synchronized between the active and standby controller:

• Cisco Compatible Extension-based applications

• Client statistics

• Proxy Mobile IPv6, Application Visibility and Control, session initiation protocol (SIP), and static call admission control (CAC) tree

• Workgroup bridges and the clients associated with them

• Passive clients

• Encryption is supported

• Encryption is supported only if the active and standby controllers communicate through the Redundancy

Management Interface on the management ports. Encryption is not supported if the redundancy port is used for communication between the active and standby controllers.

• You cannot change the NAT address configuration of the management interface when the controllers are in redundancy mode. To enable NAT address configuration on the management interface, you must remove the redundancy configuration first, make the required changes on the primary controller, and then reenable the redundancy configuration on the same controller.

Cisco Wireless Controller Configuration Guide, Release 8.3

115

Restrictions on High Availability

• On Cisco WiSM2 and Cisco Catalyst 6500 Series Supervisor Engine 2T, if HA is enabled, post switchover, the APs might disconnect and reassociate with the WiSM2 controller. To prevent this from occurring, before you configure HA, we recommend that you verify, in the port channel, the details of both the active and standby Cisco WiSM2 controllers that the ports are balanced in the same order and the port channel hash distribution uses fixed algorithm. If they are not in order, you must change the port channel distribution to be fixed and reset Cisco WiSM2 from the Cisco Catalyst 6500 Series Supervisor Engine

2T.

• After you enable SSO, you must access both the standby and active controller using:

◦The console connection

◦SSH facility on the service port

◦SSH facility on the redundant management interface

Note

While SSO is enabled, you can not access both the standby and active controller either using the web UI/the telnet facility or using Cisco Prime Infrastructure/Prime NCS on the service port.

• After the switch over of controller, clients along with children mesh access points (MAPs) are disconnected and are rejoined with the new active controller. The entire mesh tree is rebuilt. The clients of root access points (RAPs) are also disconnected but the RAPs are intact with the controller.

• Synchronization of bulk configurations is supported only for the configurations that are stored in XMLs.

Scheduled reboot is a configuration that is not stored in XMLs or Flash. Therefore, the scheduled reboot configuration is not included in the synchronization of bulk configurations.

• When a switchover occurs, the controller does not synchronize the information on DHCP dirty bit from the active to standby controller even when DHCP dirty bit is set on the active controller. After a switchover, the controller populates the DHCP dirty bit based on the client DHCP retries.

• If you are using Cisco WiSM2, we recommend that you use the following release versions of Cisco IOS on Cisco Catalyst 6500 Series Supervisor Engine 2T:

• 15.1(02)SY

• 15.1(01)ICB40.1

• 15.1(01)ICB29.36

• 15.1(01)ICB29.1

• 15.1(01)IC66.25

• 15.1(01)IB273.72

116

Cisco Wireless Controller Configuration Guide, Release 8.3

Configuring High Availability (GUI)

Configuring High Availability (GUI)

Before You Begin

Ensure that the management interfaces of both controllers are in the same subnet. You can verify this on the

GUI of both the controllers by choosing Controllers > Interfaces and viewing the IP addresses of the management interface.

Step 1

Step 2

Step 3

Step 4

Step 5

On the GUI of both the controllers, choose Controller > Redundancy > Global Configuration.

The Global Configuration window is displayed.

Enter the addresses of the controllers in the Redundant Management IP field and the Peer Redundant Management

IP field.

Note

Ensure that the Redundant Management Interface IP address of one controller is the same as the Redundant

Management Interface IP address of the peer controller.

From the Redundant Unit drop-down list, choose one of the controllers as primary and the other as secondary.

On the GUI of both the controllers, set the SSO to Enabled state.

Note

After you enable an SSO, the service port peer IP address and the service port netmask appear on the configuration window. Note that the service port peer IP address and the netmask can be pushed to the peer only if the HA peer is available and operational. When you enable HA, you do not have to configure the service port peer IP address and the service port netmask parameters. You must configure the parameters only when the HA peer is available and operational. After you enable SSO, both the controllers are rebooted. During the reboot process, the controllers negotiate the redundancy role through the redundant port, based on the configuration. The primary controller becomes the active controller and the secondary controller becomes the standby controller.

(Optional) After the HA pair becomes available and operational, you can configure the peer service port IP address and the netmask after the service port is configured as static. If you enable DHCP on the service port, you do not have to configure these parameters on the Global Configuration window:

• Service Port Peer IP—IP address of the service port of the peer controller.

• Service Port Peer Netmask—Netmask of the service port of the peer controller.

• Mobility MAC Address—A common MAC address for both the active and standby controllers that is used in the mobility protocol. If an HA pair has to be added as a mobility member for a mobility group, the mobility MAC address (instead of the system MAC address of the active or standby controller) should be used. Normally, the mobility MAC address is chosen as the MAC address of the active controller and you do not have to manually configure this.

• Keep Alive Timer—The timer that controls how often the standby controller sends keepalive messages to the active controller. The valid range is between 100 to 1000 milliseconds.

• Peer Search Timer—The timer that controls how often the active controller sends peer search messages to the standby controller. The valid range is between 60 to 300 seconds.

Note

After you enable the HA and pair the controllers, there is only one unified GUI to manage the HA pair through the management port. GUI access through the service port is not feasible for both the active and standby controllers. The standby controller can be managed only through the console port or the service port.

Only Telnet and SSH sessions are allowed through the service port of the active and standby controllers.

Cisco Wireless Controller Configuration Guide, Release 8.3

117

Configuring High Availability (CLI)

Step 6

Step 7

Step 8

Step 9

Step 10

Step 11

Click Apply.

Click Save Configuration.

View the redundancy status of the HA pair by choosing Monitor > Redundancy > Summary.

The Redundancy Summary window is displayed.

View the redundancy status of the HA pair by choosing Monitor > Redundancy > Detail.

The Redundancy Detail page is displayed.

View the redundancy statistics information of the HA pair by choosing Monitor > Redundancy > Statistics.

The Redundancy Statistics page is displayed.

Perform these steps to configure the peer network route: a) Choose Controller > Redundancy > Peer Network Route.

The Network Routes Peer window is displayed.

This window provides a summary of the existing service port network routes of the peer controller to network or element management systems on a different subnet. You can view the IP address, IP netmask, and gateway IP address.

b) To create a new peer network route, click New.

c) Enter the IP address, IP netmask, and the Gateway IP address of the route.

d) Click Apply.

Configuring High Availability (CLI)

Before You Begin

Ensure that the management interfaces of both controllers are in the same subnet.

To configure HA in controllers, you must:

• Configure a local-redundancy IP address and a peer-redundancy management IP address by running this command:

config interface address redundancy-management ip-addr1 peer-redundancy-management ip-addr2

• Configure the role of a controller by entering this command:

config redundancy unit {primary | secondary}

• Configure the redundancy mode by entering this command:

config redundancy mode {sso | none}

Note

Both controllers reboot and then negotiate the roles of active and standby-hot controllers.

• Configure redundancy by entering this command:

config redundancy mode {sso {ap | client} | disable}

Note

You can choose between an AP SSO and a client SSO.

118

Cisco Wireless Controller Configuration Guide, Release 8.3

Configuring High Availability (CLI)

• Configure the route configurations of the standby controller by entering this command:

config redundancy peer-route {add network-ip-addr ip-mask | delete network-ip-addr}

Note

This command can be run only if the HA peer controller is available and operational.

• Configure a mobility MAC address by entering this command:

config redundancy mobilitymac mac-addr

Note

• This command can be run only when SSO is disabled.

• If you upgrade from Release 8.0.110.0 to a later release, this command's setting is removed. You must manually reconfigure the mobility MAC address after the upgrade.

• Configure the IP address and netmask of the peer service port of the standby controller by entering this command:

config redundancy interface address peer-service-port ip-address netmask

This command can be run only if the HA peer controller is available and operational.

• Initiate a manual switchover by entering this command:

redundancy force-switchover

Note

Execute this command only when you require a manual switchover.

• Configure a redundancy timer by entering this command:

config redundancy timer {keep-alive-timer time-in-milliseconds | peer-search-timer time-in-seconds}

• Configure encryption of communication between controllers by entering this command:

config redundancy link-encryption {enable | disable}

• Configure the hash distribution as fixed by entering this command:

config port-channel hash-distribution fixed

• Verify a port channel member order and load value by entering this command:

show etherchannel port-channel

• View the status of the redundancy by entering this command:

show redundancy summary

• View information about the redundancy management interface by entering this command:

show interface detailed redundancy-management

• View information about the redundancy port by entering this command:

show interface detailed redundancy-port

• Reboot a peer controller by entering this command:

reset peer-system

• Start the upload of file types, such as configuration, event logs, crash files, and so on from the standby-hot controller by entering this command on the active controller:

Cisco Wireless Controller Configuration Guide, Release 8.3

119

Monitoring High Availability Standby WLC transfer upload peer-start

• View information about sleeping clients after a switchover, by entering this command on the then active controller :

show custom-web sleep-client summary

• Debug the redundancy modules by entering these commands:

Note

Ensure that SSO is enabled to use these debug commands. Enter config redundancy mode SSO command to enable SSO.

debug redundancy {infra | facilitator | transport | keepalive | gw-reachability | config-sync | ap-sync

| client-sync | mobility}

• infra—Configures debug of the Redundancy Infra Module.

• facilitator—Configures debug of the Redundancy Facilitator Module.

• transport—Configures debug of the Redundancy Transport Module.

• keepalive—Configures debug of the Redundancy Keepalive Module.

• gw-reachability—Configures debug of the Redundancy Gw-reachability Module.

• config-sync—Configures debug of the Redundancy Config-Sync Module.

• ap-sync—Configures debug of the Redundancy AP-Sync Module.

• client-sync—Configures debug of the Redundancy Client-Sync Module.

• mobility—Configures debug of the Redundancy Mobility Module.

Monitoring High Availability Standby WLC

You can view the status and health information of active and standby WLC separately. This section describes the details of getting health information and traps from the standby WLC.

The standby WLC uses the redundancy management interface for any external communications such as when talking to Syslog, NTP server, TFTP server, and so on. On the standby WLC, the management user authentication and accounting is performed on the redundancy management interface. RADIUS or TACACS+ server can be used for user authentication, apart from a local management user account. To support this, the redundancy interface IP address(es) should be added as network device on the RADIUS or TACACS+ server.

The authentication request is sent to RADIUS or TACACS+ server over redundancy management interface.

Whenever you log on to the standby WLC, accounting message is sent to the RADIUS server. The purpose of the accounting message is to log the admin logon events on the standby WLC console.

This feature is supported on all WLC models supporting HA SSO feature:

• Cisco 8500 Series WLCs

• Cisco Flex 7500 Series WLCs

• Cisco 5500 Series WLCs

• Cisco WiSM2

120

Cisco Wireless Controller Configuration Guide, Release 8.3

Monitoring High Availability Standby WLC

Events and Notifications

• Trap when WLC becomes Hot Standby—A trap is reported with time stamp when HA peer becomes

Hot Standby and the trap shown below is reported

"RF notification EventType:37 Reason :HA peer is Hot-Standby...At:..."

A new trap type is added in CISCO-RF-SUPPLEMENTAL-MIB.my

• Trap when Bulk Sync Complete—After the HA pairing is done and Bulk sync is complete, the following trap is reported:

"RF notification EventType:36 Reason :Bulk Sync Completed...At:.."

A new trap type is added in CISCO-RF-SUPPLEMENTAL-MIB.my

• Trap when Standby WLC goes down—When the standby peer goes down due to manual reset, crash, memory leak/hang, or moving to maintenance mode, the following trap is reported:

"RF failure notification ErrorType: 34 Reason :Lost Peer, Moving to Active-No-Peer State!"

On the CLI, you can view the trap by entering the show traplog command.

• Syslog notification when Admin login on Standby

Admin login to Standby via SSH generates an event in msglog/syslog. The following is a sample system message:

*emWeb: Mar 06 20:34:42.675: #CLI-3-LOGIN_STANDBY: [SS] cli_lvl7.c:4520 [USER@9 name="admin" from="SSH"] user login success on standby controller.

You can view this message on the standby WLC by entering the show msglog command.

Admin login to Standby via console generates an event in msglog/syslog. The following is a sample system message:

*emWeb: Mar 06 20:34:42.675: #CLI-3-LOGIN_STANDBY: [SS] cli_lvl7.c:4520 [USER@9 name="admin" from="console"] user login success on standby controller.

You can view this message on the standby WLC by entering the show msglog command.

• Peer Process Statistics—The CPU and Memory statistics of all the threads of the standby WLC are synchronized with the active WLC every 10 seconds. This information is displayed when you query for the Peer statistics on the active WLC.

Enter these commands on the active WLC to view the peer process system, CPU, and memory statistics:

◦show redundancy peer-system statistics

◦show redundancy peer-process cpu

◦show redundancy peer-process memory

On the GUI, choose Monitor > Redundancy > Peer Statistics to view the peer process system, CPU, and memory statistics:

Cisco Wireless Controller Configuration Guide, Release 8.3

121

Monitoring High Availability Standby WLC

122

Cisco Wireless Controller Configuration Guide, Release 8.3

C H A P T E R

Managing Certificates

•

Loading an Externally Generated SSL Certificate, page 123

•

Downloading Device Certificates, page 126

•

Uploading Device Certificates, page 128

•

Downloading CA Certificates, page 130

•

Uploading CA Certificates, page 132

•

Generating a Certificate Signing Request, page 133

Loading an Externally Generated SSL Certificate

This section describes how to load an externally generated SSL certificate.

Information About Externally Generated SSL Certificates

You can use a TFTP server to download an externally generated SSL certificate to the controller. Follow these guidelines for using TFTP:

• If you load the certificate through the service port, the TFTP server must be on the same subnet as the controller because the service port is not routable, or you must create static routes on the controller.

Also, if you load the certificate through the distribution system network port, the TFTP server can be on any subnet.

• A third-party TFTP server cannot run on the same PC as the Cisco Prime Infrastructure because the

Prime Infrastructure built-in TFTP server and the third-party TFTP server require the same communication port.

Note

Chained certificates are supported for web authentication only and not for the management certificate.

Cisco Wireless Controller Configuration Guide, Release 8.3

123

Loading an Externally Generated SSL Certificate

Note

Every HTTPS certificate contains an embedded RSA key. The length of the key can vary from 512 bits, which is relatively insecure, to thousands of bits, which is very secure. When you obtain a new certificate from a Certificate Authority, make sure that the RSA key embedded in the certificate is at least 768 bits long.

Loading an SSL Certificate (GUI)

Step 1

On the HTTP Configuration page, select the Download SSL Certificate check box.

Figure 15: HTTP Configuration Page

Step 2

Step 3

Step 4

Step 5

Step 6

Step 7

Step 8

Step 9

Step 10

In the Server IP Address text box, enter the IP address of the TFTP server.

In the Maximum Retries text box, enter the maximum number of times that the TFTP server attempts to download the certificate.

In the Timeout text box, enter the amount of time (in seconds) that the TFTP server attempts to download the certificate.

In the Certificate File Path text box, enter the directory path of the certificate.

In the Certificate File Name text box, enter the name of the certificate (webadmincert_name.pem).

(Optional) In the Certificate Password text box, enter a password to encrypt the certificate.

Click Apply.

Click Save Configuration.

Choose Commands > Reboot > Reboot > Save and Reboot to reboot the controller for your changes to take effect,

124

Cisco Wireless Controller Configuration Guide, Release 8.3

Loading an Externally Generated SSL Certificate

Loading an SSL Certificate (CLI)

Step 1

Step 2

Step 3

Step 4

Step 5

Step 6

Step 7

Use a password to encrypt the HTTPS certificate in a .PEM-encoded file. The PEM-encoded file is called a web administration certificate file (webadmincert_name.pem).

Move the webadmincert_name.pem file to the default directory on your TFTP server.

To view the current download settings, enter this command and answer n to the prompt:

transfer download start

Information similar to the following appears:

Mode........................................... TFTP

Data Type...................................... Admin Cert

TFTP Server IP................................. xxx.xxx.xxx.xxx

TFTP Path...................................... <directory path>

TFTP Filename..................................

Are you sure you want to start? (y/n) n

Transfer Canceled

Use these commands to change the download settings:

transfer download mode tftp

transfer download datatype webauthcert

transfer download serverip TFTP_server IP_address

transfer download path absolute_TFTP_server_path_to_the_update_file

transfer download filename webadmincert_name.pem

To set the password for the .PEM file so that the operating system can decrypt the web administration SSL key and certificate, enter this command:

transfer download certpassword private_key_password

To confirm the current download settings and start the certificate and key download, enter this command and answer y to the prompt:

transfer download start

Information similar to the following appears:

Mode........................................... TFTP

Data Type...................................... Site Cert

TFTP Server IP................................. xxx.xxx.xxx.xxx

TFTP Path...................................... directory path

TFTP Filename.................................. webadmincert_name

Are you sure you want to start? (y/n) y

TFTP Webadmin cert transfer starting.

Certificate installed.

Please restart the switch (reset system) to use the new certificate.

To save the SSL certificate, key, and secure web password to NVRAM so that your changes are retained across reboots, enter this command:

Cisco Wireless Controller Configuration Guide, Release 8.3

125

Downloading Device Certificates

Step 8 save config

To reboot the controller, enter this command:

reset system

Downloading Device Certificates

Each wireless device (controller, access point, and client) has its own device certificate. For example, the controller is shipped with a Cisco-installed device certificate. This certificate is used by EAP-FAST (when not using PACs), EAP-TLS, PEAP-GTC, and PEAP-MSCHAPv2 to authenticate wireless clients during local

EAP authentication. However, if you want to use your own vendor-specific device certificate, it must be downloaded to the controller.

Note

For more information about configuring local EAP, see the Configuring Local EAP section.

Follow the instructions in this section to download a vendor-specific device certificate to the controller through the GUI or CLI. However, before you begin, make sure you have a TFTP or FTP server available for the certificate download. Follow these guidelines when setting up a TFTP or FTP server:

• If you are downloading through the distribution system network port, the TFTP or FTP server can be on the same or a different subnet because the distribution system port is routable.

Note

All certificates downloaded to the controller must be in PEM format.

Downloading Device Certificates (GUI)

Step 1

Step 2

Step 3

Step 4

Step 5

Copy the device certificate to the default directory on your server.

Choose Commands > Download File to open the Download File to Controller page.

From the File Type drop-down list, choose Vendor Device Certificate.

In the Certificate Password text box, enter the password that was used to protect the certificate.

From the Transfer Mode drop-down list, choose from the following options:

• TFTP

126

Cisco Wireless Controller Configuration Guide, Release 8.3

Downloading Device Certificates

Step 6

Step 7

Step 8

Step 9

Step 10

Step 11

Step 12

Step 13

Step 14

• FTP

• SFTP (available in 7.4 and later releases)

In the IP Address text box, enter the IP address of the server.

In the File Path text box, enter the directory path of the certificate.

In the File Name text box, enter the name of the certificate.

If you are using an FTP server, follow these steps: a) In the Server Login Username text box, enter the username to log into the FTP server.

b) In the Server Login Password text box, enter the password to log into the FTP server.

c) In the Server Port Number text box, enter the port number on the FTP server through which the download occurs.

The default value is 21.

Click Download to download the device certificate to the controller. A message appears indicating the status of the download.

After the download is complete, choose Commands > Reboot > Reboot.

If prompted to save your changes, click Save and Reboot.

Click OK to confirm your decision to reboot the controller.

Downloading Device Certificates (CLI)

Step 1

Step 2

Step 3

Step 4

Step 5

Step 6

Step 7

Log onto the controller CLI.

Specify the transfer mode used to download the config file by entering this command:

transfer download mode {tftp | ftp | sftp}

Specify the type of the file to be downloaded by entering this command:

transfer download datatype eapdevcert

Specify the certificate’s private key by entering this command:

transfer download certpassword password

Specify the IP address of the TFTP or FTP server by entering this command:

transfer download serverip server-ip-address

Specify the name of the config file to be downloaded by entering this command:

transfer download path server-path-to-file

Specify the directory path of the config file by entering this command:

transfer download filename filename.pem

Cisco Wireless Controller Configuration Guide, Release 8.3

127

Uploading Device Certificates

Step 8

Step 9

Step 10

Step 11

If you are using a TFTP server, enter these commands:

• transfer download tftpMaxRetries retries

• transfer download tftpPktTimeout timeout

Note

The default values of 10 retries and a 6-second timeout should work correctly without any adjustment.

If you are using an FTP server, enter these commands:

• transfer download username username

• transfer download password password

• transfer download port port

Note

The default value for the port parameter is

21.

View the updated settings by entering the transfer download start command. Answer y when prompted to confirm the current settings and start the download process.

Reboot the controller by entering this command:

reset system

Uploading Device Certificates

Uploading Device Certificates (GUI)

Step 1

Step 2

Step 3

Step 4

Step 5

Step 6

Step 7

Choose Commands > Upload File to open the Upload File from Controller page.

From the File Type drop-down list, choose IPSec Device Certificate.

From the Transfer Mode drop-down list, choose from the following options:

• TFTP

• FTP

• SFTP

In the IP Address text box, enter the IP address of the server.

In the File Path text box, enter the directory path of the certificate.

In the File Name text box, enter the name of the certificate.

If you are using an FTP server, follow these steps: a) In the Server Login Username text box, enter the username to log on to the FTP server.

128

Cisco Wireless Controller Configuration Guide, Release 8.3

Uploading Device Certificates

Step 8

Step 9

Step 10

Step 11

b) In the Server Login Password text box, enter the password to log on to the FTP server.

c) In the Server Port Number text box, enter the port number on the FTP server through which the download occurs.

The default value is 21. For SFTP, the default value is 22.

Click Upload to upload the CA certificate from the controller. A message appears indicating the status of the upload.

After the upload is complete, choose Commands > Reboot > Reboot.

If prompted to save your changes, click Save and Reboot.

Click OK to confirm your decision to reboot the controller.

Uploading Device Certificates (CLI)

Step 1

Step 2

Step 3

Step 4

Step 5

Step 6

Step 7

Step 8

Step 9

Log on to the controller CLI.

Specify the type of the file to be uploaded by entering this command:

transfer upload datatype ipsecdevcert

Specify the transfer mode used to upload the file by entering this command:

transfer upload mode {tftp | ftp | sftp}

Specify the IP address of the TFTP or FTP server by entering this command:

transfer upload serverip server-ip-address

Specify the directory path of the file by entering this command:

transfer upload path server-path-to-file

Specify the name of the file to be uploaded by entering this command:

transfer upload filename filename

If you are using an FTP server, enter these commands:

• transfer upload username username

• transfer upload password password

• transfer upload port port

Note

The default value for the port parameter for is 21. For SFTP, the default value is

22.

View the updated settings by entering the transfer upload start command. Answer y when prompted to confirm the current settings and start the upload process.

Reboot the controller by entering the reset system command.

Cisco Wireless Controller Configuration Guide, Release 8.3

129

Downloading CA Certificates

Downloading CA Certificates

Controllers and access points have a Certificate Authority (CA) certificate that is used to sign and validate device certificates. The controller is shipped with a Cisco-installed CA certificate. This certificate may be used by EAP-FAST (when not using PACs), EAP-TLS, PEAP-GTC, and PEAP-MSCHAPv2 to authenticate wireless clients during local EAP authentication. However, if you want to use your own vendor-specific CA certificate, it must be downloaded to the controller.

Note

For more information about configuring local EAP, see the Configuring Local EAP section.

Follow the instructions in this section to download CA certificates to the controller through the GUI or CLI.

However, before you begin, make sure that you have a TFTP or FTP server available for the certificate download. Follow these guidelines when setting up a TFTP or FTP server:

• If you are downloading through the distribution system network port, the TFTP or FTP server can be on the same or a different subnet because the distribution system port is routable.

Note

All certificates downloaded to the controller must be in PEM format.

Download CA Certificates (GUI)

Step 1

Step 2

Step 3

Step 4

Step 5

Copy the CA certificate to the default directory on your server.

Choose Commands > Download File to open the Download File to Controller page.

From the File Type drop-down list, choose Vendor CA Certificate.

From the Transfer Mode drop-down list, choose from the following options:

• TFTP

• FTP

• SFTP (available in 7.4 and later releases)

In the IP Address text box, enter the IP address of the server.

130

Cisco Wireless Controller Configuration Guide, Release 8.3

Downloading CA Certificates

Step 6

Step 7

Step 8

Step 9

Step 10

Step 11

Step 12

Step 13

In the File Path text box, enter the directory path of the certificate.

In the File Name text box, enter the name of the certificate.

If you are using an FTP server, follow these steps: a) In the Server Login Username text box, enter the username to log on to the FTP server.

b) In the Server Login Password text box, enter the password to log on to the FTP server.

c) In the Server Port Number text box, enter the port number on the FTP server through which the download occurs.

The default value is 21.

Click Download to download the CA certificate to the controller. A message appears indicating the status of the download.

After the download is complete, choose Commands > Reboot > Reboot.

If prompted to save your changes, click Save and Reboot.

Click OK to confirm your decision to reboot the controller.

Downloading CA Certificates (CLI)

Step 1

Step 2

Step 3

Step 4

Step 5

Step 6

Step 7

Step 8

Log on to the controller CLI.

Specify the transfer mode used to download the config file by entering this command:

transfer download mode {tftp | ftp | sftp}

Specify the type of the file to be downloaded by entering this command:

transfer download datatype eapdevcert

Specify the IP address of the TFTP or FTP server by entering this command:

transfer download serverip server-ip-address

Specify the directory path of the config file by entering this command:

transfer download path server-path-to-file

Specify the name of the config file to be downloaded by entering this command:

transfer download filename filename

If you are using a TFTP server, enter these commands:

• transfer download tftpMaxRetries retries

• transfer download tftpPktTimeout timeout

Note

The default values of 10 retries and a 6-second timeout should work correctly without any adjustment.

If you are using an FTP server, enter these commands:

Cisco Wireless Controller Configuration Guide, Release 8.3

131

Uploading CA Certificates

Step 9

Step 10

• transfer download username username

• transfer download password password

• transfer download port port

Note

The default value for the port parameter is

21.

View the updated settings by entering the transfer download start command. Answer y when prompted to confirm the current settings and start the download process.

Reboot the controller by entering the reset system command.

Uploading CA Certificates

Uploading CA Certificates (GUI)

Step 1

Step 2

Step 3

Step 4

Step 5

Step 6

Step 7

Step 8

Step 9

Step 10

Step 11

Choose Commands > Upload File to open the Upload File from Controller page.

From the File Type drop-down list, choose IPSec CA Certificate.

From the Transfer Mode drop-down list, choose from the following options:

• TFTP

• FTP

• SFTP

In the IP Address text box, enter the IP address of the server.

In the File Path text box, enter the directory path of the certificate.

In the File Name text box, enter the name of the certificate.

If you are using an FTP server, follow these steps: a) In the Server Login Username text box, enter the username to log on to the FTP server.

b) In the Server Login Password text box, enter the password to log on to the FTP server.

c) In the Server Port Number text box, enter the port number on the FTP server through which the download occurs.

The default value is 21. For SFTP, the default value is 22.

Click Upload to upload the CA certificate from the controller. A message appears indicating the status of the upload.

After the upload is complete, choose Commands > Reboot > Reboot.

If prompted to save your changes, click Save and Reboot.

Click OK to confirm your decision to reboot the controller.

132

Cisco Wireless Controller Configuration Guide, Release 8.3

Generating a Certificate Signing Request

Uploading CA Certificates (CLI)

Step 1

Step 2

Step 3

Step 4

Step 5

Step 6

Step 7

Step 8

Step 9

Log on to the controller CLI.

Specify the type of the file to be uploaded by entering this command:

transfer upload datatype ipseccacert

Specify the transfer mode used to upload the file by entering this command:

transfer upload mode {tftp | ftp | sftp}

Specify the IP address of the TFTP or FTP server by entering this command:

transfer upload serverip server-ip-address

Specify the directory path of the file by entering this command:

transfer upload path server-path-to-file

Specify the name of the file to be uploaded by entering this command:

transfer upload filename filename

If you are using an FTP server, enter these commands:

• transfer upload username username

• transfer upload password password

• transfer upload port port

Note

The default value for the port parameter is 21. For SFTP, the default value is

22.

View the updated settings by entering the transfer upload start command. Answer y when prompted to confirm the current settings and start the upload process.

Reboot the controller by entering the reset system command.

Generating a Certificate Signing Request

Step 1

Step 2

Install and open the OpenSSL application.

Enter the command:

OpenSSL>

req -new -newkey rsa:1024 -nodes -keyout mykey.pem -out myreq.pem

Controllers support a maximum key size of 2048 bits.

Note

You must provide the correct Common Name. Ensure that the host name that is used to create the certificate

(Common Name) matches the Domain Name System (DNS) host name entry for the virtual interface IP on the controller. This name should exist in the DNS as well. Also, after you make the change to the VIP interface, you must reboot the system in order for this change to take effect.

After you issue the command, you are prompted to enter information such as country name, state, city, and so on.

Cisco Wireless Controller Configuration Guide, Release 8.3

133

Generating a Certificate Signing Request

Step 3

Step 4

Information similar to the following appears:

OpenSSL>

req -new -newkey rsa:1024 -nodes -keyout mykey.pem -out myreq.pem

Loading 'screen' into random state - done

Generating a 1024 bit RSA private key

................................................................++++++

...................................................++++++ writing new private key to 'mykey.pem'

-----

You are about to be asked to enter information that will be incorporated into your certificate request.

What you are about to enter is what is called a Distinguished Name or a DN.

There are quite a few fields but you can leave some blank

For some fields there will be a default value,

If you enter '.', the field will be left blank.

-----

Country Name (2 letter code) [AU]:US

State or Province Name (full name) [Some-State]:CA

Locality Name (eg, city) []:San Jose

Organization Name (eg, company) [Internet Widgits Pty Ltd]:ABC

Organizational Unit Name (eg, section) []:CDE

Common Name (eg, YOUR name) []:XYZ.ABC

Email Address []:[email protected]

Please enter the following 'extra' attributes to be sent with your certificate request

A challenge password []:Test123

An optional company name []:

OpenSSL>

After you provide all the required details two files are generated:

• A new private key that includes the name mykey.pem

• A CSR that includes the name myreq.pem

Copy and paste the Certificate Signing Request (CSR) information into any CA enrollment tool. After you submit the

CSR to a third party CA, the third party CA digitally signs the certificate and sends back the signed certificate chain through e-mail. In case of chained certificates, you receive the entire chain of certificates from the CA. If you only have one intermediate certificate similar to the example above, you will receive the following three certificates from the CA:

• Root certificate.pem

• Intermediate certificate.pem

• Device certificate.pem

Note

Ensure that the certificate is Apache-compatible with SHA1 encryption.

Once you have all the three certificates, copy and paste into another file the contents of each .pem file in this order:

------BEGIN CERTIFICATE------

*Device cert*

------END CERTIFICATE------

------BEGIN CERTIFICATE------

*Intermediate CA cert *

------END CERTIFICATE--------

------BEGIN CERTIFICATE------

*Root CA cert *

134

Cisco Wireless Controller Configuration Guide, Release 8.3

Generating a Certificate Signing Request

Step 5

Step 6

Step 7

------END CERTIFICATE------

Save the file as All-certs.pem.

Combine the All-certs.pem certificate with the private key that you generated along with the CSR (the private key of the device certificate, which is mykey.pem in this example), and save the file as final.pem.

Create the All-certs.pem and final.pem files by entering these commands: openssl>

pkcs12 -export -in All-certs.pem -inkey mykey.pem

-out All-certs.p12 -clcerts -passin pass:check123

-passout pass:check123

openssl>

pkcs12 -in All-certs.p12 -out final.pem

-passin pass:check123 -passout pass:check123

final.pem is the file that we need to download to the controller.

Note

You must enter a password for the parameters -passin and -passout. The password that is configured for the

-passout parameter must match the certpassword parameter that is configured on the controller. In the above example, the password that is configured for both the -passin and -passout parameters is check123.

What to Do Next

Download the final.pem file to the controller either using CLI or GUI.

Downloading Third-Party Certificate (GUI)

Step 1

Step 2

Step 3

Step 4

Step 5

Step 6

Step 7

Step 8

Step 9

Step 10

Copy the device certificate final.pem to the default directory on your TFTP server.

Choose Security > Web Auth > Certificate to open the Web Authentication Certificate page.

Check the Download SSL Certificate check box to view the Download SSL Certificate From Server parameters.

In the Server IP Address text box, enter the IP address of the TFTP server.

In the File Path text box, enter the directory path of the certificate.

In the File Name text box, enter the name of the certificate.

In the Certificate Password text box, enter the password to protect the certificate.

Click Apply.

After the download is complete, choose Commands > Reboot and click Save and Reboot.

Click OK in order to confirm your decision to reboot the controller.

Cisco Wireless Controller Configuration Guide, Release 8.3

135

Generating a Certificate Signing Request

Downloading Third-Party Certificate (CLI)

Step 1

Step 2

Step 3

Step 4

Move the final.pem file to the default directory on your TFTP server. Change the download settings by entering the following commands:

(Cisco Controller) >

transfer download mode tftp

(Cisco Controller) >

transfer download datatype webauthcert

(Cisco Controller) >

transfer download serverip <TFTP server IP address>

(Cisco Controller) >

transfer download path <absolute TFTP server path to the update file>

(Cisco Controller) >

transfer download filename final.pem

Enter the password for the .pem file so that the operating system can decrypt the SSL key and certificate.

(Cisco Controller) >

transfer download certpassword password

Note

Ensure that the value for certpassword is the same as the -passout parameter when you generate a

CSR.

Start the certificate and key download by entering the this command:

transfer download start

Example:

(Cisco Controller) >

transfer download start

Mode............................................. TFTP

Data Type........................................ Site Cert

TFTP Server IP................................... 10.77.244.196

TFTP Packet Timeout.............................. 6

TFTP Max Retries................................. 10

TFTP Path........................................./

TFTP Filename.................................... final.pem

This may take some time.

Are you sure you want to start? (y/N)

TFTP EAP Dev cert transfer starting.

Certificate installed.

Reboot the switch to use new certificate.

Reboot the controller.

136

Cisco Wireless Controller Configuration Guide, Release 8.3

C H A P T E R

AAA Administration

•

Setting up RADIUS, page 137

•

Setting up TACACS+, page 162

•

Maximum Local Database Entries, page 172

•

Information About Configuring Maximum Local Database Entries, page 172

•

Configuring Maximum Local Database Entries (GUI), page 173

•

Configuring Maximum Local Database Entries (CLI), page 173

Setting up RADIUS

Information About RADIUS

Remote Authentication Dial-In User Service (RADIUS) is a client/server protocol that provides centralized security for users attempting to gain management access to a network. It serves as a backend database similar to local and TACACS+ and provides authentication and accounting services:

• Authentication—The process of verifying users when they attempt to log into the controller.

Users must enter a valid username and password in order for the controller to authenticate users to the

RADIUS server. If multiple databases are configured, you can specify the sequence in which the backend database must be tired.

• Accounting—The process of recording user actions and changes.

Whenever a user successfully executes an action, the RADIUS accounting server logs the changed attributes, the user ID of the person who made the change, the remote host where the user is logged in, the date and time when the command was executed, the authorization level of the user, and a description of the action performed and the values provided. If the RADIUS accounting server becomes unreachable, users are able to continue their sessions uninterrupted.

RADIUS uses User Datagram Protocol (UDP) for its transport. It maintains a database and listens on UDP port 1812 for incoming authentication requests and UDP port 1813 for incoming accounting requests. The controller, which requires access control, acts as the client and requests AAA services from the server. The

Cisco Wireless Controller Configuration Guide, Release 8.3

137

Setting up RADIUS

traffic between the controller and the server is encrypted by an algorithm defined in the protocol and a shared secret key configured on both devices.

You can configure multiple RADIUS accounting and authentication servers. For example, you may want to have one central RADIUS authentication server but several RADIUS accounting servers in different regions.

If you configure multiple servers of the same type and the first one fails or becomes unreachable, the controller automatically tries the second one, then the third one if necessary, and so on.

When a management user is authenticated using a RADIUS server, only the PAP protocol is used. For web authentication users, PAP, MSCHAPv2 and MD5 security mechanisms are supported.

RADIUS Server Support

• You can configure up to 17 RADIUS authentication and accounting servers each.

• If multiple RADIUS servers are configured for redundancy, the user database must be identical in all the servers for the backup to work properly.

• One Time Passwords (OTPs) are supported on the controller using RADIUS. In this configuration, the controller acts as a transparent passthrough device. The controller forwards all client requests to the

RADIUS server without inspecting the client behavior. When using OTP, the client must establish a single connection to the controller to function properly. The controller currently does not have any intelligence or checks to correct a client that is trying to establish multiple connections.

• To create a read-only controller user on the RADIUS sever, you must set the service type to NAS prompt instead of Callback NAS prompt. If you set the service type to Callback NAS Prompt, the user authentication fails while setting it to NAS prompt gives the user read-only access to the controller.

Also, the Callback Administrative service type gives the user the lobby ambassador privileges to the controller.

• If RADIUS servers are mapped per WLAN, then controller do not use RADIUS server from the global list on that WLAN.

• To configure the RADIUS server:

• Using Access Control Server (ACS)—See the latest Cisco Secure Access Control System guide at http://www.cisco.com/c/en/us/support/security/secure-access-control-system/ products-user-guide-list.html

• Using Identity Services Engine (ISE)—See the Configuring External RADIUS Servers section in the Cisco Identity Services Engine Administrator Guide at http://www.cisco.com/c/en/us/support/ security/identity-services-engine/products-installation-and-configuration-guides-list.html

Primary and Fallback RADIUS Servers

The primary RADIUS server (the server with the lowest server index) is assumed to be the most preferable server for the controller. If the primary server becomes unresponsive, the controller switches to the next active backup server (the server with the next lowest server index). The controller continues to use this backup server, unless you configure the controller to fall back to the primary RADIUS server when it recovers and becomes responsive or to a more preferable server from the available backup servers.

138

Cisco Wireless Controller Configuration Guide, Release 8.3

Setting up RADIUS

RADIUS DNS

You can use a fully qualified domain name (FQDN) that enables you to change the IP address when needed, for example, for load balancing updates. A submenu, DNS, is added to the Security > AAA > RADIUS menu, which you can use to get RADIUS IP information from a DNS. The DNS query is disabled by default.

Restrictions on Configuring RADIUS

• You can configure the session timeout value for RADIUS server up to 65535 seconds. The controller does not support configuring session timeout value for RADIUS server higher than 65535 seconds.

• The session timeout value configured on RADIUS server if set beyond 24 days, then the RADIUS session timeout value does not override the session timeout value configured locally over a WLAN.

Configuring RADIUS on the ACS

Step 1

Step 2

Choose Network Configuration on the ACS main page.

Choose Add Entry under AAA Clients to add your controller to the server. The Add AAA Client page appears.

Figure 16: Add AAA Client Page on CiscoSecure ACS

Cisco Wireless Controller Configuration Guide, Release 8.3

139

Setting up RADIUS

Step 3

Step 4

Step 5

Step 6

Step 7

Step 8

Step 9

Step 10

Step 11

Step 12

Step 13

Step 14

Step 15

Step 16

Step 17

Step 18

Step 19

Step 20

In the AAA Client Hostname text box, enter the name of your controller.

In the AAA Client IP Address text box, enter the IP address of your controller.

In the Shared Secret text box, enter the shared secret key to be used for authentication between the server and the controller.

Note

The shared secret key must be the same on both the server and the controller.

From the Authenticate Using drop-down list, choose RADIUS (Cisco Airespace).

Click Submit + Apply to save your changes.

Choose Interface Configuration on the ACS main page.

Choose RADIUS (Cisco Aironet). The RADIUS (Cisco Aironet) page appears.

Under User Group, select the Cisco-Aironet-Session-Timeout check box.

Click Submit to save your changes.

On the ACS main page, from the left navigation pane, choose System Configuration.

Choose Logging.

When the Logging Configuration page appears, enable all of the events that you want to be logged and save your changes.

On the ACS main page, from the left navigation pane, choose Group Setup.

Choose a previously created group from the Group drop-down list.

Note

This step assumes that you have already assigned users to groups on the ACS according to the roles to which they will be assigned.

Click Edit Settings. The Group Setup page appears.

Under Cisco Aironet Attributes, select the Cisco-Aironet-Session-Timeout check box and enter a session timeout value in the edit box.

Specify read-only or read-write access to controllers through RADIUS authentication, by setting the Service-Type attribute (006) to Callback NAS Prompt for read-only access or to Administrative for read-write privileges. If you do not set this attribute, the authentication process completes successfully (without an authorization error on the controller), but you might be prompted to authenticate again.

Note

If you set the Service-Type attribute on the ACS, make sure to select the Management check box on the RADIUS

Authentication Servers page of the controller GUI.

Click Submit to save your changes.

Configuring RADIUS (GUI)

Step 1

Step 2

Choose Security > AAA > RADIUS.

Perform one of the following:

• If you want to configure a RADIUS server for authentication, choose Authentication.

• If you want to configure a RADIUS server for accounting, choose Accounting.

140

Cisco Wireless Controller Configuration Guide, Release 8.3

Setting up RADIUS

Step 3

Step 4

Note

The pages used to configure authentication and accounting contain mostly the same text boxes. Therefore, these instructions walk through the configuration only once, using the Authentication pages as examples. You would follow the same steps to configure multiple services and/or multiple servers.

The RADIUS Authentication (or Accounting) Servers page appears.

This page lists any RADIUS servers that have already been configured.

• If you want to delete an existing server, hover your cursor over the blue drop-down arrow for that server and choose

Remove.

• If you want to make sure that the controller can reach a particular server, hover your cursor over the blue drop-down arrow for that server and choose Ping.

From the Acct Call Station ID Type drop-down list, choose the option that is sent to the RADIUS server in the

Access-Request message. The following options are available:

• IP Address

• System MAC Address

• AP MAC Address

• AP MAC Address:SSID

• AP Name:SSID

• AP Name

• AP Group

• Flex Group

• AP Location

• VLAN ID

• AP Ethernet MAC Address

• AP Ethernet MAC Address:SSID

Note

The AP Name:SSID, AP Name, AP Group, Flex Group, AP Location, and VLAN ID options are added in the

7.4 release.

The AP Ethernet MAC Address and AP Ethernet MAC Address:SSID are added in the 7.6 release.

From the Auth Call Station ID Type drop-down list, choose the option that is sent to the RADIUS server in the

Access-Request message. The following options are available:

• IP Address

• System MAC Address

• AP MAC Address

• AP MAC Address:SSID

• AP Name:SSID

• AP Name

• AP Group

Cisco Wireless Controller Configuration Guide, Release 8.3

141

Setting up RADIUS

Step 5

Step 6

Step 7

Step 8

Step 9

Step 10

Step 11

Step 12

• Flex Group

• AP Location

• VLAN ID

• AP Ethernet MAC Address

• AP Ethernet MAC Address:SSID

Enable RADIUS-to-controller key transport using AES key wrap protection by checking the Use AES Key Wrap check box. The default value is unchecked. This feature is required for FIPS customers.

From the MAC Delimiter drop-down list, choose the option that is sent to the RADIUS server in the Access-Request message. The following options are available:

• Colon

• Hyphen

• Single-hyphen

• None

Click Apply. Perform one of the following:

• To edit an existing RADIUS server, click the server index number for that server. The RADIUS Authentication

(or Accounting) Servers > Edit page appears.

• To add a RADIUS server, click New. The RADIUS Authentication (or Accounting) Servers > New page appears.

If you are adding a new server, choose a number from the Server Index (Priority) drop-down list to specify the priority order of this server in relation to any other configured RADIUS servers providing the same service.

If you are adding a new server, enter the IP address of the RADIUS server in the Server IP Address text box.

Note

Auto IPv6 is not supported on RADIUS server. The RADIUS server must not be configured with Auto IPv6 address. Use fixed IPv6 address instead.

From the Shared Secret Format drop-down list, choose ASCII or Hex to specify the format of the shared secret key to be used between the controller and the RADIUS server. The default value is ASCII.

In the Shared Secret and Confirm Shared Secret text boxes, enter the shared secret key to be used for authentication between the controller and the server.

Note

The shared secret key must be the same on both the server and the controller.

If you are configuring a new RADIUS authentication server and want to enable AES key wrap, which makes the shared secret between the controller and the RADIUS server more secure, follow these steps:

Note

AES key wrap is designed for Federal Information Processing Standards (FIPS) customers and requires a key-wrap compliant RADIUS authentication server.

a) Check the Key Wrap check box.

b) From the Key Wrap Format drop-down list, choose ASCII or HEX to specify the format of the AES key wrap keys: Key Encryption Key (KEK) and Message Authentication Code Key (MACK).

c) In the Key Encryption Key (KEK) text box, enter the 16-byte KEK.

142

Cisco Wireless Controller Configuration Guide, Release 8.3

Setting up RADIUS

Step 13

Step 14

Step 15

Step 16

Step 17

Step 18

Step 19

Step 20

Step 21

Step 22

d) In the Message Authentication Code Key (MACK) text box, enter the 20-byte KEK.

If you are adding a new server, enter the RADIUS server’s UDP port number for the interface protocols in the Port

Number text box. The valid range is 1 to 65535, and the default value is 1812 for authentication and 1813 for accounting.

From the Server Status text box, choose Enabled to enable this RADIUS server or choose Disabled to disable it. The default value is enabled.

If you are configuring a new RADIUS authentication server, from the Support for CoA drop-down list, choose Enabled to enable change of authorization, which is an extension to the RADIUS protocol that allows dynamic changes to a user session, or choose Disabled to disable this feature. By default, this is set to Disabled state. Support for CoA includes support for disconnecting users and changing authorizations applicable to a user session and supports disconnect and change of authorization (CoA) messages. Disconnect messages cause a user session to be terminated immediately where

CoA messages modify session authorization attributes such as data filters.

In the Server Timeout text box, enter the number of seconds between retransmissions. The valid range is 2 to 30 seconds, and the default value is 2 seconds.

Check the Key Wrap check box.

Note

We recommend that you increase the timeout value if you experience repeated reauthentication attempts or the controller falls back to the backup server when the primary server is active and reachable.

Check the Network User check box to enable network user authentication (or accounting), or uncheck it to disable this feature. The default value is unchecked. If you enable this feature, this entry is considered the RADIUS authentication

(or accounting) server for network users. If you did not configure a RADIUS server entry on the WLAN, you must enable this option for network users.

If you are configuring a RADIUS authentication server, check the Management check box to enable management authentication, or uncheck the check box to disable this feature. The default value is checked. If you enable this feature, this entry is considered the RADIUS authentication server for management users, and authentication requests go to the

RADIUS server.

Enter the Management Retransmit Timeout value, which denotes the network login retransmission timeout for the server.

If you want to use a tunnel gateway as AAA proxy, check the Tunnel Proxy check box. The gateway can function as a proxy RADIUS server as well as a tunnel gateway.

Check the IPSec check box to enable the IP security mechanism, or uncheck the check box to disable this feature. The default value is unchecked.

Note

From Release 8.3 onwards, IPSec is supported over IPv6 interfaces as well.

If you enabled IPsec in Step 17, follow these steps to configure additional IPsec parameters: a) From the IPSec drop-down list, choose one of the following options as the authentication protocol to be used for IP security: HMAC MD5 or HMAC SHA1. The default value is HMAC SHA1.

A message authentication code (MAC) is used between two parties that share a secret key to validate information transmitted between them. HMAC (Hash MAC) is based on cryptographic hash functions. It can be used in combination with any iterated cryptographic hash function. HMAC MD5 and HMAC SHA1 are two constructs of the HMAC using the MD5 hash function and the SHA1 hash function. HMAC also uses a secret key for calculation and verification of the message authentication values.

b) From the IPSec Encryption drop-down list, choose one of the following options to specify the IP security encryption mechanism:

• DES—Data Encryption Standard that is a method of data encryption using a private (secret) key. DES applies a 56-bit key to each 64-bit block of data.

• 3DES—Data Encryption Standard that applies three keys in succession. This is the default value.

Cisco Wireless Controller Configuration Guide, Release 8.3

143

Setting up RADIUS

Step 23

Step 24

Step 25

Step 26

• AES CBC—Advanced Encryption Standard that uses keys with a length of 128, 192, or 256 bits to encrypt data blocks with a length of 128, 192, or 256 bits. AES 128 CBC uses a 128-bit data path in Cipher Block

Chaining (CBC) mode.

• 256-AES—Advanced Encryption Standard that uses keys with a length of 256 bits.

c) From the IKE Phase 1 drop-down list, choose one of the following options to specify the Internet Key Exchange

(IKE) protocol: Aggressive or Main. The default value is Aggressive.

IKE Phase 1 is used to negotiate how IKE should be protected. Aggressive mode passes more information in fewer packets with the benefit of slightly faster connection establishment at the cost of transmitting the identities of the security gateways in the clear.

d) In the Lifetime text box, enter a value (in seconds) to specify the timeout interval for the session. The valid range is

1800 to 57600 seconds, and the default value is 1800 seconds.

e) From the IKE Diffie Hellman Group drop-down list, choose one of the following options to specify the IKE Diffie

Hellman group: Group 1 (768 bits), Group 2 (1024 bits), or Group 5 (1536 bits). The default value is Group 1

(768 bits).

Diffie-Hellman techniques are used by two devices to generate a symmetric key through which they can publicly exchange values and generate the same symmetric key. Although all three groups provide security from conventional attacks, Group 5 is considered more secure because of its larger key size. However, computations involving Group

1 and Group 2 based keys might occur slightly faster because of their smaller prime number size.

Note

If the shared secret for IPSec is not configured, the default radius shared secret is used. If the authentication method is PSK, WLANCC should be enabled to use the IPSec shared secret, default value is used otherwise.

You can view the status for the WLANCC and UCAPL prerequisite modes in Controller > Inventory.

Click Apply.

Click Save Configuration.

Repeat the previous steps if you want to configure any additional services on the same server or any additional RADIUS servers.

Specify the RADIUS server fallback behavior, as follows: a) Choose Security > AAA > RADIUS > Fallback to open the RADIUS > Fallback Parameters to open the fallback parameters page.

b) From the Fallback Mode drop-down list, choose one of the following options:

• Off—Disables RADIUS server fallback. This is the default value.

• Passive—Causes the controller to revert to a server with a lower priority from the available backup servers without using extraneous probe messages. The controller ignores all inactive servers for a time period and retries later when a RADIUS message needs to be sent.

• Active—Causes the controller to revert to a server with a lower priority from the available backup servers by using RADIUS probe messages to proactively determine whether a server that has been marked inactive is back online. The controller ignores all inactive servers for all active RADIUS requests. Once the primary server receives a response from the recovered ACS server, the active fallback RADIUS server no longer sends probe messages to the server requesting the active probe authentication.

c) If you enabled Active fallback mode in Step b, enter the name to be sent in the inactive server probes in the Username text box. You can enter up to 16 alphanumeric characters. The default value is “cisco-probe.”

144

Cisco Wireless Controller Configuration Guide, Release 8.3

Setting up RADIUS

Step 27

Step 28

Step 29

Step 30

Step 31

d) If you enabled Active fallback mode in Step b, enter the probe interval value (in seconds) in the Interval in Sec text box. The interval serves as inactive time in passive mode and probe interval in active mode. The valid range is 180 to 3600 seconds, and the default value is 300 seconds.

Specify the RADIUS DNS parameters as follows:

Note

IPv6 is not supported for RADIUS

DNS.

a) Choose Security > AAA > RADIUS > DNS. The RADIUS DNS Parameters page appears.

b) Check or uncheck the DNS Query check box.

c) In the Port Number text box, enter the authentication port number. The valid range is 1 to 65535.

The accounting port number is an increment of 1 of the authentication port number. For example, if you define the authentication port number as 1812, the accounting port number is 1813. The accounting port number is always derived from the authentication port number.

d) From the Secret Format drop-down list, choose the format in which you want to configure the secret. Valid options are ASCII and Hex.

e) Depending on the format selected, enter and confirm the secret.

Note

All servers are expected to use the same authentication port and the same secret.

f) In the DNS Timeout text box, enter the number of days after which the DNS query is refreshed to get the latest update from the DNS server.

g) In the URL text box, enter the fully qualified domain name or the absolute domain name of the RADIUS server.

h) In the Server IP Address text box, enter the IP address of the DNS server.

i) Click Apply.

Specify the order of authentication when multiple databases are configured by choosing Security > Priority Order >

Management User. The Priority Order > Management User page appears.

In the Order Used for Authentication text box, specify which servers have priority when the controller attempts to authenticate management users. Use the > and < buttons to move servers between the Not Used and Order Used for

Authentication text boxes. After the desired servers appear in the Order Used for Authentication text box, use the Up and Down buttons to move the priority server to the top of the list.

By default, the local database is always queried first. If the username is not found, the controller switches to the RADIUS server if configured for RADIUS or to the TACACS+ server if configured for TACACS+. The default setting is local and then RADIUS.

Click Apply.

Click Save Configuration.

Configuring RADIUS (CLI)

• Specify whether the IP address, system MAC address, AP MAC address, AP Ethernet MAC address of the originator will be sent to the RADIUS server in the Access-Request message by entering this command:

config radius callStationIdType {ipaddr | macaddr | ap-macaddr-only | ap-macaddr-ssid |

ap-location | ap-mac-ssid-ap-group | ap-name | ap-name-ssid | flex-group-name | vlan-id}

This command supports both IPv4 and IPv6 address formats.

Cisco Wireless Controller Configuration Guide, Release 8.3

145

Setting up RADIUS

Note

The default is System MAC Address.

Caution

Do not use Call Station ID Type for IPv6-only clients.

• Specify the delimiter to be used in the MAC addresses that are sent to the RADIUS authentication or accounting server in Access-Request messages by entering this command:

config radius {auth | acct} mac-delimiter {colon | hyphen | single-hyphen | none} where

• colon sets the delimiter to a colon (the format is xx:xx:xx:xx:xx:xx).

• hyphen sets the delimiter to a hyphen (the format is xx-xx-xx-xx-xx-xx). This is the default value.

• single-hyphen sets the delimiter to a single hyphen (the format is xxxxxx-xxxxxx).

• none disables delimiters (the format is xxxxxxxxxxxx).

• Configure a RADIUS authentication server by entering these commands:

• config radius auth add index server_ip_address port_number {ascii | hex} shared_secret—Adds a RADIUS authentication server.

This command supports both IPv4 and IPv6 address formats.

• config radius auth keywrap {enable | disable}—Enables AES key wrap, which makes the shared secret between the controller and the RADIUS server more secure. AES key wrap is designed for

Federal Information Processing Standards (FIPS) customers and requires a key-wrap compliant

RADIUS authentication server.

• config radius auth keywrap add {ascii | hex} kek mack index—Configures the AES key wrap attributes where

◦kek specifies the 16-byte Key Encryption Key (KEK).

◦mack specifies the 20-byte Message Authentication Code Key (MACK).

◦index specifies the index of the RADIUS authentication server on which to configure the

AES key wrap.

• config radius auth rfc3576 {enable | disable} index—Enables or disables RFC 3576, which is an extension to the RADIUS protocol that allows dynamic changes to a user session. RFC 3576 includes support for disconnecting users and changing authorizations applicable to a user session and supports disconnect and change-of-authorization (CoA) messages. Disconnect messages cause a user session to be terminated immediately where CoA messages modify session authorization attributes such as data filters.

• config radius auth retransmit-timeout index timeout—Configures the retransmission timeout value for a RADIUS authentication server.

• config radius auth mgmt-retransmit-timeout index timeout—Configures the default management login retransmission timeout for a RADIUS authentication server.

146

Cisco Wireless Controller Configuration Guide, Release 8.3

Setting up RADIUS

• config radius auth network index {enable | disable}—Enables or disables network user authentication. If you enable this feature, this entry is considered the RADIUS authentication server for network users. If you did not configure a RADIUS server entry on the WLAN, you must enable this option for network users.

• config radius auth management index {enable | disable}—Enables or disables management authentication. If you enable this feature, this entry is considered the RADIUS authentication server for management users, and authentication requests go to the RADIUS server.

• config radius auth ipsec {enable | disable} index—Enables or disables the IP security mechanism.

• config radius auth ipsec authentication {hmac-md5 | hmac-sha1} index—Configures the authentication protocol to be used for IP security.

• config radius auth ipsec encryption {256-aes | 3des | aes | des | none} index—Configures the

IP security encryption mechanism.

• config radius auth ipsec ike dh-group {group-1 | group-2 | group-5| 2048bit-group-14}

index—Configures the IKE Diffie-Hellman group.

• config radius auth ipsec ike lifetime interval index—Configures the timeout interval for the session.

• config radius auth ipsec ike phase1{aggressive | main} index—Configures the Internet Key

Exchange (IKE) protocol.

• config radius auth ipsec ike auth-method {PSK | certificate} index—Configures the IKE authentication methods. By default PSK is be used for IPSEC sessions.

• config radius auth ipsec ike auth-mode pre-shared-key index hex/asciisecret—Configures the

IPSEC pre-shared key.

• config radius auth ipsec ike auth-mode {pre-shared-key index hex-ascii-index shared-secret |

certificate index} —Configures the IKE authentication method. By default, preshared key is used for IPSEC sessions.

• config radius auth {enable | disable} index—Enables or disables a RADIUS authentication server.

• config radius auth delete index—Deletes a previously added RADIUS authentication server.

• Configure a RADIUS accounting server by entering these commands:

• config radius acct add index server_ip_address port# {ascii | hex} shared_secret—Adds a

RADIUS accounting server.

This command supports both IPv4 and IPv6 address formats.

• config radius acct server-timeout index timeout—Configures the retransmission timeout value for a RADIUS accounting server.

• config radius acct network index {enable | disable}—Enables or disables network user accounting.

If you enable this feature, this entry is considered the RADIUS accounting server for network users. If you did not configure a RADIUS server entry on the WLAN, you must enable this option for network users.

• config radius acct ipsec {enable | disable} index—Enables or disables the IP security mechanism.

• config radius acct ipsec authentication {hmac-md5 | hmac-sha1} index—Configures the authentication protocol to be used for IP security.

Cisco Wireless Controller Configuration Guide, Release 8.3

147

Setting up RADIUS

• config radius acct ipsec encryption {256-aes | 3des | aes | des | none} index—Configures the

IP security encryption mechanism.

• config radius acct ipsec ike dh-group {2048bit-group-14 | group-1 | group-2 | group-5}

index—Configures the IKE Diffie Hellman group.

• config radius acct ipsec ike lifetime interval index—Configures the timeout interval for the session.

• config radius acct ipsec ike auth-mode {pre-shared-key index hex-ascii-index shared-secret |

certificate index} —Configures the IKE authentication method. By default, preshared key is used for IPSEC sessions.

• config radius acct ipsec ike phase1{aggressive | main} index—Configures the Internet Key

Exchange (IKE) protocol.

• config radius acct {enable | disable} index—Enables or disables a RADIUS accounting server.

• config radius acct delete index—Deletes a previously added RADIUS accounting server.

• config radius acct region {group | none | provincial}—Configures the RADIUS region.

• config radius acct realm {add | delete } radius-index realm-string—Configures the realm of the

RADIUS accounting server.

• config radius auth callStationIdType {ap-ethmac-only | ap-ethmac-ssid}—Sets the Called

Station ID type to be AP’s radio MAC address or AP’s radio MAC address with SSID.

• config radius auth callStationIdType ap-label-address—Sets the Called Station ID Type to the

AP MAC address that is printed on the AP label, for the authentication messages.

config radius auth callStationIdType ap-label-address-ssid—Sets the Call Station ID Type to the <AP label MAC address>:<SSID> format, for the authentication messages.

• config radius auth callStationIdType ap-group-name —Sets the Called Station ID type to use the AP group name. If the AP is not part of any AP group, default-group is taken as the AP group name.

• config radius auth callStationIdType ap-location—Sets the Called Station ID to the AP Location.

• config radius auth callStationIdType ap-mac-ssid-ap-group—Sets Called Station ID type to the format <AP MAC address>:<SSID>:<AP Group>.

• config radius auth callStationIdType {ap-macaddr-only | ap-macaddr-ssid}—Sets the Called

Station ID type to be AP’s radio MAC address or AP’s radio MAC address with SSID in the <AP radio MAC address>:<SSID> format.

• config radius auth callStationIdType {ap-name | ap-name-ssid}—Sets the Called Station ID type to be AP name or AP name with SSID in the <AP name>:<SSID> format.

Note

When the Called Station ID type is set to AP name, the conversion of uppercase letters to lowercase letters for the AP name is not considered. For example, while creating an

AP, if the AP name is provided with uppercase letters, then the AP name for the call station ID type gets displayed with upper case letters only.

• config radius auth callStationIdType flex-group-name—Sets the Called Station ID type to the

FlexConnect group name.

148

Cisco Wireless Controller Configuration Guide, Release 8.3

Setting up RADIUS

• config radius auth callStationIdType {ipaddr | macaddr}—Sets the Called Station ID type to use the IP address (only Layer 3) or system's MAC address.

• config radius auth callStationIdType vlan-id—Sets the Called Station ID type to the system's

VLAN ID.

• Configure the RADIUS server fallback behavior by entering this command:

config radius fallback-test mode {off | passive | active}

where

• off disables RADIUS server fallback.

• passive causes the controller to revert to a server with a lower priority from the available backup servers without using extraneous probe messages. The controller simply ignores all inactive servers for a time period and retries later when a RADIUS message needs to be sent.

• active causes the controller to revert to a server with a lower priority from the available backup servers by using RADIUS probe messages to proactively determine whether a server that has been marked inactive is back online. The controller simply ignores all inactive servers for all active

RADIUS requests. Once the primary server receives a response from the recovered ACS server, the active fallback RADIUS server no longer sends probe messages to the server requesting the active probe authentication.

• If you enabled Active mode in Step 5, enter these commands to configure additional fallback parameters:

• config radius fallback-test username username—Specifies the name to be sent in the inactive server probes. You can enter up to 16 alphanumeric characters for the username parameter.

• config radius fallback-test interval interval—Specifies the probe interval value (in seconds).

• Configure RADIUS DNS parameters by entering these commands:

• config radius dns global port-num {ascii | hex} secret—Adds global port number and secret information for the RADIUS DNS.

• config radius dns query url timeout-in-days—Configures the FQDN of the RADIUS server and timeout after which a refresh is performed to get the latest update from the DNS server.

• config radius dns serverip ip-addr—Configures the IP address of the DNS server.

• config radius dns {enable | disable}—Enables or disables the DNS query.

• Configure RADIUS extended source ports support by entering this command:

config radius ext-source-ports {enable | disable}

Enabling multiple source ports allows the number of outstanding RADIUS requests to be increased.

With single source port, the number of outstanding requests was limited to 255 for each authentication and accounting request.

The number of RADIUS queues supported on various WLC platforms:

• 5508 and WiSM2 support 8 RADIUS queues

• 5520, Flex 7500 Series, and 8500 Series support 16 RADIUS queues

• Save your changes by entering this command:

save config

Cisco Wireless Controller Configuration Guide, Release 8.3

149

Setting up RADIUS

• Configure the order of authentication when multiple databases are configured by entering this command:

config aaa auth mgmt AAA_server_type AAA_server_type where AAA_server_type is local, radius, or tacacs.

To see the current management authentication server order, enter the show aaa auth command.

• See RADIUS statistics by entering these commands:

• show radius summary—Shows a summary of RADIUS servers and statistics with AP Ethernet

MAC configurations.

• show radius auth statistics—Shows the RADIUS authentication server statistics.

• show radius acct statistics—Shows the RADIUS accounting server statistics.

• show radius rfc3576 statistics—Shows a summary of the RADIUS RFC-3576 server.

• See active security associations by entering these commands:

• show ike {brief | detailed} ip_or_mac_addr—Shows a brief or detailed summary of active IKE security associations.

• show ipsec {brief | detailed} ip_or_mac_addr—Shows a brief or detailed summary of active

IPSec security associations.

• Clear the statistics for one or more RADIUS servers by entering this command:

clear stats radius {auth | acct} {index | all}

• Make sure that the controller can reach the RADIUS server by entering this command:

ping server_ip_address

RADIUS Authentication Attributes Sent by the Controller

The following tables identify the RADIUS authentication attributes sent between the controller and the

RADIUS server in access-request and access-accept packets.

Table 3: Authentication Attributes Sent in Access-Request Packets

Attribute ID

Description

User-Name

Password

CHAP-Password

NAS-IP-Address

NAS-Port

Service-Type

Framed-MTU

Called-Station-ID (MAC address)

Calling-Station-ID (MAC address)

150

Cisco Wireless Controller Configuration Guide, Release 8.3

Setting up RADIUS

Attribute ID

Description

NAS-Identifier

Proxy-State

CHAP-Challenge

NAS-Port-Type

EAP-Message

1 To specify read-only or read-write access to controllers through RADIUS authentication, you must set the Service-Type attribute (6) on the RADIUS server to Callback NAS Prompt for read-only access or to Administrative for read-write privileges.

Table 4: Authentication Attributes Honored in Access-Accept Packets (Cisco)

Attribute ID

Description

Cisco-LEAP-Session-Key

Cisco-Keywrap-Msg-Auth-Code

Cisco-Keywrap-NonCE

Cisco-Keywrap-Key

Cisco-URL-Redirect

Cisco-URL-Redirect-ACL

Note

These Cisco-specific attributes are not supported: Auth-Algo-Type and SSID.

Table 5: Authentication Attributes Honored in Access-Accept Packets (Standard)

Attribute ID

Description

Service-Type. To specify read-only or read-write access to controllers through RADIUS authentication, you must set the Service-Type attribute

(6) on the RADIUS server to Callback NAS Prompt for read-only access or to Administrative for read-write privileges.

Framed-IP-Address

Class

Vendor-Specific

Timeout

Termination-Action

Acct-Status-Type

Cisco Wireless Controller Configuration Guide, Release 8.3

151

Setting up RADIUS

Attribute ID

Description

Tunnel-Type

EAP-Message

Tunnel-Group-ID

Note

Message authentication is not supported.

Table 7: Authentication Attributes Honored in Access-Accept Packets (Airespace)

Attribute ID

Description

VAP-ID

DSCP

8021P-Type

VLAN-Interface-Name

ACL-Name

Data-Bandwidth-Average-Contract

Real-Time-Bandwidth-Average-Contract

Data-Bandwidth-Burst-Contract

Real-Time-Bandwidth-Burst-Contract

Guest-Role-Name

Note

Guest-Role-Name is honored only on L3 security web authentication with AAA over-ride enabled on the Cisco WLC.

Data-Bandwidth-Average-Contract-US

Real-Time-Bandwidth-Average-Contract-US

152

Cisco Wireless Controller Configuration Guide, Release 8.3

Setting up RADIUS

Attribute ID

Description

Data-Bandwidth-Burst-Contract-US

Real-Time-Bandwidth-Burst-Contract-US

Authentication Attributes Honored in Access-Accept Packets (Airespace)

This section lists the RADIUS authentication Airespace attributes currently supported on the Cisco WLC.

VAP ID

This attribute indicates the WLAN ID of the WLAN to which the client should belong. When the WLAN-ID attribute is present in the RADIUS Access Accept, the system applies the WLAN-ID (SSID) to the client station after it authenticates. The WLAN ID is sent by the Cisco WLC in all instances of authentication except

IPsec. In case of web authentication, if the Cisco WLC receives a WLAN-ID attribute in the authentication response from the AAA server, and it does not match the ID of the WLAN, authentication is rejected. The

802.1X/MAC filtering is also rejected. The rejection, based on the response from the AAA server, is because of the SSID Cisco AVPair support. The fields are transmitted from left to right.

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Type | Length | Vendor-Id

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Vendor-Id (cont.) | Vendor type | Vendor length |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| WLAN ID (VALUE) |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

• Type – 26 for Vendor-Specific

• Length – 10

• Vendor-Id – 14179

• Vendor type – 1

• Vendor length – 4

• Value – ID of the WLAN to which the client should belong.

QoS-Level

This attribute indicates the QoS level to be applied to the mobile client's traffic within the switching fabric, as well as over the air. This example shows a summary of the QoS-Level Attribute format. The fields are transmitted from left to right.

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Type | Length | Vendor-Id

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Vendor-Id (cont.) | Vendor type | Vendor length |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| QoS Level |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Cisco Wireless Controller Configuration Guide, Release 8.3

153

Setting up RADIUS

• Type – 26 for Vendor-Specific

• Length – 10

• Vendor-Id – 14179

• Vendor type – 2

• Vendor length – 4

• Value – Three octets:

◦3 – Bronze (Background)

◦0 – Silver (Best Effort)

◦1 – Gold (Video)

◦2 – Platinum (Voice)

Differentiated Services Code Point (DSCP)

DSCP is a packet header code that can be used to provide differentiated services based on the QoS levels.

This attribute defines the DSCP value to be applied to a client. When present in a RADIUS Access Accept, the DSCP value overrides the DSCP value specified in the WLAN profile. The fields are transmitted from left to right.

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Type | Length | Vendor-Id

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Vendor-Id (cont.) | Vendor type | Vendor length |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| DSCP (VALUE) |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

• Type – 26 for Vendor-Specific

• Length – 10

• Vendor-Id – 14179

• Vendor type – 3

• Vendor length – 4

• Value – DSCP value to be applied for the client.

802.1p Tag Type

802.1p VLAN tag received from the client, defining the access priority. This tag maps to the QoS Level for client-to-network packets. This attribute defines the 802.1p priority to be applied to the client. When present in a RADIUS Access Accept, the 802.1p value overrides the default specified in the WLAN profile. The fields are transmitted from left to right.

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

154

Cisco Wireless Controller Configuration Guide, Release 8.3

Setting up RADIUS

| Type | Length | Vendor-Id

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Vendor-Id (cont.) | Vendor type | Vendor length |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| 802.1p (VALUE) |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

• Type – 26 for Vendor-Specific

• Length – 10

• Vendor-Id – 14179

• Vendor type – 4

• Vendor length – 3

• Value – 802.1p priority to be applied to a client.

VLAN Interface Name

This attribute indicates the VLAN interface a client is to be associated to. A summary of the Interface-Name

Attribute format is shown below. The fields are transmitted from left to right.

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Type | Length | Vendor-Id

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Vendor-Id (cont.) | Vendor type | Vendor length |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Interface Name...

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

• Type – 26 for Vendor-Specific

• Length – >7

• Vendor-Id – 14179

• Vendor type – 5

• Vendor length – >0

• Value – A string that includes the name of the interface the client is to be assigned to.

Note

This attribute only works when MAC filtering is enabled or if 802.1X or WPA is used as the security policy.

ACL-Name

This attribute indicates the ACL name to be applied to the client. A summary of the ACL-Name Attribute format is shown below. The fields are transmitted from left to right.

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Type | Length | Vendor-Id

Cisco Wireless Controller Configuration Guide, Release 8.3

155

Setting up RADIUS

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Vendor-Id (cont.) | Vendor type | Vendor length |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| ACL Name...

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

• Type – 26 for Vendor-Specific

• Length – >7

• Vendor-Id – 14179

• Vendor type – 6

• Vendor length – >0

• Value – A string that includes the name of the ACL to use for the client

Data Bandwidth Average Contract

This attribute is a rate limiting value. It indicates the Data Bandwidth Average Contract that will be applied for a client for non-realtime traffic such as TCP. This value is specific for downstream direction from wired to wireless. When present in a RADIUS Access Accept, the Data Bandwidth Average Contract value overrides the Average Data Rate value present in the WLAN or QoS Profile. The fields are transmitted from left to right.

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Type | Length | Vendor-Id

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Vendor-Id (cont.) | Vendor type | Vendor length |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Data Bandwidth Average Contract...

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

• Type – 26 for Vendor-Specific

• Length – 10

• Vendor-Id – 14179

• Vendor type – 7

• Vendor length – 4

• Value – A value in kbps

Real Time Bandwidth Average Contract

This attribute is a rate limiting value. It indicates the Data Bandwidth Average Contract that will be applied to a client for realtime traffic such as UDP. This value is specific for downstream direction from wired to wireless. When present in a RADIUS Access Accept, the Real Time Bandwidth Average Contract value overrides the Average Real-Time Rate value present in the WLAN or QoS Profile. The fields are transmitted from left to right.

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Type | Length | Vendor-Id

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Vendor-Id (cont.) | Vendor type | Vendor length |

156

Cisco Wireless Controller Configuration Guide, Release 8.3

Setting up RADIUS

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Real Time Bandwidth Average Contract...

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

• Type – 26 for Vendor-Specific

• Length – 10

• Vendor-Id – 14179

• Vendor type – 8

• Vendor length – 4

• Value – A value in kbps

Data Bandwidth Burst Contract

This attribute is a rate limiting value. It indicates the Data Bandwidth Burst Contract that will be applied to a client for non-realtime traffic such as TCP. This value is specific to downstream direction from wired to wireless. When present in a RADIUS Access Accept, the Data Bandwidth Burst Contract value overrides the

Burst Data Rate value present in the WLAN or QoS Profile. The fields are transmitted from left to right.

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Type | Length | Vendor-Id

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Vendor-Id (cont.) | Vendor type | Vendor length |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Data Bandwidth Burst Contract...

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

• Type – 26 for Vendor-Specific

• Length – 10

• Vendor-Id – 14179

• Vendor type – 9

• Vendor length – 4

• Value – A value in kbps

Real Time Bandwidth Burst Contract

This attribute is a rate limiting value. It indicates the Data Bandwidth Burst Contract that will be applied to a client for realtime traffic such as UDP. This value is specific to downstream direction from wired to wireless.

When present in a RADIUS Access Accept, the Real Time Bandwidth Burst Contract value overrides the

Burst Real-Time Rate value present in the WLAN or QoS Profile. The fields are transmitted from left to right.

Note

If you try to implement Average Data Rate and Burst Data Rate as AAA override parameters to be pushed from a AAA server, both Average Data Rate and Burst Data Rate have to be sent from ISE.

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Type | Length | Vendor-Id

Cisco Wireless Controller Configuration Guide, Release 8.3

157

Setting up RADIUS

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Vendor-Id (cont.) | Vendor type | Vendor length |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Real Time Bandwidth Burst Contract...

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

• Type – 26 for Vendor-Specific

• Length – 10

• Vendor-Id – 14179

• Vendor type – 10

• Vendor length – 4

• Value – A value in kbps

Guest Role Name

This attribute provides the bandwidth contract values to be applied for an authenticating user. When present in a RADIUS Access Accept, the bandwidth contract values defined for the Guest Role overrides the bandwidth contract values (based on QOS value) specified for the WLAN. The fields are transmitted from left to right.

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Type | Length | Vendor-Id

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Vendor-Id (cont.) | Vendor type | Vendor length |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| GuestRoleName ...

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

• Type – 26 for Vendor-Specific

• Length – 10

• Vendor-Id – 14179

• Vendor type – 11

• Vendor length – Variable based on the Guest Role Name length

• Value – A string of alphanumeric characters

Data Bandwidth Average Contract Upstream

This attribute is a rate limiting value. It indicates the Data Bandwidth Average Contract that will be applied to a client for non-realtime traffic such as TCP. This value is specific to upstream direction from wireless to wired. When present in a RADIUS Access Accept, the Data Bandwidth Average Contract value overrides the

Average Data Rate value present in the WLAN or QoS Profile. The fields are transmitted from left to right.

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Type | Length | Vendor-Id

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Vendor-Id (cont.) | Vendor type | Vendor length |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Data Bandwidth Average Contract Upstream...

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

158

Cisco Wireless Controller Configuration Guide, Release 8.3

Setting up RADIUS

• Type – 26 for Vendor-Specific

• Length – 10

• Vendor-Id – 14179

• Vendor type – 13

• Vendor length – 4

• Value – A value in kbps

Real Time Bandwidth Average Contract Upstream

This attribute is a rate limiting value. It indicates the Data Bandwidth Average Contract that will be applied to a client for realtime traffic such as UDP. This value is specific to upstream direction from wireless to wired.

When present in a RADIUS Access Accept, the Real Time Bandwidth Average Contract value overrides the

Average Real-Time Rate value present in the WLAN or QoS Profile. The fields are transmitted from left to right.

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Type | Length | Vendor-Id

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Vendor-Id (cont.) | Vendor type | Vendor length |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Real Time Bandwidth Average Contract Upstream...

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

• Type – 26 for Vendor-Specific

• Length – 10

• Vendor-Id – 14179

• Vendor type – 14

• Vendor length – 4

• Value – A value in kbps

Data Bandwidth Burst Contract Upstream

This attribute is a rate limiting value. It indicates the Data Bandwidth Burst Contract that will be applied to a client for non-realtime traffic such as TCP. This value is specific to upstream direction from wireless to wired. When present in a RADIUS Access Accept, the Data Bandwidth Burst Contract value overrides the

Burst Data Rate value present in the WLAN or QoS Profile. The fields are transmitted from left to right.

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Type | Length | Vendor-Id

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Vendor-Id (cont.) | Vendor type | Vendor length |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Data Bandwidth Burst Contract Upstream...

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

• Type – 26 for Vendor-Specific

• Length – 10

Cisco Wireless Controller Configuration Guide, Release 8.3

159

Setting up RADIUS

• Vendor-Id – 14179

• Vendor type – 15

• Vendor length – 4

• Value – A value in kbps

Real Time Bandwidth Burst Contract Upstream

This attribute is a rate limiting value. It indicates the Data Bandwidth Burst Contract that will be applied to a client for realtime traffic such as UDP. This value is specific to upstream direction from wireless to wired.

When present in a RADIUS Access Accept, the Real Time Bandwidth Burst Contract value overrides the

Burst Real-Time Rate value present in the WLAN or QoS Profile. The fields are transmitted from left to right.

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Type | Length | Vendor-Id

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Vendor-Id (cont.) | Vendor type | Vendor length |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Real Time Bandwidth Burst Contract Upstream...

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

• Type – 26 for Vendor-Specific

• Length – 10

• Vendor-Id – 14179

• Vendor type – 16

• Vendor length – 4

• Value – A value in kbps

RADIUS Accounting Attributes

This table identifies the RADIUS accounting attributes for accounting requests sent from a controller to the

RADIUS server.

Table 8: Accounting Attributes for Accounting Requests

Attribute ID

Description

User-Name

NAS-IP-Address

NAS-Port

Framed-IP-Address

Class

Called-Station-ID (MAC address)

Calling-Station-ID (MAC address)

160

Cisco Wireless Controller Configuration Guide, Release 8.3

Setting up RADIUS

Attribute ID

190

Description

NAS-Identifier

Accounting-Status-Type

Accounting-Delay-Time (Stop and interim messages only)

Accounting-Input-Octets (Stop and interim messages only)

Accounting-Output-Octets (Stop and interim messages only)

Accounting-Session-ID

Accounting-Authentic

Accounting-Session-Time (Stop and interim messages only)

Accounting-Input-Packets (Stop and interim messages only)

Accounting-Output-Packets (Stop and interim messages only)

Accounting-Terminate-Cause (Stop messages only)

Accounting-Input-Gigawords

Accounting-Output-Gigawords

Event-Timestamp

Tunnel-Type

Tunnel-Medium-Type

Tunnel-Group-ID

IPv6-Framed-Prefix

IPv6-Framed-Address

This table lists the different values for the Accounting-Status-Type attribute (40).

Table 9: Accounting-Status-Type Attribute Values

Attribute ID

Description

Start

Stop

Interim-Update

Note

RADIUS Accounting Interim updates are sent upon each client authentication, even if the RADIUS Server Accounting - Interim

Update feature is not enabled on the client's WLAN.

Accounting-On

Accounting-Off

Cisco Wireless Controller Configuration Guide, Release 8.3

161

Setting up TACACS+

9-14

Reserved for Tunneling Accounting

Reserved for Failed

Setting up TACACS+

Information About TACACS+

Terminal Access Controller Access Control System Plus (TACACS+) is a client/server protocol that provides centralized security for users attempting to gain management access to a controller. It serves as a backend database similar to local and RADIUS. However, local and RADIUS provide only authentication support and limited authorization support while TACACS+ provides three services:

• Authentication—The process of verifying users when they attempt to log into the controller.

Users must enter a valid username and password in order for the controller to authenticate users to the

TACACS+ server. The authentication and authorization services are tied to one another. For example, if authentication is performed using the local or RADIUS database, then authorization would use the permissions associated with the user in the local or RADIUS database (which are read-only, read-write, and lobby-admin) and not use TACACS+. Similarly, when authentication is performed using TACACS+, authorization is tied to TACACS+.

Note

When multiple databases are configured, you can use the controller GUI or CLI to specify the sequence in which the backend databases should be tried.

• Authorization—The process of determining the actions that users are allowed to take on the controller based on their level of access.

For TACACS+, authorization is based on privilege (or role) rather than specific actions. The available roles correspond to the seven menu options on the controller GUI: MONITOR, WLAN, CONTROLLER,

WIRELESS, SECURITY, MANAGEMENT, and COMMANDS. An additional role, LOBBY, is available for users who require only lobby ambassador privileges. The roles to which users are assigned are configured on the TACACS+ server. Users can be authorized for one or more roles. The minimum authorization is MONITOR only, and the maximum is ALL, which authorizes the user to execute the functionality associated with all seven menu options. For example, a user who is assigned the role of

SECURITY can make changes to any items appearing on the Security menu (or designated as security commands in the case of the CLI). If users are not authorized for a particular role (such as WLAN), they can still access that menu option in read-only mode (or the associated CLI show commands). If the

TACACS+ authorization server becomes unreachable or unable to authorize, users are unable to log into the controller.

162

Cisco Wireless Controller Configuration Guide, Release 8.3

Setting up TACACS+

Note

If users attempt to make changes on a controller GUI page that are not permitted for their assigned role, a message appears indicating that they do not have sufficient privilege.

If users enter a controller CLI command that is not permitted for their assigned role, a message may appear indicating that the command was successfully executed although it was not. In this case, the following additional message appears to inform users that they lack sufficient privileges to successfully execute the command: “Insufficient

Privilege! Cannot execute command!”

• Accounting—The process of recording user actions and changes.

Whenever a user successfully executes an action, the TACACS+ accounting server logs the changed attributes, the user ID of the person who made the change, the remote host where the user is logged in, the date and time when the command was executed, the authorization level of the user, and a description of the action performed and the values provided. If the TACACS+ accounting server becomes unreachable, users are able to continue their sessions uninterrupted.

TACACS+ uses Transmission Control Protocol (TCP) for its transport, unlike RADIUS which uses User

Datagram Protocol (UDP). It maintains a database and listens on TCP port 49 for incoming requests. The controller, which requires access control, acts as the client and requests AAA services from the server. The traffic between the controller and the server is encrypted by an algorithm defined in the protocol and a shared secret key configured on both devices.

You can configure up to three TACACS+ authentication, authorization, and accounting servers each. For example, you may want to have one central TACACS+ authentication server but several TACACS+ authorization servers in different regions. If you configure multiple servers of the same type and the first one fails or becomes unreachable, the controller automatically tries the second one and then the third one if necessary.

Note

If multiple TACACS+ servers are configured for redundancy, the user database must be identical in all the servers for the backup to work properly.

The following are some guidelines about TACACS+:

• You must configure TACACS+ on both your CiscoSecure Access Control Server (ACS) and your controller. You can configure the controller through either the GUI or the CLI.

• TACACS+ is supported on CiscoSecure ACS version 3.2 and later releases. See the CiscoSecure ACS documentation for the version that you are running.

• One Time Passwords (OTPs) are supported on the controller using TACACS. In this configuration, the controller acts as a transparent passthrough device. The controller forwards all client requests to the

TACACS server without inspecting the client behavior. When using OTP, the client must establish a single connection to the controller to function properly. The controller currently does not have any intelligence or checks to correct a client that is trying to establish multiple connections.

• We recommend that you increase the retransmit timeout value for TACACS+ authentication, authorization, and accounting servers if you experience repeated reauthentication attempts or the controller falls back to the backup server when the primary server is active and reachable. The default retransmit timeout value is 2 seconds and you can increase the retransmit timeout value to a maximum of 30 seconds.

• To configure the TACACS+ server:

Cisco Wireless Controller Configuration Guide, Release 8.3

163

Setting up TACACS+

• Using Identity Services Engine (ISE)—See the ISE TACACS+ Configuration Guide for Wireless

LAN Controllers at http://www.cisco.com/c/dam/en/us/td/docs/security/ise/how_to/

HowTo-TACACS_for_WLC.pdf

TACACS+ DNS

You can use a fully qualified domain name (FQDN) that enables you to change the IP address when needed, for example, for load balancing updates. A submenu, DNS, is added to the Security > AAA > TACACS+ menu, which you can use to get TACACS+ IP information from a DNS. The DNS query is disabled by default.

Note

IPv6 is not supported for TACAS+ DNS.

It is not possible to use both the static list and the DNS list at the same time. The addresses returned by the

DNS override the static entries.

DNS AAA is valid for FlexConnect AP clients that use central authentication.

DNS AAA is not supported to define a RADIUS for FlexConnect AP groups. For FlexConnect clients with local switching, you have to manually define AAA.

Rogue, 802.1X, web authentication, MAC filtering, mesh, and other features that use the global list also use the DNS-defined servers.

Dynamic Management User Login via AAA Server

The management users, who logged in using local credentials when external AAA servers were not available, are notified to re-authenticate within the set time frame when external TACACS+ servers are available. Failing to authenticate will terminate the user session. TACACS+ uses the TACACS+ fallback-test configuration and the re-authentication configuration is common to RADIUS and TACACS+. This enhancement was introduced in 8.2 release.

TACACS+ VSA

The Internet Engineering Task Force (IETF) draft standard specifies a method for communicating vendor-specific attributes (VSAs) between the network access server and the TACACS+ server. The IETF uses attribute 26. VSAs allow vendors to support their own extended attributes that are not suitable for general use.

The Cisco TACACS+ implementation supports one vendor-specific option using the format recommended in the IETF specification. The Cisco vendor ID is 9, and the supported option is vendor type 1, which is named cisco-av-pair. The value is a string with the following format: protocol : attribute separator value *

The protocol is a Cisco attribute for a particular type of authorization, the separator is = (equal sign) for mandatory attributes, and * (asterisk) indicates optional attributes.

164

Cisco Wireless Controller Configuration Guide, Release 8.3

Setting up TACACS+

Configuring TACACS+ on the ACS

Step 1

Step 2

Choose Network Configuration on the ACS main page.

Choose Add Entry under AAA Clients to add your controller to the server. The Add AAA Client page appears.

Figure 17: Add AAA Client Page on CiscoSecure ACS

Step 3

Step 4

Step 5

In the AAA Client Hostname text box, enter the name of your controller.

In the AAA Client IP Address text box, enter the IP address of your controller.

In the Shared Secret text box, enter the shared secret key to be used for authentication between the server and the controller.

Note

The shared secret key must be the same on both the server and the controller.

Cisco Wireless Controller Configuration Guide, Release 8.3

165

Setting up TACACS+

Step 6

Step 7

Step 8

Step 9

Step 10

Step 11

Step 12

Step 13

Step 14

Step 15

Step 16

Step 17

Step 18

Step 19

Step 20

Step 21

Step 22

Step 23

From the Authenticate Using drop-down list, choose TACACS+ (Cisco IOS).

Click Submit + Apply to save your changes.

On the ACS main page, in the left navigation pane, choose Interface Configuration.

Choose TACACS+ (Cisco IOS). The TACACS+ (Cisco) page appears.

Under TACACS+ Services, select the Shell (exec) check box.

Under New Services, select the first check box and enter ciscowlc in the Service text box and common in the Protocol text box.

Under Advanced Configuration Options, select the Advanced TACACS+ Features check box.

Click Submit to save your changes.

On the ACS main page, in the left navigation pane, choose System Configuration.

Choose Logging.

When the Logging Configuration page appears, enable all of the events that you want to be logged and save your changes.

On the ACS main page, in the left navigation pane, choose Group Setup.

From the Group drop-down list, choose a previously created group.

Note

This step assumes that you have already assigned users to groups on the ACS according to the roles to which they will be assigned.

Click Edit Settings. The Group Setup page appears.

Under TACACS+ Settings, select the ciscowlc common check box.

Select the Custom Attributes check box.

In the text box below Custom Attributes, specify the roles that you want to assign to this group. The available roles are

MONITOR, WLAN, CONTROLLER, WIRELESS, SECURITY, MANAGEMENT, COMMANDS, ALL, and LOBBY.

The first seven correspond to the menu options on the controller GUI and allow access to those particular controller features. If a user is not entitled for a particular task, the user is still allowed to access that task in read-only mode. You can enter one or multiple roles, depending on the group's needs. Use ALL to specify all seven roles or LOBBY to specify the lobby ambassador role. Enter the roles using this format: rolex=ROLE

For example, to specify the WLAN, CONTROLLER, and SECURITY roles for a particular user group, you would enter the following text: role1=WLAN role2=CONTROLLER role3=SECURITY?

To give a user group access to all seven roles, you would enter the following text: role1=ALL?

Note

Make sure to enter the roles using the format shown above. The roles must be in all uppercase letters, and there can be no spaces within the text.

Note

You should not combine the MONITOR role or the LOBBY role with any other roles. If you specify one of these two roles in the Custom Attributes text box, users will have MONITOR or LOBBY privileges only, even if additional roles are specified.

Click Submit to save your changes.

166

Cisco Wireless Controller Configuration Guide, Release 8.3

Setting up TACACS+

Configuring TACACS+ (GUI)

Step 1

Step 2

Step 3

Step 4

Step 5

Step 6

Step 7

Choose Security > AAA > TACACS+.

Perform one of the following:

• If you want to configure a TACACS+ server for authentication, choose Authentication.

• If you want to configure a TACACS+ server for authorization, choose Authorization.

• If you want to configure a TACACS+ server for accounting, choose Accounting.

Note

The pages used to configure authentication, authorization, and accounting all contain the same text boxes.

Therefore, these instructions walk through the configuration only once, using the Authentication pages as examples. You would follow the same steps to configure multiple services and/or multiple servers.

For basic management authentication via TACACS+ to succeed, it is required to configure authentication and authorization servers on the WLC. Accounting configuration is optional.

The TACACS+ (Authentication, Authorization, or Accounting) Servers page appears. This page lists any TACACS+ servers that have already been configured.

• If you want to delete an existing server, hover your cursor over the blue drop-down arrow for that server and choose

Remove.

• If you want to make sure that the controller can reach a particular server, hover your cursor over the blue drop-down arrow for that server and choose Ping.

Perform one of the following:

• To edit an existing TACACS+ server, click the server index number for that server. The TACACS+ (Authentication,

Authorization, or Accounting) Servers > Edit page appears.

• To add a TACACS+ server, click New. The TACACS+ (Authentication, Authorization, or Accounting) Servers

> New page appears.

If you are adding a new server, choose a number from the Server Index (Priority) drop-down list to specify the priority order of this server in relation to any other configured TACACS+ servers providing the same service. You can configure up to three servers. If the controller cannot reach the first server, it tries the second one in the list and then the third if necessary.

If you are adding a new server, enter the IP address of the TACACS+ server in the Server IP Address text box.

From the Shared Secret Format drop-down list, choose ASCII or Hex to specify the format of the shared secret key to be used between the controller and the TACACS+ server. The default value is ASCII.

In the Shared Secret and Confirm Shared Secret text boxes, enter the shared secret key to be used for authentication between the controller and the server.

Note

The shared secret key must be the same on both the server and the controller.

Cisco Wireless Controller Configuration Guide, Release 8.3

167

Setting up TACACS+

Step 8

Step 9

Step 10

Step 11

Step 12

Step 13

Step 14

Step 15

Step 16

Step 17

Step 18

If you are adding a new server, enter the TACACS+ server’s TCP port number for the interface protocols in the Port

Number text box. The valid range is 1 to 65535, and the default value is 49.

In the Server Status text box, choose Enabled to enable this TACACS+ server or choose Disabled to disable it. The default value is Enabled.

In the Server Timeout text box, enter the number of seconds between retransmissions. The valid range is 5 to 30 seconds, and the default value is 5 seconds.

Note

Click Apply.

Specify the TACACS+ DNS parameters as follows: a) Choose Security > AAA > TACACS+ > DNS. The TACACS DNS Parameters page appears.

b) Select or unselect the DNS Query check box.

c) In the Interval in sec text box, enter the authentication port number. The valid range is 1 to 65535.

d) From the Secret Format drop-down list, choose the format in which you want to configure the secret. Valid options are ASCII and Hex.

e) Depending on the format selected, enter and confirm the secret.

Note

All servers are expected to use the same authentication port and the same secret.

f) In the DNS Timeout text box, enter the number of days after which the DNS query is refreshed to get the latest update from the DNS server.

g) In the URL text box, enter the fully qualified domain name or the absolute domain name of the TACACS+ server.

h) In the Server IP Address text box, enter the IPv4 address of the DNS server.

Note

IPv6 is not supported for TACACS+

DNS.

i) Click Apply.

Configure the TACACS+ probe duration mode as follows: a) Choose Security > AAA > TACACS+ > Fallback. The TACACS+ Fallback Parameters page appears.

b) From the Fallback Mode drop-down list, select Enable.

c) In the Interval in sec text box, enter the time in seconds. The valid range is between 180 and 3600 seconds.

d) Click Apply.

Configure the re-authentication terminal interval for a user before being logged out as follows: a) Choose Security > AAA > General. The AAA General page appears.

b) In the Mgmt User Re-auth Interval text box, enter the time in seconds. The valid range is between 0 and 300.

c) Click Apply.

Click Save Configuration.

Repeat the previous steps if you want to configure any additional services on the same server or any additional TACACS+ servers.

Specify the order of authentication when multiple databases are configured by choosing Security > Priority Order >

Management User. The Priority Order > Management User page appears.

In the Order Used for Authentication text box, specify which servers have priority when the controller attempts to authenticate management users.

168

Cisco Wireless Controller Configuration Guide, Release 8.3

Setting up TACACS+

Step 19

Step 20

Use the > and < buttons to move servers between the Not Used and Order Used for Authentication text boxes. After the desired servers appear in the Order Used for Authentication text box, use the Up and Down buttons to move the priority server to the top of the list. By default, the local database is always queried first. If the username is not found, the controller switches to the RADIUS server if configured for RADIUS or to the TACACS+ server if configured for

TACACS+. The default setting is local and then RADIUS.

Click Apply.

Click Save Configuration.

Configuring TACACS+ (CLI)

• Configure a TACACS+ authentication server by entering these commands:

• config tacacs auth add index server_ip_address port# {ascii | hex} shared_secret—Adds a

TACACS+ authentication server.

This command supports both IPv4 and IPv6 address formats.

• config tacacs auth delete index—Deletes a previously added TACACS+ authentication server.

• config tacacs auth (enable | disable} index—Enables or disables a TACACS+ authentication server.

• config tacacs auth server-timeout index timeout—Configures the retransmission timeout value for a TACACS+ authentication server.

• Configure a TACACS+ authorization server by entering these commands:

◦config tacacs athr add index server_ip_address port# {ascii | hex} shared_secret—Adds a

TACACS+ authorization server.

This command supports both IPv4 and IPv6 address formats.

◦config tacacs athr delete index—Deletes a previously added TACACS+ authorization server.

◦config tacacs athr (enable | disable} index—Enables or disables a TACACS+ authorization server.

◦config tacacs athr server-timeout index timeout—Configures the retransmission timeout value for a TACACS+ authorization server.

◦config tacacs athr mgmt-server-timeout index timeout—Configures the default management login server timeout for a TACACS+ authorization server.

• Configure a TACACS+ accounting server by entering these commands:

◦config tacacs acct add index server_ip_address port# {ascii | hex} shared_secret—Adds a

TACACS+ accounting server.

This command supports both IPv4 and IPv6 address formats.

◦config tacacs acct delete index—Deletes a previously added TACACS+ accounting server.

◦config tacacs acct (enable | disable} index—Enables or disables a TACACS+ accounting server.

Cisco Wireless Controller Configuration Guide, Release 8.3

169

Setting up TACACS+

◦config tacacs acct server-timeout index timeout—Configures the retransmission timeout value for a TACACS+ accounting server.

◦config tacacs acct mgmt-server-timeout index timeout—Configures the default management login server timeout for a TACACS+ accounting server.

• See TACACS+ statistics by entering these commands:

◦show tacacs summary—Shows a summary of TACACS+ servers and statistics.

◦show tacacs auth stats—Shows the TACACS+ authentication server statistics.

◦show tacacs athr stats—Shows the TACACS+ authorization server statistics.

◦show tacacs acct stats—Shows the TACACS+ accounting server statistics.

• Clear the statistics for one or more TACACS+ servers by entering this command:

clear stats tacacs [auth | athr | acct] {index | all}

• Configure the order of authentication when multiple databases are configured by entering this command.

The default setting is local and then radius.

config aaa auth mgmt [radius | tacacs]

See the current management authentication server order by entering the show aaa auth command.

• Make sure the controller can reach the TACACS+ server by entering this command:

ping server_ip_address

• Configure TACACS+ DNS parameters by entering these commands:

• config tacacs dns global port-num {ascii | hex} secret—Adds global port number and secret information for the TACACS+ DNS.

• config tacacs dns query url timeout-in-days—Configures the FQDN of the TACACS+ server and timeout after which a refresh is performed to get the latest update from the DNS server.

• config tacacs dns serverip ip-addr—Configures the IP address of the DNS server.

• config tacacs dns {enable | disable}—Enables or disables the DNS query.

• Configure TACACS+ probe and re-authentication interval by entering these commands:

• config tacacs fallback-test interval seconds—Enables and sets the probe interval for TACACS+ server. The valid range is 0 to disable and between 180 and 3600 seconds when enabled.

• config mgmtuser termination-interval seconds—Sets the interval of re-authentication window for the user before being logged out of the system. The valid range is between 0 and 300. Default value is 0.

• View the user authentication server configuration by entering the following commands:

• show aaa auth —Displays AAA related information for authentication servers.

• show tacacs summary —Displays TACACS+ summary

• Enable or disable TACACS+ debugging by entering this command:

debug aaa tacacs {enable | disable}

170

Cisco Wireless Controller Configuration Guide, Release 8.3

Setting up TACACS+

• Save your changes by entering this command:

save config

Viewing the TACACS+ Administration Server Logs

Step 1

Step 2

On the ACS main page, in the left navigation pane, choose Reports and Activity.

Under Reports, choose TACACS+ Administration.

Click the .csv file corresponding to the date of the logs you want to view. The TACACS+ Administration .csv page appears.

Figure 18: TACACS+ Administration .csv Page on CiscoSecure ACS

This page displays the following information:

• Date and time the action was taken

• Name and assigned role of the user who took the action

• Group to which the user belongs

• Specific action that the user took

• Privilege level of the user who executed the action

• IP address of the controller

• IP address of the laptop or workstation from which the action was executed

Cisco Wireless Controller Configuration Guide, Release 8.3

171

Maximum Local Database Entries

Sometimes a single action (or command) is logged multiple times, once for each parameter in the command. For example, if you enter the snmp community ipaddr ip_address subnet_mask community_name command, the IP address may be logged on one line while the subnet mask and community name are logged as “E.” On another line, the subnet mask maybe logged while the IP address and community name are logged as “E.” See the first and third lines in the example in this figure.

Figure 19: TACACS+ Administration .csv Page on CiscoSecure ACS

Maximum Local Database Entries

Information About Configuring Maximum Local Database Entries

You can configure the controller to specify the maximum number of local database entries used for storing user authentication information. The database entries include local management users (including lobby ambassadors), local network users (including guest users), MAC filter entries, exclusion list entries, and access point authorization list entries. Together they cannot exceed the configured maximum value.

172

Cisco Wireless Controller Configuration Guide, Release 8.3

Configuring Maximum Local Database Entries (GUI)

Configuring Maximum Local Database Entries (GUI)

Step 1

Step 2

Step 3

Step 4

Choose Security > AAA > General to open the General page.

In the Maximum Local Database Entries text box, enter a value for the maximum number of entries that can be added to the local database the next time the controller reboots. The currently configured value appears in parentheses to the right of the text box. The valid range is 512 to 2048, and the default setting is 2048.

The Number of Entries, Already Used text box shows the number of entries currently in the database.

Click Apply to commit your changes.

Click Save Configuration to save your settings.

Configuring Maximum Local Database Entries (CLI)

Step 1

Step 2

Step 3

Specify the maximum number of entries that can be added to the local database the next time the controller reboots by entering this command:

config database size max_entries

Save your changes by entering this command:

save config

View the maximum number of database entries and the current database contents by entering this command:

show database summary

Cisco Wireless Controller Configuration Guide, Release 8.3

173

Configuring Maximum Local Database Entries (CLI)

174

Cisco Wireless Controller Configuration Guide, Release 8.3

C H A P T E R

Managing Users

•

Configuring Administrator Usernames and Passwords, page 175

•

Configuring Guest User Accounts, page 177

•

Password Policies, page 180

Configuring Administrator Usernames and Passwords

Information About Configuring Administrator Usernames and Passwords

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.

Configuring Usernames and Passwords (GUI)

Step 1

Step 2

Step 3

Step 4

Step 5

Choose Management > Local Management Users.

Click New.

Enter the username and password, and confirm the password.

Usernames and passwords are case-sensitive and can contain up to 24 ASCII characters. Usernames and passwords cannot contain spaces.

Choose the User Access Mode as one of the following:

• ReadOnly

• ReadWrite

• LobbyAdmin

Click Apply.

Cisco Wireless Controller Configuration Guide, Release 8.3

175

Configuring Administrator Usernames and Passwords

Configuring Usernames and Passwords (CLI)

Step 1

Step 2

Configure a username and password by entering one of these commands:

• config mgmtuser add username password read-write—Creates a username-password pair with read-write privileges.

• config mgmtuser add username password read-only—Creates a username-password pair with read-only privileges.

Usernames and passwords are case-sensitive and can contain up to 24 ASCII characters. Usernames and passwords cannot contain spaces.

Note

If you ever need to change the password for an existing username, enter the config mgmtuser password

username new_password command.

List the configured users by entering this command:

show mgmtuser

Restoring Passwords

Before You Begin

Ensure that you are accessing the controller CLI through the console port.

Step 1

Step 2

Step 3

Step 4

Step 5

Step 6

After the controller boots up, enter Restore-Password at the User prompt.

Note

For security reasons, the text that you enter does not appear on the controller console.

At the Enter User Name prompt, enter a new username.

At the Enter Password prompt, enter a new password.

At the Re-enter Password prompt, reenter the new password. The controller validates and stores your entries in the database.

When the User prompt reappears, enter your new username.

When the Password prompt appears, enter your new password. The controller logs you in with your new username and password.

176

Cisco Wireless Controller Configuration Guide, Release 8.3

Configuring Guest User Accounts

Configuring Guest User Accounts

Information About Creating Guest Accounts

The controller can provide guest user access on WLANs. The first step in creating guest user accounts is to create a lobby administrator user, also known as a lobby ambassador account. Once this account has been created, a lobby ambassador can create and manage guest user accounts on the controller. The lobby ambassador has limited configuration privileges and access only to the web pages used to manage the guest accounts.

The lobby ambassador can specify the amount of time that the guest user accounts remain active. After the specified time elapses, the guest user accounts expire automatically.

Restrictions on Managing User Accounts

• The local user database is limited to a maximum of 2048 entries, which is also the default value. This database is shared by local management users (including lobby ambassadors), local network users

(including guest users), MAC filter entries, exclusion list entries, and access point authorization list entries. Together they cannot exceed the configured maximum value.

• For net user accounts or guest user accounts, the following special characters are allowed along with alphanumeric characters: ~, @, #, $, %, ^, &, (, ), !, _, -, `, ., [, ], =, +, *, :, ;, {, }, ,, /, and \.

Creating a Lobby Ambassador Account

Creating a Lobby Ambassador Account (GUI)

Step 1

Step 2

Step 3

Step 4

Choose Management > Local Management Users to open the Local Management Users page.

This page lists the names and access privileges of the local management users.

Note

If you want to delete any of the user accounts from the controller, hover your cursor over the blue drop-down arrow and choose Remove. However, deleting the default administrative user prohibits both GUI and CLI access to the controller. Therefore, you must create a user with administrative privileges (ReadWrite) before you remove the default user.

Click New to create a lobby ambassador account. The Local Management Users > New page appears.

In the User Name text box, enter a username for the lobby ambassador account.

Note

Management usernames must be unique because they are stored in a single database.

In the Password and Confirm Password text boxes, enter a password for the lobby ambassador account.

Cisco Wireless Controller Configuration Guide, Release 8.3

177

Configuring Guest User Accounts

Step 5

Step 6

Step 7

Note

Passwords are case sensitive. The settings for the management User Details parameters depends on the settings that you make in the Password Policy page. The following requirements are enforced on the password

• The password should contain characters from at least three of the following classes: lowercase letters, uppercase letters, digits, and special characters.

• No character in the password can be repeated more than three times consecutively.

• The password should not contain a management username or the reverse letters of a username.

• The password should not contain words like Cisco, oscic, admin, nimda, or any variant obtained by changing the capitalization of letters by substituting 1, |, or ! or substituting 0 for o or substituting $ for s.

Choose LobbyAdmin from the User Access Mode drop-down list. This option enables the lobby ambassador to create guest user accounts.

Note

The ReadOnly option creates an account with read-only privileges, and the ReadWrite option creates an administrative account with both read and write privileges.

Click Apply to commit your changes. The new lobby ambassador account appears in the list of local management users.

Click Save Configuration to save your changes.

Creating a Lobby Ambassador Account (CLI)

To create a lobby ambassador account use the following command:

config mgmtuser add lobbyadmin_username lobbyadmin_pwd lobby-admin

Note

Replacing lobby-admin with read-only creates an account with read-only privileges. Replacing

lobby-admin with read-write creates an administrative account with both read and write privileges.

Creating Guest User Accounts as a Lobby Ambassador (GUI)

Step 1

Step 2

Step 3

Step 4

Log into the controller as the lobby ambassador, using the username and password. The Lobby Ambassador Guest

Management > Guest Users List page appears.

Click New to create a guest user account. The Lobby Ambassador Guest Management > Guest Users List > New page appears.

In the User Name text box, enter a name for the guest user. You can enter up to 24 characters.

Perform one of the following:

• If you want to generate an automatic password for this guest user, select the Generate Password check box. The generated password is entered automatically in the Password and Confirm Password text boxes.

• If you want to create a password for this guest user, leave the Generate Password check box unselected and enter a password in both the Password and Confirm Password text boxes.

Note

Passwords can contain up to 24 characters and are case sensitive.

178

Cisco Wireless Controller Configuration Guide, Release 8.3

Configuring Guest User Accounts

Step 5

Step 6

Step 7

Step 8

Step 9

From the Lifetime drop-down lists, choose the amount of time (in days, hours, minutes, and seconds) that this guest user account is to remain active. A value of zero (0) for all four text boxes creates a permanent account.

Default: 1 day

Range: 5 minutes to 30 days

Note

The smaller of this value or the session timeout for the guest WLAN, which is the WLAN on which the guest account is created, takes precedence. For example, if a WLAN session timeout is due to expire in 30 minutes but the guest account lifetime has 10 minutes remaining, the account is deleted in 10 minutes upon guest account expiry. Similarly, if the WLAN session timeout expires before the guest account lifetime, the client experiences a recurring session timeout that requires reauthentication.

You can change a guest user account with a nonzero lifetime to another lifetime value at any time while the account is active. However, to make a guest user account permanent using the controller GUI, you must delete the account and create it again. If desired, you can use the config netuser lifetime user_name 0 command to make a guest user account permanent without deleting and recreating it.

From the WLAN SSID drop-down list, choose the SSID that will be used by the guest user. The only WLANs that are listed are those WLANs for which Layer 3 web authentication has been configured.

Note

We recommend that you create a specific guest WLAN to prevent any potential conflicts. If a guest account expires and it has a name conflict with an account on the RADIUS server and both are on the same WLAN, the users associated with both accounts are disassociated before the guest account is deleted.

In the Description text box, enter a description of the guest user account. You can enter up to 32 characters.

Click Apply to commit your changes. The new guest user account appears in the list of guest users on the Guest Users

List page.

From this page, you can see all of the guest user accounts, their WLAN SSID, and their lifetime. You can also edit or remove a guest user account. When you remove a guest user account, all of the clients that are using the guest WLAN and are logged in using that account’s username are deleted.

Repeat this procedure to create any additional guest user accounts.

Viewing Guest User Accounts

Viewing the Guest Accounts (GUI)

To view guest user accounts using the controller GUI, choose Security > AAA > Local Net Users. The Local

Net Users page appears.

From this page, you can see all of the local net user accounts (including guest user accounts) and can edit or remove them as desired. When you remove a guest user account, all of the clients that are using the guest

WLAN and are logged in using that account’s username are deleted.

Viewing the Guest Accounts (CLI)

To see all of the local net user accounts (including guest user accounts) using the controller CLI, enter this command:

show netuser summary

Cisco Wireless Controller Configuration Guide, Release 8.3

179

Password Policies

Password Policies

Information About Password Policies

The password policies allows you to enforce 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 old version, all the old passwords are maintained as it is, even though the passwords are weak. After the system upgrade, if 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.

Restrictions on Password Policies

• Strong password requirement based on WLAN-CC requirement is applicable only to WLAN admin login passwords and is not applicable to AP Management passwords.

• Strong password - lockout feature is not applied if you try to access the Cisco WLC through a serial connection or a terminal server connection and it has unlimited attempts.

Configuring Password Policies (GUI)

Step 1

Step 2

Step 3

Step 4

Step 5

Step 6

Step 7

Choose Security > AAA > Password Policies to open the Password Policies page.

Select the Password must contain characters from at least 3 different classes check box if you want your password to contain characters from at least three of the following classes: lower case letters, upper case letters, digits, and special characters.

Select the No character can be repeated more than 3 times consecutively check box if you do not want character in the new password to repeat more than three times consecutively.

Select the Password cannot be the default words like cisco, admin check box if you do not want the password to contain words such as Cisco, ocsic, admin, nimda, or any variant obtained by changing the capitalization of letters or by substituting 1, |, or! or substituting 0 for o or substituting $ for s.

Select the Password cannot contain username or reverse of username check box if you do not want the password to contain a username or the reverse letters of a username.

Click Apply to commit your changes.

Click Save Configuration to save your changes.

Configuring Password Policies (CLI)

• Enable or disable strong password check for AP and WLC by entering this command:

180

Cisco Wireless Controller Configuration Guide, Release 8.3

Password Policies

config switchconfig strong-pwd {case-check | consecutive-check | default-check | username-check

| all-checks| position-check | case-digit-check} {enable | disable} where

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

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

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

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

◦position-check—Checks four-character range from old password.

◦case-digit-check—Checks all four combinations to be present: lower, upper, digits, and special characters.

• Configure minimum number of upper, lower, digit, and special characters in a password by entering this command:

config switchconfig strong-pwd minimum {upper-case | lower-case | digits | special-chars}

num-of-chars

• Configure minimum length for a password by entering this command:

config switchconfig strong-pwd min-length pwd-length

• Configure lockout for management or SNMPv3 users by entering this command:

config switchconfig strong-pwd lockout {mgmtuser | snmpv3user} {enable | disable}

• Configure lockout time for management or SNMPv3 users by entering this command:

config switchconfig strong-pwd lockout time {mgmtuser | snmpv3user} timeout-in-mins

• Configure the number of consecutive failure attempts for management or SNMPv3 users by entering this command:

config switchconfig strong-pwd lockout attempts {mgmtuser | snmpv3user} num-of-failure-attempts

• Configure lifetime for management or SNMPv3 users by entering this command:

config switchconfig strong-pwd lifetime {mgmtuser | snmpv3user} lifetime-in-days

• See the configured options for strong password check by entering this command:

show switchconfig

Information similar to the following appears:

802.3x Flow Control Mode......................... Disabled

FIPS prerequisite features....................... Disabled secret obfuscation............................... Enabled

Strong Password Check Features: case-check ...........Enabled

consecutive-check ....Enabled

default-check .......Enabled

username-check ......Enabled

Cisco Wireless Controller Configuration Guide, Release 8.3

181

Password Policies

182

Cisco Wireless Controller Configuration Guide, Release 8.3

C H A P T E R

Ports and Interfaces

•

Ports, page 183

•

Link Aggregation, page 187

•

Interfaces, page 192

Ports

Information About Ports

A port is a physical entity that is used for connections on the controller platform. Controllers have two types of ports: distribution system ports and a service port.

Figure 20: Ports on the Cisco 5508 Wireless Controllers

Redundant port (RJ-45)

2 Service port (RJ-45)

3 Console port (RJ-45)

4 USB ports 0 and 1 (Type A)

SFP distribution system ports 1–8

7 Management port LEDs

8 SFP distribution port Link and Activity LEDs

9 Power supply (PS1 and PS2), System (SYS), and

Alarm (ALM) LEDs

Cisco Wireless Controller Configuration Guide, Release 8.3

183

Ports

5 Console port (Mini USB Type B)

Note

You can use only one console port

(either RJ-45 or mini USB). When you connect to one console port, the other is disabled.

10 Expansion module slot

For more information about Cisco Unified Wireless Network Protocol and Port Matrix, see http:// www.cisco.com/c/en/us/support/docs/wireless/5500-series-wireless-controllers/113344-cuwn-ppm.html

Information About Distribution System Ports

A distribution system port connects the controller to a neighbor switch and serves as the data path between these two devices.

Restrictions for Configuring Distribution System Ports

• Cisco 5508 Controllers have eight Gigabit Ethernet distribution system ports, through which the Controller can manage multiple access points. The 5508-12, 5508-25, 5508-50, 5508-100, and 5508-250 models allow a total of 12, 25, 50, 100, or 250 access points to join the controller. Cisco 5508 controllers have no restrictions on the number of access points per port. However, we recommend using link aggregation

(LAG) or configuring dynamic AP-manager interfaces on each Gigabit Ethernet port to automatically balance the load. If more than 100 access points are connected to the Cisco 5500 Series Controller, make sure that more than one Gigabit Ethernet interface is connected to the upstream switch.

Note

The Gigabit Ethernet ports on the Cisco 5508 Controllers accept these SX/LC/T small form-factor plug-in (SFP) modules: -

• 1000BASE-SX SFP modules, which provide a 1000-Mbps wired connection to a network through an 850nM (SX) fiber-optic link using an LC physical connector

• 1000BASE-LX SFP modules, which provide a 1000-Mbps wired connection to a network through a 1300nM (LX/LH) fiber-optic link using an LC physical connector

• 1000BASE-T SFP modules, which provide a 1000-Mbps wired connection to a network through a copper link using an RJ-45 physical connector

• GLC-SX-MM, a 1000BASE-SX connector should be in auto-negotiation mode to function as desired because all SFP modules using LC physical connecters must ideally be in auto-negotiation mode on

Cisco 5508 Series Controllers to function properly. However, when Cisco ASR is connected using the fiber port, GLC-SX-MM does not come up between Cisco ASR and Cisco 5508 as Cisco ASR requires the connector to be in fixed mode to function properly.

• Each distribution system port is, by default, an 802.1Q VLAN trunk port. The VLAN trunking characteristics of the port are not configurable.

184

Cisco Wireless Controller Configuration Guide, Release 8.3

Ports

Note

Some controllers support link aggregation (LAG), which bundles all of the controller’s distribution system ports into a single 802.3ad port channel. Cisco 5500 Series Controllers support LAG, and LAG is enabled automatically on the controllers within the Cisco

WiSM2.

• Cisco WLC configuration in access mode is not supported. We recommend that you configure Cisco

WLC in trunk mode when you configure Cisco WLC ports on a switch.

• In Cisco Flex 7500 and 8500 Series Controllers:

◦If a port is unresponsive after a soaking period of 5 seconds, all the interfaces for which the port is the primary and the active port, fail over to the backup port, if a backup is configured and is operational. Similarly, if the unresponsive port is the backup port, then all the interfaces fail over to the primary port if it is operational.

◦After the unresponsive port is restored, there is a soaking period of 60 seconds after which if the port is still operational, then all the interfaces fall back to this port, which was the primary port. If the port was the backup port, then no change is done.

◦You must ensure that you configure the port before you connect a switch or distribution system in the Cisco Wireless LAN Controller 2500 series.

• If an IPv6 packet is destined to controller management IPv6 address and the client VLAN is different from the controller management VLAN, then the IPv6 packet is switched out of the WLC box. If the same IPv6 packet comes as a network packet to the WLC, management access is not denied.

Information About Service Port

Cisco 5500 Series Controllers also have a 10/100/1000 copper Ethernet service port. The service port is controlled by the service-port interface and is reserved for out-of-band management of the controller and system recovery and maintenance in the event of a network failure. It is also the only port that is active when the controller is in boot mode. The service port is not capable of carrying 802.1Q tags, so it must be connected to an access port on the neighbor switch. Use of the service port is optional.

The service port of the Cisco Wireless Controller 7510 and 8510 models is a one Gigabit Ethernet port. To verify the speed of service port, you must connect the service port to a Gigabit Ethernet port on the switch.

Note

The service port is not auto-sensing. You must use the correct straight-through or crossover Ethernet cable to communicate with the service port.

Caution

Do not configure wired clients in the same VLAN or subnet of the service port of the controller on the network. If you configure wired clients on the same subnet or VLAN as the service port, it is not possible to access the management interface of the controller.

Cisco Wireless Controller Configuration Guide, Release 8.3

185

Ports

Configuring Ports (GUI)

The controller’s ports are configured with factory-default settings designed to make the controllers’ ports operational without additional configuration. However, you can view the status of the controller’s ports and edit their configuration parameters at any time.

Step 1

Choose Controller > Ports to open the Ports page.

This page shows the current configuration for each of the controller’s ports.

If you want to change the settings of any port, click the number for that specific port. The Port > Configure page appears.

Note

If the management and AP-manager interfaces are mapped to the same port and are members of the same VLAN, you must disable the WLAN before making a port-mapping change to either interface. If the management and

AP-manager interfaces are assigned to different VLANs, you do not need to disable the WLAN.

Note

The number of parameters available on the Port > Configure page depends on your controller type.

The following show the current status of the port:

• Port Number—Number of the current port.

• Admin Status—Current state of the port. Values: Enable or Disable

• Physical Mode—Configuration of the port physical interface. The mode varies by the controller type.

• Physical Status—The data rate being used by the port. The available data rates vary based on controller type.

◦2500 series - 1 Gbps full duplex

◦WiSM2 - 10 Gbps full duplex

◦7500 series - 10 Gbps full duplex

• Link Status—Link status of the port. Values: Link Up or Link Down

• Link Trap—Whether the port is set to send a trap when the link status changes. Values: Enable or Disable

• Power over Ethernet (PoE)—If the connecting device is equipped to receive power through the Ethernet cable and if so, provides –48 VDC. Values: Enable or Disable

Note

Some older Cisco access points do not draw PoE even if it is enabled on the controller port. In such cases, contact the Cisco Technical Assistance Center (TAC).

The following is a list of the port’s configurable parameters.

Admin Status—Enables or disables the flow of traffic through the port. Options: Enable or Disable, with default option of Enable.

Note

When a primary port link goes down, messages may get logged internally only and not be posted to a syslog server. It may take up to 40 seconds to restore logging to the syslog server.

Physical Mode—Determines whether the port’s data rate is set automatically or specified by the user. The supported data rates vary based on the controller type. Default: Auto.

Link Trap—Causes the port to send a trap when the port’s link status changes. Options: Enable or Disable, with default option of Enable.

186

Cisco Wireless Controller Configuration Guide, Release 8.3

Link Aggregation

Step 2

Step 3

Step 4

Step 5

Click Apply.

Click Save Configuration.

Click Back to return to the Ports page and review your changes.

Repeat this procedure for each additional port that you want to configure.

Link Aggregation

Information About Link Aggregation

Link aggregation (LAG) is a partial implementation of the 802.3ad port aggregation standard. It bundles all of the controller’s distribution system ports into a single 802.3ad port channel. This reduces the number of IP addresses required to configure the ports on your controller. When LAG is enabled, the system dynamically manages port redundancy and load balances access points transparently to the user.

LAG simplifies controller configuration because you no longer require to configure primary and secondary ports for each interface. If any of the controller ports fail, traffic is automatically migrated to one of the other ports. As long as at least one controller port is functioning, the system continues to operate, access points remain connected to the network, and wireless clients continue to send and receive data.

Cisco WLC does not send CDP advertisements on a LAG interface.

Note

LAG is supported across switches.

Link Aggregation for Cisco Aironet 1850 Series Access Points

Cisco Aironet 1850 Series 802.11ac Wave 2 Access Points have two Gigabit Ethernet interfaces, the PoE port and the AUX port, which, by using Link Aggregation, can together accommodate the greater than 1 Gbps of throughput expected with Wave 2.

Note

Only Link Aggregation Control Protocol (LACP) is supported; Port Aggregation Protocol (PAgP) is not supported.

LAG is supported on Cisco Aironet 1850 Series APs with the following switches:

• Cisco Catalyst 3850 Series Switches—All models (non-CA mode)

• Cisco Catalyst 3650 Series Switches—All models (non-CA mode)

• Cisco Catalyst 4500E Supervisor Engine 8-E

Restrictions for Link Aggregation

• You can bundle all eight ports on a Cisco 5508 Controller into a single link.

Cisco Wireless Controller Configuration Guide, Release 8.3

187

Link Aggregation

• Terminating on two different modules within a single Catalyst 6500 series switch provides redundancy and ensures that connectivity between the switch and the controller is maintained when one module fails. The controller’s port 1 is connected to Gigabit interface 3/1, and the controller’s port 2 is connected to Gigabit interface 2/1 on the Catalyst 6500 series switch. Both switch ports are assigned to the same channel group.

• LAG requires the EtherChannel to be configured for 'mode on' on both the controller and the Catalyst switch.

• Once the EtherChannel is configured as on at both ends of the link, the Catalyst switch should not be configured for either Link Aggregation Control Protocol (LACP) or Cisco proprietary Port Aggregation

Protocol (PAgP) but be set unconditionally to LAG. Because no channel negotiation is done between the controller and the switch, the controller does not answer to negotiation frames and the LAG is not formed if a dynamic form of LAG is set on the switch. Additionally, LACP and PAgP are not supported on the controller.

• If the recommended load-balancing method cannot be configured on the Catalyst switch, then configure the LAG connection as a single member link or disable LAG on the controller.

Figure 21: Link Aggregation with the Catalyst 6500 Series Neighbor Switch

• You cannot configure the controller’s ports into separate LAG groups. Only one LAG group is supported per controller. Therefore, you can connect a controller in LAG mode to only one neighbor device.

• When you enable LAG or make any changes to the LAG configuration, you must immediately reboot the controller.

• When you enable LAG, you can configure only one AP-manager interface because only one logical port is needed. LAG removes the requirement for supporting multiple AP-manager interfaces.

• When you enable LAG, all dynamic AP-manager interfaces and untagged interfaces are deleted, and all

WLANs are disabled and mapped to the management interface. Also, the management, static AP-manager, and VLAN-tagged dynamic interfaces are moved to the LAG port.

• Multiple untagged interfaces to the same port are not allowed.

• When you enable LAG, you cannot create interfaces with a primary port other than 29.

188

Cisco Wireless Controller Configuration Guide, Release 8.3

Link Aggregation

• When you enable LAG, all ports participate in LAG by default. You must configure LAG for all of the connected ports in the neighbor switch.

• When you enable LAG, if any single link goes down, traffic migrates to the other links.

• When you enable LAG, only one functional physical port is needed for the controller to pass client traffic.

• When you enable LAG, access points remain connected to the controller until you reboot the controller, which is needed to activate the LAG mode change, and data service for users continues uninterrupted.

• When you enable LAG, you eliminate the need to configure primary and secondary ports for each interface.

• When you enable LAG, the controller sends packets out on the same port on which it received them. If a CAPWAP packet from an access point enters the controller on physical port 1, the controller removes the CAPWAP wrapper, processes the packet, and forwards it to the network on physical port 1. This may not be the case if you disable LAG.

• When you disable LAG, the management, static AP-manager, and dynamic interfaces are moved to port

• When you disable LAG, you must configure primary and secondary ports for all interfaces.

• When you disable LAG, you must assign an AP-manager interface to each port on the controller.

Otherwise, access points are unable to join.

• Cisco 5500 Series Controllers support a single static link aggregation bundle.

• LAG is typically configured using the Startup Wizard, but you can enable or disable it at any time through either the GUI or CLI.

• When you enable LAG on Cisco 2500 Series Controller to which the direct-connect access point is associated, the direct connect access point is disconnected since LAG enabling is still in the transition state. You must reboot the controller immediately after enabling LAG.

• In 8500 when more than 1000 APs joining WLC flapping occurs, to avoid this do not add more than

1000 Aps on a single catalyst switch for Capwap IPv6.

Configuring Link Aggregation (GUI)

Step 1

Step 2

Step 3

Step 4

Step 5

Choose Controller > General to open the General page.

Set the LAG Mode on Next Reboot parameter to Enabled.

Save the configuration.

Reboot Cisco WLC.

Assign the WLAN to the appropriate VLAN.

Cisco Wireless Controller Configuration Guide, Release 8.3

189

Link Aggregation

Configuring Link Aggregation (CLI)

Step 1

Step 2

Step 3

Enter the config lag enable command to enable LAG.

Note

Enter the config lag disable command if you want to disable

LAG.

Enter the save config command to save your settings.

Reboot Cisco WLC.

Configuring Link Aggregation for Cisco 1850 Series APs (CLI)

• Configure the Cisco Aironet 1850 Series AP link aggregation by entering this global configuration command:

config ap lag-mode support {enable | disable}

Disabling global link aggregation for the APs will result in a reboot of all the lag enabled APs.

• Configure link aggregation for a specific Cisco AP by entering this command:

config ap lag-mode support {enable | disable} ap-name

Enabling or disabling link aggregation for the Cisco AP resets and reboots the specified Cisco AP.

• Enable and configure Port Channel mode on switches connected to the Cisco AP. For optimal traffic load balancing on the LAG ports to the Cisco AP, ensure that the switch supports balancing based purely on the L4 source and destination ports.

Configuration Example: interface Port-channel20 description 1852I lag switchport access vlan 1107 switchport mode access interface GigabitEthernet1/0/1 switchport access vlan 1107 switchport mode access channel-group 20 mode active interface GigabitEthernet1/0/2 switchport access vlan 1107 switchport mode access channel-group 20 mode active

For more information about this step, see the Cisco Aironet 1850 Series Access Point Deployment Guide at http://www.cisco.com/c/en/us/td/docs/wireless/controller/technotes/8-1/1850_DG/b_Cisco_Aironet_

Series_1850_Access_Point_Deployment_Guide.html

After link aggregation is enabled on the Cisco AP, the Cisco WLC and the Cisco AP use multiple

CAPWAP data tunnels to send and receive wireless client traffic.

• View the link aggregation status by entering these commands: a) View the status of link aggregation on the Cisco AP by entering this command on the AP console:

190

Cisco Wireless Controller Configuration Guide, Release 8.3

Link Aggregation show configuration

b) View the status of link aggregation on Cisco WLC by entering these commands on the Cisco WLC

CLI:

• show ap lag-mode

• show ap config general ap-name

Verifying Link Aggregation Settings (CLI)

To verify your LAG settings, enter this command:

show lag summary

Information similar to the following appears:

LAG Enabled

Configuring Neighbor Devices to Support Link Aggregation

The controller’s neighbor devices must also be properly configured to support LAG.

• Each neighbor port to which the controller is connected should be configured as follows: interface GigabitEthernet <interface id> switchport channel-group <id> mode on no shutdown

• The port channel on the neighbor switch should be configured as follows: interface port-channel <id> switchport switchport trunk encapsulation dot1q switchport trunk native vlan <native vlan id> switchport trunk allowed vlan <allowed vlans> switchport mode trunk no shutdown

Choosing Between Link Aggregation and Multiple AP-Manager Interfaces

Cisco 5500 Series Controllers have no restrictions on the number of access points per port, but we recommend using LAG or multiple AP-manager interfaces on each Gigabit Ethernet port to automatically balance the load.

The following factors should help you decide which method to use if your controller is set for Layer 3 operation:

• With LAG, all of the controller ports need to connect to the same neighbor switch. If the neighbor switch goes down, the controller loses connectivity.

• With multiple AP-manager interfaces, you can connect your ports to different neighbor devices. If one of the neighbor switches goes down, the controller still has connectivity. However, using multiple

AP-manager interfaces presents certain challenges when port redundancy is a concern.

Cisco Wireless Controller Configuration Guide, Release 8.3

191

Interfaces

Interfaces

Information About Interfaces

An interface is a logical entity on the controller. An interface has multiple parameters associated with it, including an IP address, default gateway (for the IP subnet), primary physical port, secondary physical port,

VLAN identifier, and DHCP server.

These five types of interfaces are available on the controller. Four of these are static and are configured at setup time:

• Management interface (static and configured at setup time; mandatory)

• AP-manager interface (static and configured at setup time; mandatory)

Note

You are not required to configure an AP-manager interface on Cisco 5500 Series

Controllers.

• Virtual interface (static and configured at setup time; mandatory)

• Service-port interface (static and configured at setup time; optional)

• Dynamic interface (user-defined)

Note

Typically, you define the management, AP-manager, virtual, and service-port interface parameters using the Startup Wizard. However, you can display and configure interface parameters through either the GUI or CLI after the controller is running.

When LAG is disabled, each interface is mapped to at least one primary port, and some interfaces (management and dynamic) can be mapped to an optional secondary (or backup) port. If the primary port for an interface fails, the interface automatically moves to the backup port. In addition, multiple interfaces can be mapped to a single controller port.

In Cisco Wireless LAN Controller 5508 Series, the controller marks packets greater than 1500 bytes as long.

However, the packets are not dropped. The workaround to this is to configure the MTU on a switch to less than 1500 bytes.

Note

Interfaces that are quarantined are not displayed on the Controller > Interfaces page. For example, if there are 6 interfaces and one of them is quarantined, the quarantined interface is not displayed and the details of the other 5 interfaces are displayed on the GUI. You can get the total number of interfaces that is inclusive of quarantined interfaces through the count displayed on the top-right corner of the GUI.

192

Cisco Wireless Controller Configuration Guide, Release 8.3

Interfaces

Restrictions for Configuring Interfaces

• Each physical port on the wireless controller can have only one AP-manager configured with it. For the

Cisco 5500 Series Controllers, the management interface with AP-management enabled cannot fail over to the backup port, which is primary for the AP-manager on the management or dynamic VLAN interface.

• Cisco 5500 Series Controllers do not support fragmented pings on any interface.

• When the port comes up in VMware ESXi with configuration for NIC teaming, the vWLC may lose connectivity. However, the virtual wireless LAN controller (vWLC) resumes connectivity after a while.

Information About Dynamic AP Management

A dynamic interface is created as a WLAN interface by default. However, any dynamic interface can be configured as an AP-manager interface, with one AP-manager interface allowed per physical port. A dynamic interface with the Dynamic AP Management option enabled is used as the tunnel source for packets from the controller to the access point and as the destination for CAPWAP packets from the access point to the controller.

The dynamic interfaces for AP management must have a unique IP address and are usually configured on the same subnet as the management interface.

Note

If link aggregation (LAG) is enabled, there can be only one AP-manager interface.

We recommend having a separate dynamic AP-manager interface per controller port.

Cisco Wireless Controller Configuration Guide, Release 8.3

193

Interfaces

Information About WLANs

A WLAN associates a service set identifier (SSID) to an interface or an interface group. It is configured with security, quality of service (QoS), radio policies, and other wireless network parameters. Up to 512 WLANs can be configured per controller.

Figure 22: Relationship between Ports, Interfaces, and WLANs

Each controller port connection is an 802.1Q trunk and should be configured as such on the neighbor switch.

On Cisco switches, the native VLAN of an 802.1Q trunk is an untagged VLAN. If you configure an interface to use the native VLAN on a neighboring Cisco switch, make sure you configure the interface on the controller to be untagged.

Note

A zero value for the VLAN identifier (on the Controller > Interfaces page) means that the interface is untagged.

194

Cisco Wireless Controller Configuration Guide, Release 8.3

Interfaces

The default (untagged) native VLAN on Cisco switches is VLAN 1. When controller interfaces are configured as tagged (meaning that the VLAN identifier is set to a nonzero value), the VLAN must be allowed on the

802.1Q trunk configuration on the neighbor switch and not be the native untagged VLAN.

We recommend that tagged VLANs be used on the controller. You should also allow only relevant VLANs on the neighbor switch’s 802.1Q trunk connections to controller ports. All other VLANs should be disallowed or pruned in the switch port trunk configuration. This practice is extremely important for optimal performance of the controller.

Note

We recommend that you assign one set of VLANs for WLANs and a different set of VLANs for management interfaces to ensure that controllers properly route VLAN traffic.

Management Interface

Information About the Management Interface

The management interface is the default interface for in-band management of the controller and connectivity to enterprise services such as AAA servers. It is also used for communications between the controller and access points. The management interface has the only consistently “pingable” in-band interface IP address on the controller. You can access the GUI of the controller by entering the management interface IP address of the controller in the address field of your browser.

For CAPWAP, the controller requires one management interface to control all inter-controller communications and one AP-manager interface to control all controller-to-access point communications, regardless of the number of ports.

If the service port is in use, the management interface must be on a different supernet from the service-port interface.

Note

To prevent or block a wired or wireless client from accessing the management network on a controller

(from the wireless client dynamic interface or VLAN), the network administrator must ensure that only authorized clients gain access to the management network through proper CPU ACLs, or use a firewall between the client dynamic interface and the management network.

Caution

Do not map a guest WLAN to the management interface. If the EoIP tunnel breaks, the client could obtain an IP and be placed on the management subnet.

Caution

Cisco Wireless Controller Configuration Guide, Release 8.3

195

Interfaces

Authentication Type for Management Interfaces

For any type of management access to the controller, bet it SSH, Telnet, or HTTP, we recommend that you use any one authentication type, which can be TACACS+, RADIUS, or Local, and not a mix of these authentication types. Ensure that you take care of the following:

• Authentication type (TACACS+, RADIUS, or Local), must be the same for all management access and for all AAA authentication and authorization parameters.

• The method list must be explicitly specified in the HTTP authentication.

Example

Follow these steps to configure Telnet:

Configure TACACS+ server by entering these commands:

tacacs server server-name

b address ipv4 ip-address

key key-name

Configure the server group name by entering these commands:

aaa group server tacacs+ group-name

b server name name

Configure authentication and authorization by entering these commands:

aaa authentication login method-list group server-group

b aaa authorization exec method-list group server-group

Note

These and all the other authentication and authorization parameters must be using the same database, be it RADIUS, TACACS+, or Local. For example, if command authorization has to be enabled, it also needs to be pointing to the same database.

Configure HTTP to use the above method lists:

ip http authentication aaa login-auth method-list

You must explicitly specify the method list, even if the method list is "default".

ip http authentication aaa exec-auth method-list

Note

• Do not configure any method-lists on the "line vty" configuration parameters. If the above steps and the line vty have different configurations, then line vty configurations take precedence.

• The database should be the same across all management configuration types such as SSH/Telnet and webui.

• You must explicitly define the method list for HTTP authentication.

Workaround

As a workaround, enter the following commands:

196

Cisco Wireless Controller Configuration Guide, Release 8.3

Interfaces

aaa authentication login default group server-group local

aaa authorization exec default group server-group local

Configuring the Management Interface (GUI)

Step 1

Step 2

Step 3

Choose Controller > Interfaces to open the Interfaces page.

Click the management link.

The Interfaces > Edit page appears.

Set the management interface parameters:

Note

The management interface uses the controller’s factory-set distribution system MAC address.

• Quarantine and quarantine VLAN ID, if applicable

Note

Select the Quarantine check box if you want to configure this VLAN as unhealthy or you want to configure network access control (NAC) out-of-band integration. Doing so causes the data traffic of any client that is assigned to this VLAN to pass through the controller.

• NAT address (only Cisco 2500 Series Controllers and Cisco 5500 Series Controllers are configured for dynamic

AP management.)

Note

Select the Enable NAT Address check box and enter the external NAT IP address if you want to be able to deploy your Cisco 2500 Series Controllers or Cisco 5500 Series Controller behind a router or other gateway device that is using one-to-one mapping network address translation (NAT). NAT allows a device, such as a router, to act as an agent between the Internet (public) and a local network (private). In this case, it maps the controller’s intranet IP addresses to a corresponding external address. The controller’s dynamic

AP-manager interface must be configured with the external NAT IP address so that the controller can send the correct IP address in the Discovery Response.

If a Cisco 2500 Series Controllers or Cisco 5500 Series Controller is configured with an external NAT IP address under the management interface, the APs in local mode cannot associate with the controller. The workaround is to either ensure that the management interface has a globally valid IP address or ensure that external NAT IP address is valid internally for the local APs.

The NAT parameters are supported for use only with one-to-one-mapping NAT, where each private client has a direct and fixed mapping to a global address. The NAT parameters do not support one-to-many NAT, which uses source port mapping to enable a group of clients to be represented by a single IP address.

• VLAN identifier

Note

Enter 0 for an untagged VLAN or a nonzero value for a tagged VLAN. We recommend using tagged

VLANs for the management interface.

• Configuring Management Interface using IPv4— Fixed IP address, IP netmask, and default gateway.

◦Configuring Management Interface using IPv6— Fixed IPv6 address, prefix-length (interface subnet mask for IPv6) and the link local address of the IPv6 gateway router.

Cisco Wireless Controller Configuration Guide, Release 8.3

197

Interfaces

Step 4

Step 5

Note

• In a setup where IPv6 is used, we recommend the APs to be at least one hop away from the Cisco

WLC. As the IPv6 packets are always sent to the Gateway, if the AP and WLC are in the same subnet, it increases the packet hops and impacts the performance.

• Once the Primary IPv6 Address, Prefix Length, and Primary IPv6 Gateway are configured on the management interface, they cannot be changed back to default values (:: /128).

• A configuration backup must be carried out before configuring IPv6 in case the user wants to revert back to IPv4 only management interface.

• When more than 1300 IPv6 APs are in use, on a single Catalyst 6000 Switch, then assign APs on multiple VLANs.

• In 8500 controller running a ha-pair,IPv6 primary gateway(link local) configured though 3600 AP joined with the IPv6 address tears down the capwap. Using the command test capwap though the

AP joined with ipv6 address, it is seen that when the Link local address is not reachable capwap should not be formed.

If APs are joined on V6 tunnel and if IPv6 gateway is misconfigured then v6 tunnel will not be teared down. The APs will still be on v6 tunnel and will not fall back to v4 tunnel.

• Dynamic AP management (for Cisco 2500 Series Controllers or Cisco 5500 Series Controller only)

Note

For Cisco 5500 Series Controllers, the management interface acts like an AP-manager interface by default.

If desired, you can disable the management interface as an AP-manager interface and create another dynamic interface as an AP manager.

• Physical port assignment (for all controllers except the Cisco 2500 Series Controllers or Cisco 5500 Series Controller)

• Primary and secondary DHCP servers

• Access control list (ACL) setting, if required

Click Save Configuration.

If you made any changes to the management or virtual interface, reboot the controller so that your changes take effect.

Configuring the Management Interface (CLI)

Step 1

Step 2

Step 3

Enter the show interface detailed management command to view the current management interface settings.

Note

The management interface uses the controller’s factory-set distribution system MAC address.

Enter the config wlan disable wlan-number command to disable each WLAN that uses the management interface for distribution system communication.

Enter these commands to define the management interface: a) Using IPv4 Address

• config interface address management ip-addr ip-netmask gateway

• config interface quarantine vlan management vlan_id

198

Cisco Wireless Controller Configuration Guide, Release 8.3

Interfaces

Note

Use the config interface quarantine vlan management vlan_id command to configure a quarantine

VLAN on the management interface.

• config interface vlan management {vlan-id | 0}

Note

Enter 0 for an untagged VLAN or a nonzero value for a tagged VLAN. We recommend using tagged

VLANs for the management interface.

• config interface ap-manager management {enable | disable} (for Cisco 5500 Series Controllers only)

Note

Use the config interface ap-manager management {enable | disable} command to enable or disable dynamic AP management for the management interface. For Cisco 5500 Series Controllers, the management interface acts like an AP-manager interface by default. If desired, you can disable the management interface as an AP-manager interface and create another dynamic interface as an AP manager.

• config interface port management physical-ds-port-number (for all controllers except the 5500 series)

• config interface dhcp management ip-address-of-primary-dhcp-server [ip-address-of-secondary-dhcp-server]

• config interface acl management access-control-list-name b) Using IPv6 Address

Note

we recommend the APs to be at least one hop away from the Cisco WLC. As the IPv6 packets are always sent to the Gateway, if the AP and WLC are in same subnet, it increases the packet hops and impacts the performance.

• config ipv6 interface address management primary ip-address prefix-length IPv6_Gateway_Address

Note

Once the Primary IPv6 Address, Prefix Length, and Primary IPv6 Gateway are configured on the management interface, they cannot be changed back to default values (:: /128). A configuration backup must be carried out before configuring IPv6 in case the user wants to revert back to IPv4 only management interface.

• config interface quarantine vlan management vlan_id

Note

Use the config interface quarantine vlan management vlan_id command to configure a quarantine

VLAN on the management interface.

• config interface vlan management {vlan-id | 0}

Note

Enter 0 for an untagged VLAN or a nonzero value for a tagged VLAN. We recommend using tagged

VLANs for the management interface.

• config interface ap-manager management {enable | disable} (for Cisco 5500 Series Controllers only)

Note

• config interface port management physical-ds-port-number (for all controllers except the 5500 series)

• config interface dhcp management ip-address-of-primary-dhcp-server [ip-address-of-secondary-dhcp-server]

• config ipv6 interface acl management access-control-list-name

Cisco Wireless Controller Configuration Guide, Release 8.3

199

Interfaces

Step 4

Step 5

Step 6

Step 7

Enter these commands if you want to be able to deploy your Cisco 5500 Series Controller behind a router or other gateway device that is using one-to-one mapping network address translation (NAT):

• config interface nat-address management {enable | disable}

• config interface nat-address management set public_IP_address

NAT allows a device, such as a router, to act as an agent between the Internet (public) and a local network (private). In this case, it maps the controller’s intranet IP addresses to a corresponding external address. The controller’s dynamic

AP-manager interface must be configured with the external NAT IP address so that the controller can send the correct

IP address in the Discovery Response.

Note

These commands are supported for use only with one-to-one-mapping NAT, where each private client has a direct and fixed mapping to a global address. These commands do not support one-to-many NAT, which uses source port mapping to enable a group of clients to be represented by a single IP address.

Enter the save config command.

Enter the show interface detailed management command to verify that your changes have been saved.

If you made any changes to the management interface, enter the reset system command to reboot the controller in order for the changes to take effect.

Virtual Interface

Information About the Virtual Interface

The virtual interface is used to support mobility management, Dynamic Host Configuration Protocol (DHCP) relay, and embedded Layer 3 security such as guest web authentication and VPN termination. It also maintains the DNS gateway host name used by Layer 3 security and mobility managers to verify the source of certificates when Layer 3 web authorization is enabled.

Specifically, the virtual interface plays these two primary roles:

• Acts as the DHCP server placeholder for wireless clients that obtain their IP address from a DHCP server.

• Serves as the redirect address for the web authentication login page.

The virtual interface IP address is used only in communications between the controller and wireless clients.

It never appears as the source or destination address of a packet that goes out a distribution system port and onto the switched network. For the system to operate correctly, the virtual interface IP address must be set (it cannot be 0.0.0.0), and no other device on the network can have the same address as the virtual interface.

Therefore, the virtual interface must be configured with an unassigned and unused gateway IP address. The virtual interface IP address is not pingable and should not exist in any routing table in your network. In addition, the virtual interface cannot be mapped to a physical port.

Restrictions

• All controllers within a mobility group must be configured with the same virtual interface IP address.

Otherwise, inter-controller roaming may appear to work, but the handoff does not complete, and the client loses connectivity for a period of time.

200

Cisco Wireless Controller Configuration Guide, Release 8.3

Interfaces

• When Virtual Interface and Management Interface have the same IP address until the third octet, the

Virtual Interface IP address will change to 0.0.0.0 after Cisco WLC is rebooted. Therefore, we recommend that you use /32 format of the IP address for the Virtual Interface.

Configuring Virtual Interfaces (GUI)

Step 1

Step 2

Step 3

Step 4

Step 5

Choose Controller > Interfaces to open the Interfaces page.

Click Virtual.

The Interfaces > Edit page appears.

Enter the following parameters:

• Any valid unassigned, and unused gateway IP address

• DNS gateway hostname

Note

To ensure connectivity and web authentication, the DNS server should always point to the virtual interface.

If a DNS hostname is configured for the virtual interface, then the same DNS host name must be configured on the DNS server(s) used by the client.

Click Save Configuration.

If you made any changes to the management or virtual interface, reboot the controller so that your changes take effect.

Configuring Virtual Interfaces (CLI)

Step 1

Step 2

Step 3

Step 4

Step 5

Enter the show interface detailed virtual command to view the current virtual interface settings.

Enter the config wlan disable wlan-number command to disable each WLAN that uses the virtual interface for distribution system communication.

Enter these commands to define the virtual interface:

• config interface address virtual ip-address

Note

For ip-address, enter a valid, unassigned, and unused gateway IP address.

• config interface hostname virtual dns-host-name

Enter the reset system command. At the confirmation prompt, enter Y to save your configuration changes to NVRAM.

The controller reboots.

Enter the show interface detailed virtual command to verify that your changes have been saved.

Cisco Wireless Controller Configuration Guide, Release 8.3

201

Interfaces

Service-Port Interfaces

Information About Service-Port Interfaces

The service-port interface controls communications through and is statically mapped by the system to the service port.

The service port can obtain an IPv4 address using DHCP, or it can be assigned a static IPv4 address, but a default gateway cannot be assigned to the service-port interface. Static IPv4 routes can be defined through the controller for remote network access to the service port.

If the service port is in use, the management interface must be on a different supernet from the service-port interface.

Similarly, the service port can be statically assigned an IPv6 address or select an IPv6 address using Stateless

Address Auto-Configuration (SLAAC). The default gateway cannot be assigned to the service-port interface.

Static IPv6 routes can be defined through the controller for remote network access to the service port.

Note

While IPv6 addressing is used along with stateless address auto-configuration, the controller does not perform the subnet verification; however, you must not connect the service-port in the same subnet as the other interfaces in the controller.

Note

This is the only SLAAC interface on the controller, all other interfaces must be statically assigned (just like for IPv4).

Note

User does not require IPv6 static routes to reach service port from the same network, but IPv6 routes requires to access service port from different network. The IPv6 static routes should be as same as IPv4.

Restrictions for Configuring Service-Port Interfaces

• Only Cisco 7500 Series Controllers and Cisco 5500 Series Controllers have a physical service-port interface that is reachable from the external network.

• You must not use the service-port for continuous SNMP polling and management functions except when the management interface of the controller is unreachable.

Configuring Service-Port Interfaces Using IPv4 (GUI)

Step 1

Step 2

Step 3

Choose Controller > Interfaces to open the Interfaces page.

Click the service-port link to open the Interfaces > Edit page.

Enter the Service-Port Interface parameters:

Note

The service-port interface uses the controller’s factory-set service-port MAC address.

202

Cisco Wireless Controller Configuration Guide, Release 8.3

Interfaces

Step 4

Step 5

• DHCP protocol (enabled)

• DHCP protocol (disabled) and IP address and IP netmask

Click Save Configuration to save your changes.

If you made any changes to the management or virtual interface, reboot the controller so that your changes take effect.

Configuring Service-Port Interfaces Using IPv4 (CLI)

Step 1

Step 2

Step 3

Step 4

Step 5

Step 6

To view the current service-port interface settings, enter this command:

show interface detailed service-port

Note

The service-port interface uses the controller’s factory-set service-port MAC address.

Enter these commands to define the service-port interface:

• To configure the DHCP server, enter this command:

config interface dhcp service-port enable

• To disable the DHCP server, enter this command:

config interface dhcp service-port disable

• To configure the IPv4 address, enter this command:

config interface address service-port ip-addr ip-netmask

The service port is used for out-of-band management of the controller. If the management workstation is in a remote subnet, you may need to add a IPv4 route on the controller in order to manage the controller from that remote workstation.

To do so, enter this command:

config route add network-ip-addr ip-netmask gateway

To remove the IPv4 route on the controller, enter this command:

config route delete ip_address

Enter the save config command to save your changes.

Enter the show interface detailed service-port command to verify that your changes have been saved.

Configuring Service-Port Interface Using IPv6 (GUI)

Step 1

Step 2

Step 3

Choose Controller > Interfaces to open the Interfaces page.

Click the service-port link to open the Interfaces > Edit page.

Enter the Service-Port Interface parameters:

Cisco Wireless Controller Configuration Guide, Release 8.3

203

Interfaces

Step 4

Step 5

Note

The service-port interface uses the controller’s factory-set service-port MAC address. Service Port can be statically assigned an address or select an address using SLAAC.

• SLACC(enabled)

• SLACC (disabled) and Primary Address and Prefix Length

Click Save Configuration to save your changes.

If you made any changes to the management or virtual interface, reboot the controller so that your changes take effect.

Configuring Service-Port Interfaces Using IPv6 (CLI)

Step 1

Step 2

Step 3

Step 4

Step 5

Step 6

To view the current service-port interface settings, enter this command:

show interface detailed service-port

Note

The service-port interface uses the controller’s factory-set service-port MAC address.

Enter these commands to define the service-port interface:

• To configure the service port using SLACC , enter this command:

config ipv6 interface slacc service-port enable

• To disable the service port from using SLACC, enter this command:

config ipv6 interface slacc service-port disable

• To configure the IPv6 address, enter this command:

config ipv6 interface address service-port iipv6_address prefix-length

The service port is used for out-of-band management of the controller. If the management workstation is in a remote subnet, you may need to add a route on the controller in order to manage the controller from that remote workstation.

To do so, enter this command:

config ipv6 route add network_ipv6_addr prefix-len ipv6_gw_addr

To remove the IPv6 route on the controller, enter this command:

config ipv6 route delete network _ipv6 addr

Enter the save config command to save your changes.

Enter the show interface detailed service-port command to verify that your changes have been saved.

204

Cisco Wireless Controller Configuration Guide, Release 8.3

Interfaces

Dynamic Interfaces

Information About Dynamic Interface

Dynamic interfaces, also known as VLAN interfaces, are created by users and designed to be analogous to

VLANs for wireless LAN clients. A controller can support up to 512 dynamic interfaces (VLANs). Each dynamic interface is individually configured and allows separate communication streams to exist on any or all of a controller’s distribution system ports. Each dynamic interface controls VLANs and other communications between controllers and all other network devices, and each acts as a DHCP relay for wireless clients associated to WLANs mapped to the interface. You can assign dynamic interfaces to distribution system ports, WLANs, the Layer 2 management interface, and the Layer 3 AP-manager interface, and you can map the dynamic interface to a backup port.

You can configure zero, one, or multiple dynamic interfaces on a distribution system port. However, all dynamic interfaces must be on a different VLAN or IP subnet from all other interfaces configured on the port.

If the port is untagged, all dynamic interfaces must be on a different IP subnet from any other interface configured on the port.

This table lists the maximum number of VLANs supported on the various controller platforms.

Table 10: Maximum number of VLANs supported on Cisco Wireless Controllers

Wireless Controllers

Cisco Virtual Wireless Controller

Cisco Wireless Controller Module for ISR G2

Cisco 2500 Series Wireless Controllers

Cisco 5500 Series Wireless Controller

Cisco Catalyst 6500 Series Wireless Services

Module2 (WiSM2)

Cisco Flex 7500 Series Cloud Controller

Cisco 8500 Series Controller

512

Maximum VLANs

512

4,096

Note

You must not configure a dynamic interface in the same network as that of Local Mobility Anchor (LMA).

If you do so, the GRE tunnel between the controller and LMA does not come up.

Prerequisites for Configuring Dynamic Interfaces

While configuring on the dynamic interface of the controller, you must ensure the following:

Cisco Wireless Controller Configuration Guide, Release 8.3

205

Interfaces

• You must use tagged VLANs for dynamic interfaces.

Restrictions for Configuring Dynamic Interfaces

The following restrictions apply for configuring the dynamic interfaces on the controller:

• Wired clients cannot access management interface of the Cisco WLC 2500 series using the IP address of the AP Manager interface .

• For SNMP requests that come from a subnet that is configured as a dynamic interface, the controller responds but the response does not reach the device that initiated the conversation.

• If you are using DHCP proxy and/or a RADIUS source interface, ensure that the dynamic interface has a valid routable address. Duplicate or overlapping addresses across controller interfaces are not supported.

• You must not use ap-manager as the interface name while configuring dynamic interfaces as ap-manager is a reserved name.

Configuring Dynamic Interfaces (GUI)

Step 1

Step 2

Step 3

Step 4

Step 5

Choose Controller > Interfaces to open the Interfaces page.

Perform one of the following:

• To create a new dynamic interface, click New. The Interfaces > New page appears. Go to Step 3.

• To modify the settings of an existing dynamic interface, click the name of the interface. The Interfaces > Edit page for that interface appears. Go to Step 5.

• To delete an existing dynamic interface, hover your cursor over the blue drop-down arrow for the desired interface and choose Remove.

Enter an interface name and a VLAN identifier, as shown in the figure above.

Note

You cannot enter ap-manager as the interface name while configuring a dynamic interface as ap-manager is a reserved name.

Click Apply to commit your changes. The Interfaces > Edit page appears.

Configure the following parameters:

• Guest LAN, if applicable

• Quarantine and quarantine VLAN ID, if applicable

Note

• Physical port assignment (for all controllers except the 5500 series)

• NAT address (only for Cisco 5500 Series Controllers configured for dynamic AP management)

206

Cisco Wireless Controller Configuration Guide, Release 8.3

Interfaces

Step 6

Step 7

Note

Select the Enable NAT Address check box and enter the external NAT IP address if you want to be able to deploy your Cisco 5500 Series Controller behind a router or other gateway device that is using one-to-one mapping network address translation (NAT). NAT allows a device, such as a router, to act as an agent between the Internet (public) and a local network (private). In this case, it maps the controller’s intranet

IP addresses to a corresponding external address. The controller’s dynamic AP-manager interface must be configured with the external NAT IP address so that the controller can send the correct IP address in the Discovery Response.

• Dynamic AP management

Note

When you enable this feature, this dynamic interface is configured as an AP-manager interface (only one

AP-manager interface is allowed per physical port). A dynamic interface that is marked as an AP-manager interface cannot be used as a WLAN interface.

Set the APs in a VLAN that is different than the dynamic interface configured on the controller. If the APs are in the same VLAN as the dynamic interface, the APs are not registered on the controller and the

“LWAPP discovery rejected” and “Layer 3 discovery request not received on management VLAN” errors are logged on the controller.

• VLAN identifier

• Fixed IP address, IP netmask, and default gateway

Note

Enter valid IP addresses in these fields.

• Primary and secondary DHCP servers

• Access control list (ACL) name, if required

Note

To ensure proper operation, you must set the Port Number and Primary DHCP Server parameters.

Click Save Configuration to save your changes.

Repeat this procedure for each dynamic interface that you want to create or edit.

Configuring Dynamic Interfaces (CLI)

Step 1

Step 2

Step 3

Step 4

Enter the show interface summary command to view the current dynamic interfaces.

View the details of a specific dynamic interface by entering this command:

show interface detailed operator_defined_interface_name.

Note

Interface names that contain spaces must be enclosed in double quotes. For example: config interface create

"vlan 25"

Enter the config wlan disable wlan_id command to disable each WLAN that uses the dynamic interface for distribution system communication.

Enter these commands to configure dynamic interfaces:

Cisco Wireless Controller Configuration Guide, Release 8.3

207

Interfaces

Step 5

Step 6

Step 7

Step 8

• config interface create operator_defined_interface_name {vlan_id | x}

• config interface address interface ip_addr ip_netmask [gateway]

• config interface vlan operator_defined_interface_name {vlan_id | o}

• config interface port operator_defined_interface_name physical_ds_port_number

• config interface ap-manager operator_defined_interface_name {enable | disable}

Note

Use the config interface ap-manager operator_defined_interface_name {enable | disable} command to enable or disable dynamic AP management. When you enable this feature, this dynamic interface is configured as an AP-manager interface (only one AP-manager interface is allowed per physical port). A dynamic interface that is marked as an AP-manager interface cannot be used as a WLAN interface. You cannot use ap-manager as the operator_defined_interface_name while configuring a dynamic interface as ap-manager is a reserved name.

• config interface dhcp operator_defined_interface_name ip_address_of_primary_dhcp_server

[ip_address_of_secondary_dhcp_server]

• config interface quarantine vlan interface_name vlan_id

Note

Use the config interface quarantine vlan interface_name vlan_id command to configure a quarantine

VLAN on any interface.

• config interface acl operator_defined_interface_name access_control_list_name

Enter these commands if you want to be able to deploy your Cisco 5500 Series Controller behind a router or other gateway device that is using one-to-one mapping network address translation (NAT):

• config interface nat-address dynamic-interface operator_defined_interface_name {enable | disable}

• config interface nat-address dynamic-interface operator_defined_interface_name set public_IP_address

AP-manager interface must be configured with the external NAT IP address so that the controller can send the correct

IP address in the Discovery Response.

Note

These commands are supported for use only with one-to-one-mapping NAT, whereby each private client has a direct and fixed mapping to a global address. These commands do not support one-to-many NAT, which uses source port mapping to enable a group of clients to be represented by a single IP address.

Enter the config wlan enable wlan_id command to reenable each WLAN that uses the dynamic interface for distribution system communication.

Enter the save config command to save your changes.

Enter the show interface detailed operator_defined_interface_name command and show interface summary command to verify that your changes have been saved.

Note

If desired, you can enter the config interface delete operator_defined_interface_name command to delete a dynamic interface.

208

Cisco Wireless Controller Configuration Guide, Release 8.3

Interfaces

AP-Manager Interface

Information About AP-Manager Interface

A controller configured with IPv4 has one or more AP-manager interfaces, which are used for all Layer 3 communications between the controller and lightweight access points after the access points have joined the controller.

Note

Release 8.2 does not support multiple non-AP Manager dynamic interfaces, untagged management interfaces, management interfaces mapped to physical ports, and non-LAG scenarios.

Note

A controller configured with IPv6 has only one AP-manager and is applicable on management interface.

You cannot remove the AP-manager configured on management interface.

The AP-manager IP address is used as the tunnel source for CAPWAP packets from the controller to the access point and as the destination for CAPWAP packets from the access point to the controller.

Note

The controller does not support transmitting the jumbo frames. To avoid having the controller transmit

CAPWAP packets to the AP that will necessitate fragmentation and reassembly, reduce MTU/MSS on the client side.

The AP-manager interface communicates through any distribution system port by listening across the Layer

3 network for access point CAPWAP or LWAPP join messages to associate and communicate with as many lightweight access points as possible.

A controller configured with IPv6 does not support Dynamic AP-Manager. By default, the management interface acts like an AP-manager interface. Link Aggregation (LAG) is used for IPv6 AP load balancing.

Restrictions for Configuring AP Manager Interface

• For IPv4—The MAC address of the management interface and the AP-manager interface is the same as the base LAG MAC address.

• If only one distribution system port can be used, you should use distribution system port 1.

• An AP-manager interface is not required to be configured. The management interface acts like an

AP-manager interface by default, and the access points can join on this interface.

• If link aggregation (LAG) is enabled, there can be only one AP-manager interface. But when LAG is disabled, one or more AP-manager interfaces can be created, generally one per physical port.

◦When LAG is enabled—Supports only one AP Manager, which can either be on the management or dynamic interface with AP management.

◦When LAG is disabled—Supports one AP Manager per port. The Dynamic Interface tied to a

VLAN can act as an AP Manager (when enabled).

Cisco Wireless Controller Configuration Guide, Release 8.3

209

Interfaces

Note

When you enable LAG, all the ports would lose their AP Manager status and the AP management reverts back onto the Management interface.

• Port redundancy for the AP-manager interface is not supported. You cannot map the AP-manager interface to a backup port.

Configuring the AP-Manager Interface (GUI)

Step 1

Step 2

Step 3

Step 4

Step 5

Choose Controller > Interfaces to open the Interfaces page.

Click AP-Manager Interface.

The Interface > Edit page appears.

Note

For IPv6 only—A controller configured with IPv6 address does not support Dynamic AP-Manager. By default, the management interface acts like an AP-manager interface.

Set the AP-Manager Interface parameters:

Note

For Cisco 5500 Series Controllers, you are not required to configure an AP-manager interface. The management interface acts like an AP-manager interface by default.

• Physical port assignment

• VLAN identifier

Note

Enter 0 for an untagged VLAN or a nonzero value for a tagged VLAN. We recommend using tagged

VLANs for the AP-manager interface.

Note

The gig/wired subinterface is numbered with VLAN number and dot11 subinterface is numbered with the

WLAN ID. The first configured WLAN becomes dot11 0.1 & dot11 1.1 and second WLAN ID subinterface becomes dot11 0.2 & dot11 1.2 onwards. This dot11 sub interface number cannot be mapped with a VLAN

ID because multiple WLAN can be assigned with a same VLAN number. We cannot have duplicate subinterface created in the system. The native subinterface configuration in wired interface is the AP native

VLAN configuration, if VLAN support is enabled in FlexConnect mode or else the native interface is always gig prime interface in AP(Local / Flex with no VLAN support).

• Fixed IP address, IP netmask, and default gateway

• Primary and secondary DHCP servers

• Access control list (ACL) name, if required

Click Save Configuration to save your changes.

If you made any changes to the management or virtual interface, reboot the controller so that your changes take effect.

210

Cisco Wireless Controller Configuration Guide, Release 8.3

Interfaces

Configuring the AP Manager Interface (CLI)

Before You Begin

For Cisco 5500 Series Controllers, you are not required to configure an AP-manager interface. The management interface acts like an AP-manager interface by default.

Note

A controller configured with IPv6 address does not support Dynamic AP-Manager. The management interface acts like an AP-manager interface by default.

Step 1

Step 2

Step 3

Step 4

Step 5

Step 6

Enter the show interface summary command to view the current interfaces.

Note

If the system is operating in Layer 2 mode, the AP-manager interface is not listed.

Enter the show interface detailed ap-manager command to view the current AP-manager interface settings.

Enter the config wlan disable wlan-number command to disable each WLAN that uses the AP-manager interface for distribution system communication.

Enter these commands to define the AP-manager interface:

• config interface address ap-manager ip-addr ip-netmask gateway

• config interface vlan ap-manager {vlan-id | 0}

Note

Enter 0 for an untagged VLAN or a nonzero value for a tagged VLAN. We recommend using tagged

VLANs for the AP-manager interface.

• config interface port ap-manager physical-ds-port-number

• config interface dhcp ap-manager ip-address-of-primary-dhcp-server [ip-address-of-secondary-dhcp-server]

• config interface acl ap-manager access-control-list-name

Enter the save config command to save your changes.

Enter the show interface detailed ap-manager command to verify that your changes have been saved.

Configuration Example: Configuring AP-Manager on a Cisco 5500 Series Controller

For a Cisco 5500 Series Controller, we recommend that you have eight dynamic AP-manager interfaces and associate them to the eight Gigabit ports of the controller when LAG is not used. If you are using the management interface, which acts like an AP-manager interface by default, you must create only seven more dynamic AP-manager interfaces and associate them to the remaining seven Gigabit ports.

Note

For IPv6 only—A controller configured with IPv6 address does not support Dynamic AP-Manager. By default, the management interface acts like an AP-manager interface. Use LAG for IPv6 AP load balancing.

Cisco Wireless Controller Configuration Guide, Release 8.3

211

Interfaces

This figure shows a dynamic interface that is enabled as a dynamic AP-manager interface and associated to port number 2.

Figure 23: Dynamic Interface Example with Dynamic AP Management

212

Cisco Wireless Controller Configuration Guide, Release 8.3

Interfaces

This figure shows a Cisco 5500 Series Controller with LAG disabled, the management interface used as one dynamic AP-manager interface, and seven additional dynamic AP-manager interfaces, each mapped to a different Gigabit port.

Figure 24: Cisco 5500 Series Controller Interface Configuration Example

Multiple AP-Manager Interfaces

Information About Multiple AP-Manager Interfaces

When you create two or more AP-manager interfaces, each one is mapped to a different port. The ports should be configured in sequential order so that AP-manager interface 2 is on port 2, AP-manager interface 3 is on port 3, and AP-manager interface 4 is on port 4.

Before an access point joins a controller, it sends out a discovery request. From the discovery response that it receives, the access point can tell the number of AP-manager interfaces on the controller and the number of access points on each AP-manager interface. The access point generally joins the AP-manager with the least number of access points. In this way, the access point load is dynamically distributed across the multiple

AP-manager interfaces.

Note

Access points may not be distributed completely evenly across all of the AP-manager interfaces, but a certain level of load balancing occurs.

Restrictions on Configuring Multiple AP Manager Interfaces

The following restrictions apply while configuring the multiple AP manager interfaces in the controller:

• You must assign an AP-manager interface to each port on the controller.

• Before implementing multiple AP-manager interfaces, you should consider how they would impact your controller’s port redundancy.

• AP-manager interfaces do not need to be on the same VLAN or IP subnet, and they may or may not be on the same VLAN or IP subnet as the management interface. However, we recommend that you configure all AP-manager interfaces on the same VLAN or IP subnet.

• If the port of one of the AP-manager interfaces fails, the controller clears the state of the access points, and the access points must reboot to reestablish communication with the controller using the normal controller join process. The controller no longer includes the failed AP-manager interface in the CAPWAP or LWAPP discovery responses. The access points then rejoin the controller and are load balanced among the available AP-manager interfaces.

Cisco Wireless Controller Configuration Guide, Release 8.3

213

Interfaces

In the case of management interface, because there is support for backup port, APs already connected to management interface continue to be in connected state (falling to backup port) rather than dropping off. However, AP-Mgr will get disabled any new APs will associate with the current AP-Mgr.

Creating Multiple AP-Manager Interfaces (GUI)

Step 1

Step 2

Step 3

Step 4

Step 5

Step 6

Step 7

Step 8

Choose Controller > Interfaces to open the Interfaces page.

Click New.

The Interfaces > New page appears.

Enter an AP-manager interface name and a VLAN identifier.

Click Apply to commit your changes. The Interfaces > Edit page appears.

Enter the appropriate interface parameters.

Note

Every interface supports primary and backup port with the following exceptions

• Dynamic interface is converted to AP manager which does not support backup of port configuration.

• If AP manager is enabled on management interface and when management interface moves to backup port because of primary port failure, the AP manager will be disabled.

To make this interface an AP-manager interface, select the Enable Dynamic AP Management check box.

Note

Only one AP-manager interface is allowed per physical port. A dynamic interface that is marked as an AP-manager interface cannot be used as a WLAN interface.

Click Save Configuration to save your settings.

Repeat this procedure for each additional AP-manager interface that you want to create.

Creating Multiple AP-Manager Interfaces (CLI)

Step 1

Step 2

Enter these commands to create a new interface:

• config interface create operator_defined_interface_name {vlan_id | x}

• config interface address operator_defined_interface_name ip_addr ip_netmask [gateway]

• config interface vlan operator_defined_interface_name {vlan_id | o}

• config interface port operator_defined_interface_name physical_ds_port_number

• config interface dhcp operator_defined_interface_name ip_address_of_primary_dhcp_server

[ip_address_of_secondary_dhcp_server]

• config interface quarantine vlan interface_name vlan_id

Note

Use this command to configure a quarantine VLAN on any interface.

• config interface acl operator_defined_interface_name access_control_list_name

To make this interface an AP-manager interface, enter this command:

{config interface ap-manager operator_defined_interface_name enable | disable}

214

Cisco Wireless Controller Configuration Guide, Release 8.3

Interfaces

Step 3

Step 4

Note

Only one AP-manager interface is allowed per physical port. A dynamic interface that is marked as an AP-manager interface cannot be used as a WLAN interface.

Enter save config command to save your changes.

Repeat this procedure for each additional AP-manager interface that you want to create.

Interface Groups

Information About Interface Groups

Interface groups are logical groups of interfaces. Interface groups facilitate user configuration where the same interface group can be configured on multiple WLANs or while overriding a WLAN interface per AP group.

An interface group can exclusively contain either quarantine or nonquarantine interfaces. An interface can be part of multiple interface groups.

A WLAN can be associated with an interface or interface group. The interface group name and the interface name cannot be the same.

This feature also enables you to associate a client to specific subnets based on the foreign controller that they are connected to. The anchor controller WLAN can be configured to maintain a mapping between foreign controller MAC and a specific interface or interface group (Foreign maps) as needed. If this mapping is not configured, clients on that foreign controller gets VLANs associated in a round robin fashion from interface group configured on WLAN.

You can also configure AAA override for interface groups. This feature extends the current access point group and AAA override architecture where access point groups and AAA override can be configured to override the interface group WLAN that the interface is mapped to. This is done with multiple interfaces using interface groups.

This feature enables network administrators to configure guest anchor restrictions where a wireless guest user at a foreign location can obtain an IP address from multiple subnets on the foreign location and controllers from within the same anchor controller.

Controller marks VLAN as dirty when the clients are unable to receive IP address using DHCP. The VLAN interface is marked as dirty based on two methods:

Aggressive Method—When only one failure is counted per association per client and controller marks VLAN as dirty interface when a failure occurs three times for a client or for three different clients.

Non-Aggressive Method—When only one failure is counted per association per client and controller marks

VLAN as a dirty interface only when three or more clients fail.

Restrictions on Configuring Interface Groups

• The priority order for configuring VLAN interface select for WLAN is:

◦AAA override

◦AP group

◦DHCP server override

◦Interface group

Cisco Wireless Controller Configuration Guide, Release 8.3

215

Interfaces

• While you configure VLAN-ACL mapping using the native VLAN identifier as part of Flex group configuration, the ACL mapping does not take place. However, if you use the same VLAN to configure

ACL mapping at the access point level, the configuration is allowed.

Creating Interface Groups (GUI)

Step 1

Step 2

Step 3

Step 4

Choose Controller > Interface Groups.

The Interface Groups page appears with the list of interface groups already created.

Note

To remove an interface group, hover your mouse pointer over the blue drop-down icon and choose Remove.

Click Add Group.

The Add New Interface Group page appears.

Enter the details of the interface group:

• Interface Group Name—Specify the name of the interface group.

• Description—Add a brief description of the interface group.

Click Add.

Creating Interface Groups (CLI)

• config interface group {create | delete} interface_group_name—Creates or deletes an interface group

• config interface group description interface_group_name description—Adds a description to the interface group

Adding Interfaces to Interface Groups (GUI)

Step 1

Step 2

Step 3

Step 4

Step 5

Choose Controller > Interface Groups.

The Interface Groups page appears with a list of all interface groups.

Click the name of the interface group to which you want to add interfaces.

The Interface Groups > Edit page appears.

Choose the interface name that you want to add to this interface group from the Interface Name drop-down list.

Click Add Interface to add the interface to the Interface group.

Repeat Steps 2 and 3 if you want to add multiple interfaces to this interface group.

Note

To remove an interface from the interface group, hover your mouse pointer over the blue drop-down arrow and choose Remove.

216

Cisco Wireless Controller Configuration Guide, Release 8.3

Interfaces

Adding Interfaces to Interface Groups (CLI)

To add interfaces to interface groups, use the config interface group interface add interface_group

interface_name command.

Viewing VLANs in Interface Groups (CLI)

To view a list of VLANs in the interface groups, use the show interface group detailed interface-group-name command.

Adding an Interface Group to a WLAN (GUI)

Step 1

Step 2

Step 3

Step 4

Choose the WLAN tab.

The WLANs page appears listing the available WLANs.

Click the WLAN ID of the WLAN to which you want to add the interface group.

In the General tab, choose the interface group from the Interface/Interface Group (G) drop-down list.

Click Apply.

Note

Suppose that the interface group that you add to a WLAN has RADIUS Server Overwrite interface enabled. In this case, when a client requests for authentication, the controller selects the first IP address from the interface group as the RADIUS server.

Adding an Interface Group to a WLAN (CLI)

To add an interface group to a WLAN, enter the config wlan interface wlan_id interface_group_name command.

Cisco Wireless Controller Configuration Guide, Release 8.3

217

Interfaces

218

Cisco Wireless Controller Configuration Guide, Release 8.3

C H A P T E R

IPv6

•

Prerequisites for Configuring IPv6 Mobility, page 219

•

Restrictions for Configuring IPv6 Mobility, page 219

•

Information About IPv6 Mobility, page 220

•

Configuring IPv6 Globally, page 221

•

Configuring RA Guard for IPv6 Clients, page 221

•

Configuring RA Throttling for IPv6 Clients, page 222

Prerequisites for Configuring IPv6 Mobility

• Up to eight client addresses can be tracked per client.

• To allow stateful DHCPv6 IP addressing to operate properly, you must have a switch or router that supports the DHCP for IPv6 feature that is configured to act like a DHCPv6 server, or you need a dedicated server such as a Windows 2008 server with a built-in DHCPv6 server.

To support the seamless IPv6 Mobility, you might need to configure the following:

• Configuring RA Guard for IPv6 Clients

• Configuring RA Throttling for IPv6 Clients

• Configuring IPv6 Neighbor Discovery Caching

Restrictions for Configuring IPv6 Mobility

• Clients must support IPv6 with either static stateless auto configuration (such as Windows XP clients) or stateful DHCPv6 IP addressing (such as Windows Vista clients).

Cisco Wireless Controller Configuration Guide, Release 8.3

219

Information About IPv6 Mobility

Note

Currently, Windows Vista does not provide static stateless auto configuration functionality. Therefore, DHCPv6 is required for seamless roaming. Otherwise, these clients must manually renew their address after each change of VLANs.

Note

The Dynamic VLAN function for IPv6 is not supported.

• Roaming of IPv6 clients that are associated with a WLAN that is mapped to an untagged interface to another WLAN that is mapped to a tagged interface is not supported.

• On the 7.4 release, the WLCs that have the same mobility group, same VLAN ID, and different IPv4 and IPv6 subnets, generate different IPv6 router advertisements. WLAN on these WLCs is assigned to the same dynamic interface with the same VLAN ID on all the controllers. The client receives correct

IPv4 address; however it receives a router advertisement from the different subnets that reach the other

WLCs. There could be issue of no traffic from the client, because the first given IPv6 address to the client does not match to the subnet for the IPv4 address. To resolve this, you can configure the WLCs in different mobility group.

Note

While adding or deleting IPv6 mobility peer, the SSH rules for bypassing traffic are applicable for the 16666 port and for the pairs of IPs of the mobility peers.

• When AAA override is enabled on WLAN with flex local switching, the client must receive the IPv6 address from the VLAN returned by the AAA server. This implies that if a WLAN with both local switching and AAA override enabled is mapped to VLAN X and the AAA server returns a VLAN Y; then, the client must receive an address from VLAN Y. However, this is not supported in this controller release.

Note

IPv6 ping from Cisco WLC to a client is not supported if the client is in the management subnet.

• In Cisco 2504 WLC with directly connected APs, client IPv6 is not supported. ( CSCvf51290 )

Information About IPv6 Mobility

Internet Protocol version 6 (IPv6) is the next-generation network layer Internet protocol intended to replace version 4 (IPv4) in the TCP/IP suite of protocols. This new version increases the Internet global address space to accommodate users and applications that require unique global IP addresses. IPv6 incorporates 128-bit source and destination addresses, which provide significantly more addresses than the 32-bit IPv4 addresses.

To support IPv6 clients across controllers, ICMPv6 messages must be dealt with specially to ensure the IPv6 client remains on the same Layer 3 network. The controllers keep track of IPv6 clients by intercepting the

ICMPv6 messages to provide seamless mobility and protect the network from network attacks. The ICMPv6 packets are converted from multicast to unicast and delivered individually per client. This process allows

220

Cisco Wireless Controller Configuration Guide, Release 8.3

Configuring IPv6 Globally

more control. Specific clients can receive specific Neighbor Discovery and Router Advertisement packets, which ensures correct IPv6 addressing and avoids unnecessary multicast traffic.

The configuration for IPv6 mobility is the same as IPv4 mobility and requires no separate software on the client side to achieve seamless roaming. The controllers must be part of the same mobility group. Both IPv4 and IPv6 client mobility are enabled by default.

Configuring IPv6 Globally

Configuring IPv6 Globally (GUI)

Step 1

Step 2

Step 3

Step 4

Choose Controller > General.

From the Global IPv6 Config drop-down list, choose Enabled or Disabled.

Click Apply.

Click Save Configuration.

Configuring IPv6 Globally (CLI)

• Enable or disable IPv6 globally by entering this command:

config ipv6 {enable | disable}

Configuring RA Guard for IPv6 Clients

Information About RA Guard

IPv6 clients configure IPv6 addresses and populate their router tables based on IPv6 Router Advertisement

(RA) packets. The RA Guard feature is similar to the RA guard feature of wired networks. RA Guard increases the security of the IPv6 network by dropping the unwanted or rogue RA packets that come from wireless clients. If this feature is not configured, malicious IPv6 clients could announce themselves as the router for the network, which would take higher precedence over legitimate IPv6 routers.

RA Guard occurs at the controller. You can configure the controller to drop RA messages at the access point or at the controller. By default, RA Guard is configured at the access point and also enabled in the controller.

All IPv6 RA messages are dropped, which protects other wireless clients and upstream wired network from malicious IPv6 clients.

Note

• IPv6 RA guard feature works on wireless clients only. This feature does not work on wired guest access (GA).

• RA guard is also supported in FlexConnect local switching mode.

Cisco Wireless Controller Configuration Guide, Release 8.3

221

Configuring RA Throttling for IPv6 Clients

Configuring RA Guard (GUI)

Step 1

Step 2

Step 3

Step 4

Choose Controller > IPv6 > RA Guard to open the IPv6 RA Guard page. By default the IPv6 RA Guard on AP is enabled.

From the drop-down list, choose Disable to disable RA Guard. The controller also displays the clients that have been identified as sending RA packets.

Click Apply to commit your changes.

Click Save Configuration to save your changes.

Configuring RA Guard (CLI)

Use this command to configure RA Guard:

config ipv6 ra-guard ap {enable | disable}

Configuring RA Throttling for IPv6 Clients

Information about RA Throttling

RA throttling allows the controller to enforce limits to RA packets headed toward the wireless network. By enabling RA throttling, routers that send many RA packets can be trimmed to a minimum frequency that will still maintain an IPv6 client connectivity. If a client sends an RS packet, then an RA is sent back to the client.

This is allowed through the controller and unicasted to the client. This process ensures that the new clients or roaming clients are not affected by the RA throttling.

Configuring RA Throttling (GUI)

Step 1

Step 2

Choose Controller > IPv6 > RA Throttle Policy page. By default the IPv6 RA Throttle Policy is disabled. Unselect the check box to disable RA throttle policy.

Configure the following parameters:

• Throttle period—The period of time for throttling. RA throttling takes place only after the Max Through limit is reached for the VLAN or the Allow At-Most value is reached for a particular router. The range is from 10 seconds to 86400 seconds. The default is 600 seconds.

• Max Through—The maximum number of RA packets on a VLAN that can be sent before throttling takes place.

The No Limit option allows an unlimited number of RA packets through with no throttling. The range is from 0 to 256 RA packets. The default is 10 RA packets.

• Interval Option—This option allows the controller to act differently based on the RFC 3775 value set in IPv6 RA packets.

222

Cisco Wireless Controller Configuration Guide, Release 8.3

Configuring RA Throttling for IPv6 Clients

Step 3

Step 4

◦Passthrough— Allows any RA messages with the RFC 3775 interval option to go through without throttling.

◦Ignore—Causes the RA throttle to treat packets with the interval option as a regular RA and subject to throttling if in effect.

◦Throttle—Causes the RA packets with the interval option to always be subject to rate limiting.

• Allow At-least—The minimum number of RA packets per router that can be sent as multicast before throttling takes place. The range is from 0 to 32 RA packets.

• Allow At-most—The maximum number of RA packets per router that can be sent as multicast before throttling takes place. The No Limit option allows an unlimited number of RA packets through the router. The range is from

0 to 256 RA packets.

Note

When RA throttling occurs, only the first IPv6 capable router is allowed through. For networks that have multiple IPv6 prefixes being served by different routers, you should disable RA throttling.

Click Apply to commit your changes.

Click Save Configuration to save your changes.

Configuring the RA Throttle Policy (CLI)

Use this command to configure the RA throttle policy:

config ipv6 neigbhor-binding ra-throttle {allow at-least at-least-value | enable | disable | interval-option

{ ignore | passthrough | throttle} | max-through {max-through-value | no-limit}}

Cisco Wireless Controller Configuration Guide, Release 8.3

223

Configuring RA Throttling for IPv6 Clients

224

Cisco Wireless Controller Configuration Guide, Release 8.3

C H A P T E R

Access Control Lists

•

Information About Access Control Lists, page 225

•

Restrictions on Access Control Lists, page 226

•

Configuring and Applying Access Control Lists (GUI), page 227

•

Configuring and Applying Access Control Lists (CLI), page 231

•

Configuring Layer 2 Access Control Lists, page 232

•

Configuring DNS-based Access Control Lists, page 237

•

Configuring URL Filtering, page 239

Information About Access Control Lists

An Access Control List (ACL) is a set of rules used to limit access to a particular interface (for example, if you want to restrict a wireless client from pinging the management interface of the controller). After ACLs are configured on the controller, they can be applied to the management interface, the AP-manager interface, any of the dynamic interfaces, or a WLAN to control data traffic to and from wireless clients or to the controller central processing unit (CPU) to control all traffic destined for the CPU.

You may also want to create a preauthentication ACL for web authentication. Such an ACL could be used to allow certain types of traffic before authentication is complete.

Both IPv4 and IPv6 ACL are supported. IPv6 ACLs support the same options as IPv4 ACLs including source, destination, source and destination ports.

Note

You can enable only IPv4 traffic in your network by blocking IPv6 traffic. That is, you can configure an

IPv6 ACL to deny all IPv6 traffic and apply it on specific or all WLANs.

Cisco Wireless Controller Configuration Guide, Release 8.3

225

Restrictions on Access Control Lists

Restrictions on Access Control Lists

• You can define up to 64 ACLs, each with up to 64 rules (or filters) for both IPv4 and IPv6. Each rule has parameters that affect its action. When a packet matches all of the parameters for a rule, the action set for that rule is applied to the packet.

• When you apply CPU ACLs on a Cisco 5508 WLC or a Cisco WiSM2, you must permit traffic towards the virtual interface IP address for web authentication.

• All ACLs have an implicit “deny all rule” as the last rule. If a packet does not match any of the rules, it is dropped by the controller.

• If you are using an external web server with a Cisco 5508 WLC or a WLC network module, you must configure a preauthentication ACL on the WLAN for the external web server.

• If you apply an ACL to an interface or a WLAN, wireless throughput is degraded when downloading from a 1-Gbps file server. To improve throughput, remove the ACL from the interface or WLAN, move the ACL to a neighboring wired device with a policy rate-limiting restriction, or connect the file server using 100 Mbps rather than 1 Gbps.

• Multicast traffic received from wired networks that is destined to wireless clients is not processed by

WLC ACLs. Multicast traffic initiated from wireless clients, destined to wired networks or other wireless clients on the same controller, is processed by WLC ACLs.

• ACLs are configured on the controller directly or configured through Cisco Prime Infrastructure templates.

The ACL name must be unique.

• You can configure ACL per client (AAA overridden ACL) or on either an interface or a WLAN. The

AAA overridden ACL has the highest priority. However, each interface, WLAN, or per client ACL configuration that you apply can override one another.

• If peer-to-peer blocking is enabled, traffic is blocked between peers even if the ACL allows traffic between them.

• Authentication traffic has to go through the Cisco WLC for this feature to be supported, even if DNS-based

ACL is local to the AP.

• When you create an ACL, it is recommended to perform the two actions (create an ACL or ACL rule and apply the ACL or ACL rule) continuously either from CLI or GUI.

• In Cisco Wireless Releases prior to 8.0.100.0, the behavior of the Redirect-URL-ACL (as returned via

RADIUS attributes) may have been incorrect. The ACL was applied in only the Ingress direction (traffic destined for the LAN or distribution system) of the radio interface. These ACLs should also be applied in the Egress direction (traffic destined for the wireless client). Therefore, after upgrading to a Cisco

Wireless Release 8.0 or a later release, you may need to adjust the ACL to accommodate the correction of this behavior.

• Mobility pings on ports 16666 and 16667 are notable exemptions and these ports cannot be blocked by any ACL.

226

Cisco Wireless Controller Configuration Guide, Release 8.3

Configuring and Applying Access Control Lists (GUI)

Note

ACL ID 0 is not supported in Cisco WLC. Foreign WLC does not send url-redirect-acl to anchor WLC if the received ACL attribute from RADIUS/ISE is mapped to ACL ID 0. It causes web redirect failure on wireless client later.

Configuring and Applying Access Control Lists (GUI)

Configuring Access Control Lists

Step 3

Step 4

Step 5

Step 6

Step 7

Step 8

Step 1

Step 2

Choose Security > Access Control Lists > Access Control Lists to open the Access Control Lists page.

If you want to see if packets are hitting any of the ACLs configured on your controller, select the Enable Counters check box and click Apply. Otherwise, leave the check box unselected, which is the default value. This feature is useful when troubleshooting your system.

Note

If you want to clear the counters for an ACL, hover your cursor over the blue drop-down arrow for that ACL and choose Clear Counters.

Add a new ACL by clicking New. The Access Control Lists > New page appears.

In the Access Control List Name text box, enter a name for the new ACL. You can enter up to 32 alphanumeric characters.

Choose the ACL type. There are two types of ACL supported, IPv4 and IPv6.

Click Apply. When the Access Control Lists page reappears, click the name of the new ACL.

When the Access Control Lists > Edit page appears, click Add New Rule. The Access Control Lists > Rules > New page appears.

Configure a rule for this ACL as follows: a) The controller supports up to 64 rules for each ACL. These rules are listed in order from 1 to 64. In the Sequence text box, enter a value (between 1 and 64) to determine the order of this rule in relation to any other rules defined for this ACL.

Note

If rules 1 through 4 are already defined and you add rule 29, it is added as rule 5. If you add or change a sequence number for a rule, the sequence numbers for other rules adjust to maintain a continuous sequence.

For instance, if you change a rule’s sequence number from 7 to 5, the rules with sequence numbers 5 and 6 are automatically reassigned as 6 and 7, respectively.

b) From the Source drop-down list, choose one of these options to specify the source of the packets to which this ACL applies:

• Any—Any source (this is the default value).

• IP Address—A specific source. If you choose this option, enter the IP address and netmask of the source in the text boxes. If you are configuring IPv6 ACL, enter the IPv6 address and prefix length of the destination in the text boxes.

c) From the Destination drop-down list, choose one of these options to specify the destination of the packets to which this ACL applies:

• Any—Any destination (this is the default value).

Cisco Wireless Controller Configuration Guide, Release 8.3

227

Configuring and Applying Access Control Lists (GUI)

• IP Address—A specific destination. If you choose this option, enter the IP address and netmask of the destination in the text boxes. If you are configuring IPv6 ACL, enter the IPv6 address and prefix length of the destination in the text boxes.

d) From the Protocol drop-down list, choose the protocol ID of the IP packets to be used for this ACL. These are the protocol options:

• Any—Any protocol (this is the default value)

• TCP—Transmission Control Protocol

• UDP—User Datagram Protocol

• ICMP/ICMPv6—Internet Control Message Protocol

Note

ICMPv6 is only available for IPv6

ACL.

• ESP—IP Encapsulating Security Payload

• AH—Authentication Header

• GRE—Generic Routing Encapsulation

• IP in IP—Internet Protocol (IP) in IP (permits or denies IP-in-IP packets)

• Eth Over IP—Ethernet-over-Internet Protocol

• OSPF—Open Shortest Path First

• Other—Any other Internet Assigned Numbers Authority (IANA) protocol

Note

If you choose Other, enter the number of the desired protocol in the Protocol text box. You can find the list of available protocols in the INAI website.

The controller can permit or deny only IP packets in an ACL. Other types of packets (such as ARP packets) cannot be specified.

e) If you chose TCP or UDP in the previous step, two additional parameters appear: Source Port and Destination Port.

These parameters enable you to choose a specific source port and destination port or port ranges. The port options are used by applications that send and receive data to and from the networking stack. Some ports are designated for certain applications such as Telnet, SSH, HTTP, and so on.

Note

Source and Destination ports based on the ACL type.

f) From the DSCP drop-down list, choose one of these options to specify the differentiated services code point (DSCP) value of this ACL. DSCP is an IP header text box that can be used to define the quality of service across the Internet.

• Any—Any DSCP (this is the default value)

• Specific—A specific DSCP from 0 to 63, which you enter in the DSCP edit box g) From the Direction drop-down list, choose one of these options to specify the direction of the traffic to which this

ACL applies:

• Any—Any direction (this is the default value)

• Inbound—From the client

• Outbound—To the client

228

Cisco Wireless Controller Configuration Guide, Release 8.3

Configuring and Applying Access Control Lists (GUI)

Step 9

Step 10

Note

If you are planning to apply this ACL to the controller CPU, the packet direction does not have any significance, it is always ‘Any’.

h) From the Action drop-down list, choose Deny to cause this ACL to block packets or Permit to cause this ACL to allow packets. The default value is Deny.

i) Click Apply to commit your changes. The Access Control Lists > Edit page reappears, showing the rules for this

ACL.

The Deny Counters fields shows the number of times that packets have matched the explicit deny ACL rule. The

Number of Hits field shows the number of times that packets have matched an ACL rule. You must enable ACL counters on the Access Control Lists page to enable these fields.

Note

If you want to edit a rule, click the sequence number of the desired rule to open the Access Control Lists

> Rules > Edit page. If you want to delete a rule, hover your cursor over the blue drop-down arrow for the desired rule and choose Remove.

j) Repeat this procedure to add any additional rules for this ACL.

Click Save Configuration to save your changes.

Repeat this procedure to add any additional ACLs.

Applying an Access Control List to an Interface

Step 1

Step 2

Step 3

Step 4

Choose Controller > Interfaces.

Click the name of the desired interface. The Interfaces > Edit page for that interface appears.

Choose the desired ACL from the ACL Name drop-down list and click Apply. The default is None.

Note

Only IPv4 ACL are supported as interface

ACL.

Click Save Configuration to save your changes.

Applying an Access Control List to the Controller CPU

Step 1

Step 2

Step 3

Choose Security > Access Control Lists > CPU Access Control Lists to open the CPU Access Control Lists page.

Select the Enable CPU ACL check box to enable a designated ACL to control the IPv4 traffic to the controller CPU or unselect the check box to disable the CPU ACL feature and remove any ACL that had been applied to the CPU. The default value is unselected.

From the ACL Name drop-down list, choose the ACL that will control the IPv4 traffic to the controller CPU. None is the default value when the CPU ACL feature is disabled. If you choose None while the Enable CPU ACL check box is selected, an error message appears indicating that you must choose an ACL.

Note

This parameter is available only if you have selected the CPU ACL Enable check

Note

box.

When CPU ACL is enabled, it is applicable to both wireless and wired traffic.

Cisco Wireless Controller Configuration Guide, Release 8.3

229

Configuring and Applying Access Control Lists (GUI)

Step 4

Step 5

Step 6

Step 7

Select the Enable CPU IPv6 ACL check box to enable a designated ACL to control the IPv6 traffic to the controller

CPU or unselect the check box to disable the CPU ACL feature and remove any ACL that had been applied to the CPU.

The default value is unselected.

Note

For CPU IPv6 ACL, along with permit rules for HTTP/Telnet, you must add a rule to allow ICMPv6 (NA/ND uses ICMPv6) for the CPU IPv6 ACLs to work.

From the IPv6 ACL Name drop-down list, choose the ACL that will control the IPv6 traffic to the controller CPU. None is the default value when the CPU ACL feature is disabled. If you choose None while the Enable CPU IPv6 ACL check box is selected, an error message appears indicating that you must choose an ACL.

Click Apply to commit your changes.

Click Save Configuration to save your changes.

Applying an Access Control List to a WLAN

Step 1

Step 2

Step 3

Step 4

Step 5

Step 6

Choose WLANs to open the WLANs page.

Click the ID number of the desired WLAN to open the WLANs > Edit page.

Choose the Advanced tab to open the WLANs > Edit (Advanced) page.

From the Override Interface ACL drop-down list, choose the IPv4 or IPv6 ACL that you want to apply to this WLAN.

The ACL that you choose overrides any ACL that is configured for the interface. None is the default value.

Note

To support centralized access control through AAA server such as ISE or ACS, IPv6 ACL must be configured on the controller and the WLAN must be configured with AAA override enabled feature.

Click Apply.

Click Save Configuration.

Applying a Preauthentication Access Control List to a WLAN

Step 1

Step 2

Step 3

Step 4

Step 5

Step 6

Choose WLANs to open the WLANs page.

Click the ID number of the desired WLAN to open the WLANs > Edit page.

Choose the Security and Layer 3 tabs to open the WLANs > Edit (Security > Layer 3) page.

Select the Web Policy check box.

From the Preauthentication ACL drop-down list, choose the desired ACL and click Apply. None is the default value.

Click Save Configuration to save your changes.

230

Cisco Wireless Controller Configuration Guide, Release 8.3

Configuring and Applying Access Control Lists (CLI)

Configuring and Applying Access Control Lists (CLI)

Configuring Access Control Lists

Step 1

Step 2

Step 3

Step 4

Step 5

Step 6

Step 7

See all of the ACLs that are configured on the controller by entering this command:

show [ipv6] acl summary

See detailed information for a particular ACL by entering this command:

show [ipv6] acl detailed acl_name

The Counter text box increments each time a packet matches an ACL rule, and the DenyCounter text box increments each time a packet does not match any of the rules.

Note

If a traffic/request is allowed from the controller by a permit rule, then the response to the traffic/request in the opposite direction also is allowed and cannot be blocked by a deny rule in the ACL.

Enable or disable ACL counters for your controller by entering this command:

config acl counter {start | stop}

Note

If you want to clear the current counters for an ACL, enter the clear acl counters acl_name command.

Add a new ACL by entering this command:

config [ipv6] acl create acl_name.

You can enter up to 32 alphanumeric characters for the acl_name parameter.

Note

When you try to create an interface name with space, the controller CLI does not create an interface. For example, if you want to create an interface name int 3, the CLI will not create this since there is a space between int and

3. If you want to use int 3 as the interface name, you need to enclose within single quotes like ‘int 3’.

Add a rule for an ACL by entering this command:

config [ipv6] acl rule add acl_name rule_index

Configure an ACL rule by entering config [ipv6] acl rule command:

Save your settings by entering this command:

save config

Note

To delete an ACL, enter the config [ipv6] acl delete acl_name command. To delete an ACL rule, enter the

config [ipv6] acl rule delete acl_name rule_index command.

Applying Access Control Lists

Step 1

Perform the following to apply an IPv4 ACL:

• To apply an ACL to the IPv4 data path, enter this command:

config acl apply acl_name

Cisco Wireless Controller Configuration Guide, Release 8.3

231

Configuring Layer 2 Access Control Lists

Step 2

Step 3

Step 4

Step 5

• To apply an ACL to the controller CPU to restrict the IPv4 type of traffic (wired, wireless, or both) reaching the

CPU, enter this command:

config acl cpu acl_name {wired | wireless | both}

Note

To see the ACL that is applied to the controller CPU, enter the show acl cpu command. To remove the

ACL that is applied to the controller CPU, enter the config acl cpu none command.

For 2504 and 4400 series WLC, the CPU ACL cannot be used to control the CAPWAP traffic. Use the access-list on the network to control CAPWAP traffic.

Perform the following to apply an IPv6 ACL:

• To apply an ACL to an IPv6 data path, enter this command:

config ipv6 acl apply name

• To apply an ACL to the controller CPU to restrict the IPv6 type of traffic (wired, wireless, or both) reaching the

CPU, enter this command:

config ipv6 acl cpu {name|none}

To apply an ACL to a WLAN, enter this command:

• config wlan acl wlan_id acl_name

Note

To see the ACL that is applied to a WLAN, enter the show wlan wlan_id command. To remove the ACL that is applied to a WLAN, enter the config wlan acl wlan_id none command.

To apply a pre-authentication ACL to a WLAN, enter this command:

• config wlan security web-auth acl wlan_id acl_name

Save your changes by entering this command:

save config

Configuring Layer 2 Access Control Lists

Information About Configuring Layer 2 Access Control Lists

You can configure rules for Layer 2 access control lists (ACLs) based on the Ethertype associated with the packets. Using this feature, if a WLAN with central switching is required to support only PPPoE clients, you can apply Layer 2 ACL rules on the WLAN to allow only PPPoE packets after the client is authenticated and the rest of the packets are dropped. Similarly, if the WLAN is required to support only IPv4 clients or only

IPv6 clients, you can apply Layer 2 ACL rules on the WLAN to allow only IPv4 or IPv6 packets after the client is authenticated and the rest of the packets are dropped. For a locally-switched WLAN, you can apply the same Layer 2 ACL either for the WLAN or a FlexConnect AP. AP-specific Layer 2 ACLs can be configured only on FlexConnect APs. This is applicable only for locally-switched WLANs. The Layer 2 ACL that is applied to the FlexConnect AP takes precedence over the Layer 2 ACL that is applied to the WLAN.

In a mobility scenario, the mobility anchor configuration is applicable.

The following traffic is not blocked:

232

Cisco Wireless Controller Configuration Guide, Release 8.3

Configuring Layer 2 Access Control Lists

• Wireless traffic for wireless clients:

• 802.1X

• Inter-Access Point Protocol

• 802.11

• Cisco Discovery Protocol

• Traffic from a distributed system:

• Broadcast

• Multicast

• IPv6 Neighbor Discovery Protocol (NDP)

• Address Resolution Protocol (ARP) and Gratuitous ARP Protection (GARP)

• Dynamic Host Configuration Protocol (DHCP)

• Domain Name System (DNS)

Layer 2 ACL Mapping to WLAN

If you map a Layer 2 ACL to a WLAN, the Layer 2 ACL rules that you configure apply to all the clients that are associated with that WLAN.

When you map a Layer 2 ACL to a centrally switched WLAN, the rule to pass traffic based on the Ethertype is determined by Fast-Path for every client that is associated with the WLAN. Fast-Path looks into the Ethernet headers associated with the packets and forwards the packets whose Ethertype matches with the one that is configured for the ACL.

When you map a Layer 2 ACL to a locally switched WLAN, the rule to pass traffic based on the Ethertype is determined by the forwarding plane of the AP for every client that is associated with the WLAN. The AP forwarding plane looks into the Ethernet headers associated with the packets and forwards or denies the packets based on the action whose Ethertype matches with the one that is configured for the ACL.

Note

WLC devices configured to preform Central Switching and Centralized Authentication displays the name of the Layer-2 ACL being applied to roaming users incorrectly. The situation occurs when an authorized device preforms a Layer-3 roam from the anchor controller to a foreign controller. After roaming, if an administrator issues the show acl layer2 summary command on the CLI of the foreign controller the incorrect information is displayed. It is expected that the ACL applied by the anchor will follow the authenticated client as it roams from controller to controller.

Restrictions for Layer 2 Access Control Lists

• You can create a maximum of 16 rules for a Layer 2 ACL.

• AP-specific Layer 2 ACLs can be configured only on FlexConnect APs. This is applicable only for locally-switched WLANs.

• You can create a maximum of 64 Layer2 ACLs on a controller.

Cisco Wireless Controller Configuration Guide, Release 8.3

233

Configuring Layer 2 Access Control Lists

• A maximum of 16 Layer 2 ACLs are supported per AP because an AP supports a maximum of 16

WLANs.

• Ensure that the Layer 2 ACL names do not conflict with the FlexConnect ACL names because an AP does not support the same Layer 2 and Layer3 ACL names.

Configuring Layer 2 Access Control Lists (CLI)

• config acl layer2 {create | delete} acl-name—Creates or deletes a Layer 2 ACL.

• config acl layer2 apply acl-name—Applies a Layer 2 ACL to a data path.

• config acl layer2 rule {add | delete} acl-rule-name index—Creates or deletes a Layer 2 ACL rule.

• config acl layer2 rule change index acl-rule-name old-index new-index—Changes the index of a Layer

2 ACL rule.

• config acl layer2 rule action acl-rule-name index {permit | deny}—Configures an action for a rule.

• config acl layer2 rule etherType name index ether-type-number-in-hex

ether-type-mask-in-hex—Configures the destination IP address and netmask for a rule.

• config acl layer2 rule swap index acl-rule-name index-1 index-2—Swaps the index values of two rules.

• config acl counter {start | stop}—Starts or stops the ACL counter. This command is applicable for all types of ACLs. In an HA environment, the counters are not synchronized between the active and standby controllers.

• show acl layer2 summary—Shows a summary of the Layer 2 ACL profiles.

• show acl layer2 detailed acl-name—Shows a detailed description of the Layer 2 ACL profile specified.

• show client detail client-mac-addr—Shows the Layer 2 ACL rule that is applied to the client.

Mapping of Layer 2 ACLs with WLANs (CLI)

This is applicable to centrally switched WLANs and locally switched WLANs without FlexConnect access points.

• config wlan layer2 acl wlan-id acl-name—Maps a Layer 2 ACL to a centrally switched WLAN.

• config wlan layer2 acl wlan-id none—Clears the Layer 2 ACLs mapped to a WLAN.

• show wlan wlan-id—Shows the status of a Layer 2 ACL that is mapped to a WLAN.

Mapping of Layer 2 ACLs with Locally Switched WLANs Using FlexConnect Access Points (CLI)

This is applicable to locally switched WLANs that have FlexConnect access points.

• config ap flexconnect wlan l2acl add wlan-id ap-name acl-name—Maps a Layer 2 ACL to a locally switched WLAN.

• config ap flexconnect wlan l2acl delete wlan-id ap-name—Deletes the mapping.

• show ap config general ap-name—Shows the details of the mapping.

234

Cisco Wireless Controller Configuration Guide, Release 8.3

Configuring Layer 2 Access Control Lists

Configuring Layer 2 Access Control Lists (GUI)

Step 1

Step 2

Step 3

Step 4

Step 5

Step 6

Choose Security > Access Control Lists > Layer2 ACLs to open the Layer2 Access Control Lists page.

Add a new ACL by clicking New. The Layer2 Access Control Lists > New page appears.

In the Access Control List Name text box, enter a name for the new ACL. You can enter up to 32 alphanumeric characters.

Click Apply. When the Layer2 Access Control Lists page reappears, click the name of the new ACL.

When the Layer2 Access Control Lists > Edit page appears, click Add New Rule. The Layer2 Access Control Lists >

Rules > New page appears.

Configure a rule for this ACL as follows: a) The controller supports up to 16 rules for each ACL. These rules are listed in order from 1 to 16. In the Sequence text box, enter a value (between 1 and 16) to determine the order of this rule in relation to any other rules defined for this ACL.

Note

If rules 1 through 4 are already defined and you add rule 15, it is added as rule 5. If you add or change a sequence number for a rule, the sequence numbers for other rules adjust to maintain a continuous sequence.

For instance, if you change a rule’s sequence number from 7 to 5, the rules with sequence numbers 5 and 6 are automatically reassigned as 6 and 7, respectively.

b) From the Ether Type drop-down list, choose any option from the following Ether type:

• AppleTalk Address Resolution Protocol

• VLAN-tagged Frame & Short Path Bridging

• IPX (0x8137)

• IPX (0x8138)

• QNS Qnet

• Internet Protocol Version 6

• Ethernet Flow Control

• Slow Protocol

• CobraNet

• MPLS Unicast

• MPLS Multicast

• PPPoE Discovery Stage

• PPPoE Session Stage

• Jumbo Frames

• HomePlug 1.0 MME

• EAP over LAN

• PROFINET over Protocol

• HyperSCSI

• ATA over Ethernet

Cisco Wireless Controller Configuration Guide, Release 8.3

235

Configuring Layer 2 Access Control Lists

Step 7

Step 8

• EtherCAT Protocol

Note

You can select any predefined Ether Types from the Ether Type drop-down list or enter your own Ether type value using the custom option from the Ether Type drop-down list.

c) From the Action drop-down list, choose Deny to cause this ACL to block packets or Permit to cause this ACL to allow packets. The default value is Deny.

d) Click Apply to commit your changes. The Layer2 Access Control Lists > Edit page reappears, showing the rules for this ACL.

e) Repeat this procedure to add any additional rules for this ACL.

Click Save Configuration to save your changes.

Repeat this procedure to add any additional ACLs.

Applying a Layer2 Access Control List to a WLAN (GUI)

Step 1

Step 2

Step 3

Step 4

Step 5

Step 6

Choose WLANs to open the WLANs page.

Click the ID number of the desired WLAN to open the WLANs > Edit page.

Choose the Advanced tab to open the WLANs > Edit (Advanced) page.

From the Layer2 ACL drop-down list, choose the ACL you have created.

Click Apply.

Click Save Configuration.

Applying a Layer2 Access Control List to an AP on a WLAN (GUI)

Step 1

Step 2

Step 3

Step 4

Step 5

Step 6

Step 7

Choose Wireless > Access Points > All APs to open the All APs page.

Click the name of the desired access point to open the All APs > Details page.

On the All APs > Details page, click the FlexConnect tab.

From the PreAuthentication Access Control Lists area, click the Layer2 ACLs link to open the ACL Mappings page.

From the Layer2 ACL drop-down list in the WLAN ACL Mapping area, choose the ACL you have created and click

Add.

Click Apply.

Click Save Configuration.

236

Cisco Wireless Controller Configuration Guide, Release 8.3

Configuring DNS-based Access Control Lists

Configuring DNS-based Access Control Lists

Information About DNS-based Access Control Lists

The DNS-based ACLs are used for client devices such as Apple and Android devices. When using these devices, you can set pre-authentication ACLs on the Cisco WLC to determine where devices have the right to go.

To enable DNS-based ACLs on the Cisco WLC, you need to configure the allowed URLs for the ACLs. The

URLs need to be pre-configured on the ACL.

With DNS-based ACLs, the client when in registration phase is allowed to connect to the configured URLs.

The Cisco WLC is configured with the ACL name and that is returned by the AAA server for pre-authentication

ACL to be applied. If the ACL name is returned by the AAA server, then the ACL is applied to the client for web-redirection.

At the client authentication phase, the ISE server returns the pre-authentication ACL (url-redirect-acl). The

DNS snooping is performed on the AP for each client until the registration is complete and the client is in

SUPPLICANT PROVISIONING state. When the ACL configured with the URLs is received on the Cisco

WLC, the CAPWAP payload is sent to the AP enabling DNS snooping on the client and the URLs to be snooped.

With URL snooping in place, the AP learns the IP address of the resolved domain name in the DNS response.

If the domain name matches the configured URL, then the DNS response is parsed for the IP address, and the

IP address is sent to the Cisco WLC as a CAPWAP payload. The Cisco WLC adds the IP address to the allowed list of IP addresses and thus the client can access the URLs configured.

In Release 8.0, support was added for DNS-based ACL with local web authentication.

Restrictions on DNS-based Access Control Lists

• Maximum of 10 URLs can be allowed for an access control list.

• On the Cisco WLC, 20 IP addresses are allowed for one client.

• Local authentication is not supported for FlexConnect APs.

• DNS-based ACLs are not supported on FlexConnect APs with Local Switching.

• DNS-based ACLs are not supported on Cisco 1130 and 1240 series access points.

• Authentication traffic has to go through the Cisco WLC for this feature to be supported, even if DNS-based

ACL is local to the AP.

• If a client is anchored, be it auto-anchor or after roaming, DNS-based ACLs do not work.

Configuring DNS-based Access Control Lists (CLI)

Step 1

Specifies to create ACL. You can enter an IPv4 ACL name up to 32 alphanumeric characters.

config acl create name

Cisco Wireless Controller Configuration Guide, Release 8.3

237

Configuring DNS-based Access Control Lists

Step 2

Step 3

Step 4

Step 5

Step 6

Step 7

Example:

(Cisco Controller) >> config acl create android

Specifies to add a new URL domain for the access control list. URL domain name should be given in a valid format, for example, Cisco.com, bbc.in, or play.google.com. The hostname comparison is a sub string matched (wildcard based).

You must use the ACL name that you have created already.

config acl url-domain add domain-name acl-name

Example:

(Cisco Controller) >> config acl url-domain add cisco.com android

(Cisco Controller) >> config acl url-domain add play.google.com android

Specifies to delete an existing URL domain for the access control list.

config acl url-domain delete domain-name acl-name

Example:

(Cisco Controller) >> config acl url-domain delete cisco.com android

Specifies to apply the ACL.

config acl apply acl-name

Example:

(Cisco Controller) >> config acl apply android

Displays DNS-based ACL information by entering this command:

show acl summary

Example:

(Cisco Controller) >>

show acl summary

ACL Counter Status Disabled

----------------------------------------

IPv4 ACL Name Applied

-------------------------------- ------android

StoreACL

Yes

----------------------------------------

IPv6 ACL Name Applied

-------------------------------- -------

Displays detailed DNS-based ACL information by entering this command:

show acl detailed acl-name

Example:

(Cisco Controller) >>

show acl detailed android

o rules are configured for this ACL.

DenyCounter : 0

URLs configured in this ACL

---------------------------

*.play.google.com

*.store.google.com

Displays the IP addresses per client learned through DNS snooping (DNS-based ACL) by entering this command:

show client detail mac-address

238

Cisco Wireless Controller Configuration Guide, Release 8.3

Configuring URL Filtering

Step 8

Example:

(Cisco Controller) >>

show client detail mac-address

Enables debugging of information related to DNS-based ACL.

debug aaa events enable

Example:

(Cisco Controller) >>

debug aaa events enable

Configuring DNS-based Access Control Lists (GUI)

Step 1

Step 2

Step 3

Step 4

Step 5

Step 6

Step 7

Step 8

Step 9

Choose Security > Access Control Lists > Access Control Lists to open the Access Control Lists page.

Note

If you want to clear the counters for an ACL, hover your cursor over the blue drop-down arrow for that ACL and choose Clear Counters.

Add a new ACL by clicking New. The Access Control Lists > New page appears.

In the Access Control List Name text box, enter a name for the new ACL. You can enter up to 32 alphanumeric characters.

Select the ACL type as IPv4.

Click Apply.

When the Access Control Lists page reappears, click the name of the new ACL. The ACLs have no IP rules. Hover your cursor over the blue drop-down arrow, choose Add-Remove URL from the drop-down list to open the URL List page.

To add a new URL domain for an ACL, enter the new URL domain for the access control list in the URL String Name text box. The URL domain name should be given in a valid format, for example, Cisco.com, bbc.in, or play.google.com.

To delete an URL domain, hover your cursor over the blue drop-down arrow under the URL Name you want to delete, and select Delete.

Configuring URL Filtering

Information About URL Filtering

URL filtering feature allows you to control access to internet websites. It does so by permitting or denying access to specific websites based on information contained in a URL access control list (ACL). The URL filtering then restricts access based on the ACL list.

Cisco Wireless Controller Configuration Guide, Release 8.3

239

Configuring URL Filtering

Using location based filtering, APs are grouped under various AP groups and WLAN profiles separate trusted and non-trusted clients within the same SSID. This forces re-authentication and new VLAN when a trusted client moves to a non-trusted AP or vice-versa.

The Wireless Controller (WLC) supports up to 64 ACLs. These ACLs are configured to either permit or deny requests, and can be associated with different interfaces (ex: WLAN, LAN), thus increasing effective filtering.

Policies can be implemented locally on a WLAN or an AP group that is different from the applied global policy.

The policy priority order is:

Policy

Interface

WLAN

Note

Default settings is to deny requests where the request URL does not match the applied ACL.

The number of rules (URLs) supported in each ACL varies for different WLCs:

• Cisco 5508 WLC, WiSM2 support 64 rules in one ACL.

• Cisco 5520, 8510, 8540 WLCs support 100 rules in one ACL.

Restrictions for URL Filtering

• Not supported on Cisco 2504 WLCs, vWLC, and Mobility Express.

• This feature is supported only on WLAN Central Switching and not Local switching.

• Not supported in Flex mode with local switching.

• Currently not supported

• Wildcard URLs (ex: www.uresour*loc.com).

• Sub-URL (ex: www.uresour*loc.com/support).

• Sub-Domain (ex: reach.url.com or sub1.url.com)

• URL name is limited to 32 characters in length.

• No AVC Profile for the matched URLs. ACL Actions support for the Matched URLs.

• White list and Black list can be created using the "*" implicit rule in the ACL to permit or deny requests respectively.

• Only HTTP URLs are supported.

• Radius server returning URL filtering ACL name is not supported.

• ACL may fail to filter in the following situations:

• URL is across fragmented packets.

• IP packets are fragmented.

240

Cisco Wireless Controller Configuration Guide, Release 8.3

Configuring URL Filtering

• Direct IP address or proxy setup used instead of URL.

Configuring URL Filtering (GUI)

Configuring Access Control Lists (GUI)

To create or delete access control lists in an WLAN.

Step 1

Step 2

Step 3

Step 4

Choose Security > Access Control Lists > URL ACLs to open the URL Access Control Lists page.

Select the Enable URL Acl check box to enable the URL ACL feature.

Add a new ACL by clicking New. The URL Access Control Lists > New page appears.

In the URL ACL Name text box, enter a name for the new ACL. You can enter up to 32 alphanumeric characters.

Click Apply.

• Repeat this procedure to add any additional URL ACLs.

• To delete any URL ACL, in the URL Access Control Lists page, hover the mouse cursor over the blue drop-down arrow for that ACL and choose Remove.

Note

If you want to clear the counters for an ACL, hover your cursor over the blue drop-down arrow for that

ACL and choose Clear Counters.

Configuring an URL ACL List (GUI)

Configuring rules in an URL ACL List.

DETAILED STEPS

Step 1

Step 2

Step 3

Step 4

Step 5

Command or Action Purpose

Choose Security > Access Control Lists >

URL ACLs to open the URL Access Control

Lists page

Choose the URL ACL.

URL Access Control Lists > Editpage appears.

Choose Add New Rule.

Configure a rule for this ACL from the drop-down menu.

• Rule Index—range between 1 and 100.

• URL—enter the URL address.

• Action—select Permit or Deny.

Click Apply.

Repeat this procedure to add any additional rules.

Cisco Wireless Controller Configuration Guide, Release 8.3

241

Configuring URL Filtering

Command or Action Purpose

Note

To have seamless access to websites which use different port number instead of default port 80, you will need to create a rule which includes the port number in

URL-name:Port format. Example: Enter the URL as website.com:8080 and apply permit action.

Applying a URL Filtering Access Control List Globally (GUI)

Applying the URL ACL to the entire network.

Step 1

Step 2

Step 3

Step 4

Step 5

Choose Security > Local Policies to open the local policy page.

Choose the desired policy.

Policy > Editpage appears.

Enter the Match Role String in the text box.

Select the URL ACL from the URL ACL drop-down list.

Click Apply.

Note

The Match Role String name should match the role name in Cisco AV pair.

Applying a URL Filtering Access Control List to an Interface (GUI)

Applying the URL ACL to an interface in the network.

Step 1

Step 2

Step 3

Step 4

Choose Controller > Interfaces to open the interface page.

Choose the desired interface.

The interface page for the selected interface appears.

Select the URL ACL from the URL ACL drop-down list.

Click Apply.

242

Cisco Wireless Controller Configuration Guide, Release 8.3

Applying a URL Filtering Access Control List for a WLAN (GUI)

Applying the URL ACL to a WLAN in the network.

Step 1

Step 2

Step 3

Step 4

Step 5

Choose WLANs to open the WLAN page.

Click the ID number of the desired WLAN.

The WLANs > Edit page appears.

Choose the Advanced tab.

From the URL ACL drop-down list, choose the ACL that you want to apply to this WLAN.

Click Apply.

Mapping the policy to a WLAN (GUI)

Mapping the policy to a WLAN in the network.

Step 1

Step 2

Step 3

Step 4

Choose WLANs to open the WLAN page.

Click the ID number of the desired WLAN.

The WLANs > Edit page appears.

Choose the Policy-Mapping tab.

Enter the Priority Index value.

Choose the local policy from the Local Policy drop-down list.

Click Add.

Click Apply.

To delete a Policy-Mapping in a WLAN (GUI)

This procedure helps delete the policy-mapping in a WLAN.

Step 1

Step 2

Step 3

Step 4

Choose WLANs to open the WLAN page.

Click the ID number of the desired WLAN.

The WLANs > Edit page appears.

Hover the mouse cursor over the blue drop-down arrow for that local policy

Choose Remove

The confirmation box appears.

Configuring URL Filtering

Cisco Wireless Controller Configuration Guide, Release 8.3

243

Configuring URL Filtering

Step 5

Step 6

Click OK.

Click Apply.

Mapping the policy to an AP Group (GUI)

Mapping the policy to an AP Group in the network.

Step 1

Step 2

Step 3

Step 4

Step 5

Step 6

Step 7

Choose WLANs to open the WLAN page.

Choose Advanced > AP Groups.

Choose the AP Group.

The AP Groups > Edit page appears.

Choose the WLANs tab.

Hover the mouse cursor over the blue drop-down arrow of the required WLAN, select Policy-Mapping.

In the AP Group > Policy > Mappings page.

Enter the Priority Index value.

Choose the local policy from the Local Policy drop-down list.

Click Add.

Click Apply.

The WLAN and AP Group are Local Role based policies.

Configuring URL Filtering (CLI)

Configuring URL Filtering (CLI)

Step 1

Step 2

Step 3

Step 4

Step 5

Configure the URL based Filtering feature by entering this command:

config acl url-acl {enabled | disable}

Create or delete a URL ACL by entering this command:

config acl url-acl{ create | delete} id-token

Apply the URL ACL to the data path by entering this command:

config acl url-acl applyacl-name

Configure an acl to an interface by entering this command:

config interface url-acl interface-name acl-name

Configure an acl to a WLAN by entering this command:

config wlan url-acl wlan-id acl-name

244

Cisco Wireless Controller Configuration Guide, Release 8.3

Configuring URL Filtering

Configuring Access Control List Rules (CLI)

Step 1

Step 2

Step 3

Create or delete a ACL by entering this command:

config acl url-acl rule{ add | delete} acl-name index

Configure the URL address in a valid format (example: www.cisco.com) by entering this command:

config acl url-acl rule urlacl-name index url-name

Configure the action of the rule by entering this command:

config acl url-acl rule action acl-name index{ permit | deny}

Note

To have seamless access to websites which use different port number instead of default port 80, you will need to create a rule which includes the port number in URL-name:Port format. Example: enter the URL as website.com:8080 and apply permit action.

Applying Local Policy (CLI)

Step 1

Step 2

Step 3

Step 4

Step 5

Create or delete a local profiling policy by entering this command:

config policy policy-name{create | delete}

Configure a match type to a policy by entering this command:

config policy policy-name match role {role-name| none}

Configure an action to a policy by entering this command:

config policy policy-name action url-acl {enable | disable} acl-name

Activate a local policy to a WLAN by entering this command:

config wlan policy add priority-index policy-name wlan-id

Add or delete a local policy in an AP group in a WLAN by entering this command:

config wlan apgroup policy {add | delete} priority-index policy-name ap-group-name wlan-id

Viewing URL Filtering (CLI)

• View ACL summary by entering this command:

show acl url-acl summary

• View detailed URL ACL profile information by entering this command:

show acl url-acl detailed acl-name

• View the details of a policy by entering this command:

show policy {summary|policy-name}

• View client details by MAC address by entering this command:

show client detail mac-address

Cisco Wireless Controller Configuration Guide, Release 8.3

245

Configuring URL Filtering

• View the WLAN configuration details by entering this command:

show wlan wlan-id

• View the interface details by entering this command:

show interface detailed interface-name

• Clear the counters by entering this command:

clear url-acl-counters

Troubleshooting URL Filtering (CLI)

You can troubleshoot the URL Filtering feature by entering these commands:

• debug fastpath dump urlacldb aclid ruleindex dataplane

• debug fastpath dump stats dataplane

The dataplane options available are 0, 1, All.

• debug fastpath dump scbdb

246

Cisco Wireless Controller Configuration Guide, Release 8.3

C H A P T E R

Multicast/Broadcast Setup

•

Configuring Multicast Mode, page 247

•

Mediastream, page 255

•

Configuring Multicast Domain Name System, page 260

Configuring Multicast Mode

Information About Multicast/Broadcast Mode

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.

Cisco Wireless Controller Configuration Guide, Release 8.3

247

Configuring 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.

Internet Group Management Protocol (IGMP) snooping is available 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.

248

Cisco Wireless Controller Configuration Guide, Release 8.3

Configuring Multicast Mode

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.

Restrictions on Configuring Multicast Mode

• The Cisco Unified Wireless Network solution uses some IP address ranges for specific purposes, and you should keep these ranges in mind when configuring a multicast group:

◦224.0.0.0 through 224.0.0.255—Reserved link local addresses

◦224.0.1.0 through 238.255.255.255—Globally scoped addresses

◦239.0.0.0 through 239.255.x.y /16—Limited scope addresses

• When you enable multicast mode on the controller, you also must configure a CAPWAP multicast group address. Access points subscribe to the CAPWAP multicast group using IGMP.

• Cisco 1100, 1130, 1200, 1230, and 1240 access points use IGMP versions 1, 2, and 3.

• Access points in monitor mode, sniffer mode, or rogue detector mode do not join the CAPWAP multicast group address.

• The CAPWAP multicast group configured on the controllers should be different for different controllers.

• Lightweight Access Points transmit multicast packets at the highest configured mandatory data rate.

Because multicast frames are not retransmitted at the MAC layer, clients at the edge of the cell might fail to receive them successfully. If reliable reception is a goal, multicast frames should be transmitted at a low data rate. If support for high data rate multicast frames is required, it might be useful to shrink the cell size and disable all lower data rates.

Depending on your requirements, you can take the following actions:

◦If you need to transmit multicast data with the greatest reliability and if there is no need for great multicast bandwidth, then configure a single basic rate, that is low enough to reach the edges of the wireless cells.

◦If you need to transmit multicast data at a certain data rate in order to achieve a certain throughput, you can configure that rate as the highest basic rate. You can also set a lower basic rate for coverage of nonmulticast clients.

• Multicast mode does not operate across intersubnet mobility events such as guest tunneling. It does, however, operate with interface overrides using RADIUS (but only when IGMP snooping is enabled) and with site-specific VLANs (access point group VLANs).

• For LWAPP, the controller drops multicast packets sent to UDP control port 12223. For CAPWAP, the controller drops multicast packets sent to UDP control and data ports 5246 and 5247, respectively.

Therefore, you may want to consider not using these port numbers with the multicast applications on your network.

Cisco Wireless Controller Configuration Guide, Release 8.3

249

Configuring Multicast Mode

• We recommend that any multicast applications on your network not use the multicast address configured as the CAPWAP multicast group address on the controller.

• For multicast to work on Cisco 2500 Series WLC, you have to configure the multicast IP address.

• Multicast mode is not supported on Cisco Flex 7500 Series WLCs.

• IGMP and MLD snooping is not supported on Cisco Flex 7500 Series WLCs.

• For Cisco 8500 Series WLCs:

◦You must enable multicast-unicast if IPv6 support is required on FlexConnect APs with central switching clients.

◦You can change from multicast mode to multicast-unicast mode only if global multicast is disabled, which means IGMP or MLD snooping is not supported.

◦FlexConnect APs do not associate with a multicast-mulitcast group.

◦IGMP or MLD snooping is not supported on FlexConnect APs. IGMP and MLD snooping is allowed only for local mode APs in multicast-multicast mode.

◦Because VideoStream requires IGMP or MLD snooping, the VideoStream feature works only on local mode APs if multicast-multicast mode and snooping are enabled.

• In a multicast group, when multicast audio is initiated, the recipients do not hear the first two seconds of the multicast audio. As a workaround, we recommend that you set the Cisco APs to FlexConnect +

Local Switching mode for small-scale deployments.

• To reduce join latency, we recommend disabling IPv6 on the Cisco WLC.

• FlexConnect APs do not join the multicast group when the Multicast mode is Multicast-Multicast and

CAPWAP has IPv4 and IPv6. For Cisco 5508 and 8510 WLCs, you can disable the Multicast-Multicast mode and enable the Multicast-Unicast mode. For Cisco Flex 7510 WLC, there is no Multicast-Multicast configuration. For FlexConnect APs in Multicast-Multicast mode joined with central switching clients, there is reduction of 0-13 percent in data throughput.

• We recommend that you do not use Broadcast-Unicast or Multicast-Unicast mode on Cisco WLC setup where there are more than 50 APs connected together.

If a Cisco WLC setup has more than 50 APs, the CAPWAP control messages between Cisco WLC and

AP may be delayed due to duplication of each Multicast or Broadcast traffic to each of the APs. The delay in the CAPWAP control messages causes client association or 802.1X authentication to be delayed for 1 to 3 seconds. As a result of this, the client receives repeated authentication prompts or failure messages.

• While using Local and FlexConnect AP mode the Cisco WLC platform's multicast support differs for different platforms.

The parameters that affect Multicast forwarding are:

◦Cisco WLC platform.

◦Global AP multicast mode configuration at Cisco WLC.

◦Mode of the AP—Local, FlexConnect central switching.

◦For Local switching, it does not send/receive the packet to/from Cisco WLC, so it does not matter which Multicast mode is configured on the Cisco WLC.

250

Cisco Wireless Controller Configuration Guide, Release 8.3

Configuring Multicast Mode

Note

FlexConnect mode AP cannot join Multicast group address configured at Cisco WLC.

Therefore, the FlexConnect mode AP cannot receive Multicast packets that are sent by

Cisco WLC (Multicast packets sent by FlexConnect central switching is received by local mode APs). If Multicast needs to be forwarded for FlexConnect central switching, you must configure AP mode as Multicast to Unicast. This configuration is global because it is applicable to local mode AP.

• Effective with Release 8.2.100.0, it is not possible to download some of the older configurations from the Cisco WLC because of the Multicast and IP address validations introduced in this release. The platform support for global multicast and multicast mode are listed in the following table.

Table 11: Platform Support for Global Multicast and Multicast Mode

Platform

Cisco 5520, 8510, and

8540 WLCs

Global Multicast

Enabled

Disabled

Multicast Mode

Unicast

Multicast

Unicast

Supported

Yes

No mulitcast support(config supported)

Disabled Multicast

Cisco Flex 7510 WLC Global Multicast cannot be enabled. Only Unicast mode is supported. Also,

AP-Multicast mode cannot be changed to Multicast-Multicast.

Cisco 5508 WLC

No mulitcast support(config supported)

Enabled

Unicast

Multicast

Yes

Cisco 2504 WLC

Cisco vWLC

Disabled

Unicast

Multicast

Yes

Only Multicast mode is supported. Global Multicast cannot be enabled. Also,

AP-Multicast mode cannot be changed to Multicast-Multicast.

Multicast is not supported; only Unicast mode is supported.

Cisco Wireless Controller Configuration Guide, Release 8.3

251

Configuring Multicast Mode

Enabling Multicast Mode (GUI)

Step 1

Step 2

Step 3

Step 4

Step 5

Step 6

Step 7

Step 8

Step 9

Step 10

Choose Controller > Multicast to open the Multicast page.

Select the Enable Global Multicast Mode check box to configure sending multicast packets. The default value is disabled.

Note

FlexConnect supports unicast mode only.

If you want to enable IGMP snooping, select the Enable IGMP Snooping check box. If you want to disable IGMP snooping, leave the check box unselected. The default value is disabled.

To set the IGMP timeout, enter a value between 30 and 7200 seconds in the IGMP Timeout text box. The controller sends three queries in one timeout value at an interval of timeout/ 3 to see if any clients exist for a particular multicast group. If the controller does not receive a response through an IGMP report from the client, the controller times out the client entry from the MGID table. When no clients are left for a particular multicast group, the controller waits for the

IGMP timeout value to expire and then deletes the MGID entry from the controller. The controller always generates a general IGMP query (that is, to destination address 224.0.0.1) and sends it on all WLANs with an MGID value of 1.

Enter the IGMP Query Interval (seconds).

Select the Enable MLD Snooping check box to support IPv6 forwarding decisions.

Note

To enable MLD Snooping, you must enable Global Multicast Mode of the controller.

In the MLD Timeout text box, enter a value between 30 and 7200 seconds to set the MLD timeout.

Enter the MLD Query Interval (seconds). The valid range is between 15 and 2400 seconds.

Click Apply.

Click Save Configuration.

Enabling Multicast Mode (CLI)

Step 1

Step 2

Enable or disable multicasting on the controller by entering this command:

config network multicast global {enable | disable}

The default value is disabled.

Note

The config network broadcast {enable | disable} command allows you to enable or disable broadcasting without enabling or disabling multicasting as well. This command uses the multicast mode currently on the controller to operate.

Perform either of the following: a) Configure the controller to use the unicast method to send multicast packets by entering this command:

config network multicast mode unicast

b) Configure the controller to use the multicast method to send multicast packets to a CAPWAP multicast group by entering this command:

config network multicast mode multicast multicast_group_ip_address

252

Cisco Wireless Controller Configuration Guide, Release 8.3

Configuring Multicast Mode

Step 3

Step 4

Step 5

Step 6

Step 7

Step 8

Enable or disable IGMP snooping by entering this command:

config network multicast igmp snooping {enable | disable}

The default value is disabled.

Set the IGMP timeout value by entering this command:

config network multicast igmp timeout timeout

You can enter a timeout value between 30 and 7200 seconds. The controller sends three queries in one timeout value at an interval of timeout/3 to see if any clients exist for a particular multicast group. If the controller does not receive a response through an IGMP report from the client, the controller times out the client entry from the MGID table. When no clients are left for a particular multicast group, the controller waits for the IGMP timeout value to expire and then deletes the MGID entry from the controller. The controller always generates a general IGMP query (that is, to destination address 224.0.0.1) and sends it on all WLANs with an MGID value of 1.

Enable or disable Layer 2 Multicast by entering this command:

config network multicast l2mcast {enable {all | interface-name} | disable}

Enable or disable MLD snooping by entering this command:

config network multicast mld snooping {enable | disable}

The default value is disabled.

Note

To enable MLD snooping, you must enable global multicast mode of the controller.

Set the MLD timeout value by entering this command:

config network multicast mld timeout timeout

Enter the MLD Query Interval (seconds). The valid range is between 15 and 2400 seconds.

Save your changes by entering this command:

save config

Viewing Multicast Groups (GUI)

Step 1

Step 2

Choose Monitor > Multicast. The Multicast Groups page appears.

This page shows all the multicast groups and their corresponding MGIDs.

Click the link for a specific MGID (such as MGID 550) to see a list of all the clients joined to the multicast group in that particular MGID.

Viewing Multicast Groups (CLI)

Before You Begin

• See all the multicast groups and their corresponding MGIDs by entering this command:

show network multicast mgid summary

Cisco Wireless Controller Configuration Guide, Release 8.3

253

Configuring Multicast Mode

Information similar to the following appears:

Layer2 MGID Mapping:

-------------------

InterfaceName vlanId MGID

-------------------------------- --------management test wired

Layer3 MGID Mapping:

-------------------

Number of Layer3 MGIDs........................... 1

Group address Vlan MGID

---------------------

239.255.255.250

0 550

• See all the clients joined to the multicast group in a specific MGID by entering this command:

show network multicast mgid detail mgid_value where the mgid_value parameter is a number between 550 and 4095.

Information similar to the following appears:

Mgid........................................ 550

Multicast Group Address..................... 239.255.255.250

Vlan........................................ 0

Rx Packet Count............................. 807399588

No of clients............................... 1

Client List.................................

Client MAC

00:13:02:23:82:ad

Expire Time (mm:ss)

0:20

Viewing an Access Point’s Multicast Client Table (CLI)

To help troubleshoot roaming events, you can view an access point’s multicast client table from the controller by performing a remote debug of the access point.

Step 1

Step 2

Step 3

Initiate a remote debug of the access point by entering this command:

debug ap enable Cisco_AP

See all of the MGIDs on the access point and the number of clients per WLAN by entering this command:

debug ap command “show capwap mcast mgid all” Cisco_AP

See all of the clients per MGID on the access point and the number of clients per WLAN by entering this command:

debug ap command “show capwap mcast mgid id mgid_value” Cisco_AP

254

Cisco Wireless Controller Configuration Guide, Release 8.3

Mediastream

Mediastream

Information about VideoStream

The IEEE 802.11 wireless multicast delivery mechanism does not provide a reliable way to acknowledge lost or corrupted packets. As a result, if any multicast packet is lost in the air, it is not sent again which may cause an IP multicast stream unviewable.

The VideoStream feature makes the IP multicast stream delivery reliable over the air, by converting the multicast frame to a unicast frame over the air. Each VideoStream client acknowledges receiving a video IP multicast stream.

Prerequisites for VideoStream

Make sure that the multicast feature is enabled. We recommend configuring IP multicast on the controller with multicast-multicast mode.

Check for the IP address on the client machine. The machine should have an IP address from the respective

VLAN.

Verify that the access points have joined the controllers.

Make sure that the clients are able to associate to the configured WLAN at 802.11n speed.

Restrictions for Configuring VideoStream

VideoStream is supported in the 7.0.98.0 and later controller software releases.

The Cisco OEAP-600 does not support VideoStream. All other access points support VideoStream.

Configuring VideoStream (GUI)

Step 1

Configure the multicast feature by following these steps: a) Choose Wireless > MediaStream > General.

b) Select or unselect the Multicast Direct feature check box. The default value is disabled.

Note

Enabling the multicast direct feature does not automatically reset the existing client state. The wireless clients must rejoin the multicast stream after enabling the multicast direct feature on the controller.

c) In the Session Message Config area, select Session announcement State check box to enable the session announcement mechanism. If the session announcement state is enabled, clients are informed each time a controller is not able to serve the multicast direct data to the client.

d) In the Session announcement URL text box, enter the URL where the client can find more information when an error occurs during the multicast media stream transmission.

e) In the Session announcement e-mail text box, enter the e-mail address of the person who can be contacted.

f) In the Session announcement Phone text box, enter the phone number of the person who can be contacted.

g) In the Session announcement Note text box, enter a reason as to why a particular client cannot be served with a multicast media.

Cisco Wireless Controller Configuration Guide, Release 8.3

255

Mediastream

Step 2

h) Click Apply.

Add a media stream by following these steps: a) Choose Wireless > Media Stream > Streams to open the Media Stream page.

b) Click Add New to configure a new media stream. The Media Stream > New page appears.

Note

The Stream Name, Multicast Destination Start IP Address (IPv4 or IPv6), and Multicast Destination End IP

Address (IPv4 or IPv6) text boxes are mandatory. You must enter information in these text boxes.

c) In the Stream Name text box, enter the media stream name. The stream name can be up to 64 characters.

d) In the Multicast Destination Start IP Address (IPv4 or IPv6) text box, enter the start (IPv4 or IPv6) address of the multicast media stream.

e) In the Multicast Destination End IP Address (IPv4 or IPv6) text box, enter the end (IPv4 or IPv6) address of the multicast media stream.

Note

Ensure that the Multicast Destination Start and End IP addresses are of the same type, that is both addresses should be of either IPv4 or IPv6 type.

f) In the Maximum Expected Bandwidth text box, enter the maximum expected bandwidth that you want to assign to the media stream. The values can range between 1 to 35000 kbps.

Note

We recommend that you use a template to add a media stream to the controller.

g) From the Select from Predefined Templates drop-down list under Resource Reservation Control (RRC) Parameters, choose one of the following options to specify the details about the resource reservation control:

• Very Coarse (below 300 kbps)

• Coarse (below 500 kbps)

• Ordinary (below 750 kbps)

• Low (below 1 Mbps)

• Medium (below 3 Mbps)

• High (below 5 Mbps)

Note

When you select a predefined template from the drop-down list, the following text boxes under the

Resource Reservation Control (RRC) Parameters list their default values that are assigned with the template.

• Average Packet Size (100-1500 bytes)—Specifies the average packet size. The value can be in the range of 100 to 1500 bytes. The default value is 1200.

• RRC Periodic update—Enables the RRC (Resource Reservation Control Check) Periodic update. By default, this option is enabled. RRC periodically updates the admission decision on the admitted stream according to the correct channel load. As a result, it may deny certain low priority admitted stream requests.

• RRC Priority (1-8)—Specifies the priority bit set in the media stream. The priority can be any number between

1 and 8. The larger the value means the higher the priority is. For example, a priority of 1 is the lowest value and a value of 8 is the highest value. The default priority is 4. The low priority stream may be denied in the

RRC periodic update.

• Traffic Profile Violation—Specifies the action to perform in case of a violation after a re-RRC. Choose an action from the drop-down list. The possible values are as follows:

Drop—Specifies that a stream is dropped on periodic revaluation.

Fallback—Specifies that a stream is demoted to Best Effort class on periodic reevaluation.

The default value is drop.

256

Cisco Wireless Controller Configuration Guide, Release 8.3

Mediastream

Step 3

Step 4

Step 5

Step 6

Step 7

h) Click Apply.

Enable the media stream for multicast-direct by following these steps: a) Choose WLANs > WLAN ID to open the WLANs > Edit page.

b) Click the QoS tab and select Gold (Video) from the Quality of Service (QoS) drop-down list.

c) Click Apply.

Set the EDCA parameters to voice and video optimized (optional) by following these steps: a) Choose Wireless > 802.11a/n/ac or 802.11b/g/n > EDCA Parameters.

b) From the EDCA Profile drop-down list, choose the Voice and Video Optimized option.

c) Click Apply.

Enable the admission control on a band for video (optional) by following these steps:

Note

Keep the voice bandwidth allocation to a minimum for better performance.

a) Choose Wireless > 802.11a/n/ac or 802.11b/g/n > Media to open the 802.11a/n (5 GHZ) or 802.11b/g/n > Media page.

b) Click the Video tab.

c) Select the Admission Control (ACM) check box to enable bandwidth-based CAC for this radio band. The default value is disabled.

d) Click Apply.

Configure the video bandwidth by following these steps:

Note

The template bandwidth that is configured for a media stream should be more than the bandwidth for the source

Note

media stream.

The voice configuration is optional. Keep the voice bandwidth allocation to a minimum for better performance.

a) Disable all WMM WLANs.

b) Choose Wireless > 802.11a/n/ac or 802.11b/g/n > Media to open the 802.11a/n/ac (5 GHZ) or 802.11b/g/n > Media page.

c) Click the Video tab.

d) Select the Admission Control (ACM) check box to enable the video CAC for this radio band. The default value is disabled.

e) In the Max RF Bandwidth field, enter the percentage of the maximum bandwidth allocated to clients for video applications on this radio band. Once the client reaches the value specified, the access point rejects new requests on this radio band.

f) The range is 5 to 85%.

g) The default value is 9%.

h) Click Apply.

i) Reenable all WMM WLANs and click Apply.

Configure the media bandwidth by following these steps: a) Choose Wireless > 802.11a/n/ac or 802.11b/g/n > Media to open the 802.11a (or 802.11b) > Media > Parameters page.

b) Click the Media tab to open the Media page.

c) Select the Unicast Video Redirect check box to enable Unicast Video Redirect. The default value is disabled.

d) In the Maximum Media Bandwidth (0-85%) text box, enter the percentage of the maximum bandwidth to be allocated for media applications on this radio band. Once the client reaches a specified value, the access point rejects new calls on this radio band.

e) The default value is 85%; valid values are from 0% to 85%.

Cisco Wireless Controller Configuration Guide, Release 8.3

257

Mediastream

Step 8

Step 9

Step 10

f) In the Client Minimum Phy Rate text box, enter the minimum transmission data rate to the client. If the transmission data rate is below the phy rate, either the video will not start or the client may be classified as a bad client. The bad client video can be demoted for better effort QoS or subject to denial.

g) In the Maximum Retry Percent (0-100%) text box, enter the percentage of maximum retries that are allowed. The default value is 80. If it exceeds 80, either the video will not start or the client might be classified as a bad client. The bad client video can be demoted for better effort QoS or subject to denial.

h) Select the Multicast Direct Enable check box to enable the Multicast Direct Enable field. The default value is enabled.

i) From the Max Streams per Radio drop-down list, choose the maximum number of streams allowed per radio from the range 0 to 20. The default value is set to No-limit. If you choose No-limit, there is no limit set for the number of client subscriptions.

j) From the Max Streams per Client drop-down list, choose the maximum number of streams allowed per client from the range 0 to 20. The default value is set to No-limit. If you choose No-limit, there is no limit set for the number of client subscriptions.

k) Select the Best Effort QoS Admission check box to enable best-effort QoS admission.

l) Click Apply.

Enable a WLAN by following these steps: a) Choose WLANS > WLAN ID. The WLANs > Edit page appears.

b) Select the Status check box.

c) Click Apply.

Enable the 802.11 a/n/ac or 802.11 b/g/n network by following these steps: a) Choose Wireless > 802.11a/n/ac or 802.11b/g/n > Network.

b) Select the 802.11a or 802.11b/g Network Status check box to enable the network status.

c) Click Apply.

Verify that the clients are associated with the multicast groups and group IDs by following these steps: a) Choose Monitor > Clients. The Clients page appears.

b) Check if the 802.11a/n/ac or 802.11b/g/n network clients have the associated access points.

c) Choose Monitor > Multicast. The Multicast Groups page appears.

d) Select the MGID check box for the VideoStream to the clients.

e) Click MGID. The Multicast Group Detail page appears. Check the Multicast Status details.

Configuring VideoStream (CLI)

Step 1

Step 2

Step 3

Configure the multicast-direct feature on WLANs media stream by entering this command:

config wlan media-stream multicast-direct {wlan_id | all} {enable | disable}

Enable or disable the multicast feature by entering this command:

config media-stream multicast-direct {enable | disable}

Configure various message configuration parameters by entering this command:

config media-stream message {state [enable | disable] | url url | email email | phone phone _number | note note}

258

Cisco Wireless Controller Configuration Guide, Release 8.3

Mediastream

Step 4

Step 5

Step 6

Step 7

Step 8

Step 9

Save your changes by entering this command:

save config

Configure various global media-stream configurations by entering this command:

config media-stream add multicast-direct stream-name media_stream_name start_IP end_IP [template {very-coarse

| coarse | ordinary | low-resolution | med-resolution | high-resolution} | detail {Max_bandwidth bandwidth | packet

size packet_size | Re-evaluation re-evaluation {periodic | initial}} video video priority {drop | fallback}

• The Resource Reservation Control (RRC) parameters are assigned with the predefined values based on the values assigned to the template.

• The following templates are used to assign RRC parameters to the media stream:

◦Very Coarse (below 3000 kbps)

◦Coarse (below 500 kbps)

◦Ordinary (below 750 kbps)

◦Low Resolution (below 1 mbps)

◦Medium Resolution (below 3 mbps)

◦High Resolution (below 5 mbps)

Delete a media stream by entering this command:

config media-stream delete media_stream_name

Enable a specific enhanced distributed channel access (EDC) profile by entering this command:

config advanced{ 801.11a | 802.11b} edca-parameters optimized-video-voice

Enable the admission control on the desired bandwidth by entering the following commands:

• Enable bandwidth-based voice CAC for 802.11a or 802.11b/g network by entering this command:

config {802.11a | 802.11b} cac voice acm enable

• Set the percentage of the maximum bandwidth allocated to clients for voice applications on the 802.11a or 802.11b/g network by entering this command:

config {802.11a | 802.11b} cac voice max-bandwidth bandwidth

• Configure the percentage of the maximum allocated bandwidth reserved for roaming voice clients on the 802.11a

or 802.11b/g network by entering this command:

config {802.11a | 802.11b} cac voice roam-bandwidth bandwidth

Note

For TSpec and SIP based CAC for video calls, only Static method is supported.

Set the maximum number of streams per radio and/or per client by entering these commands:

• Set the maximum limit to the number multicast streams per radio by entering this command:

config {802.11a | 802.11b} media-stream multicast-direct radio-maximum [value | no-limit]

• Set the maximum number of multicast streams per client by entering this command:

config {802.11a | 802.11b} media-stream multicast-direct client-maximum [value | no-limit]

Cisco Wireless Controller Configuration Guide, Release 8.3

259

Configuring Multicast Domain Name System

Step 10

Save your changes by entering this command:

save config

Viewing and Debugging Media Streams

• See the configured media streams by entering this command:

show wlan wlan_id

• See the details of the media stream name by entering this command:

show 802.11{a | b | h} media-stream media-stream_name

• See the clients for a media stream by entering this command:

show 802.11a media-stream client media-stream-name

• See a summary of the media stream and client information by entering this command:

show media-stream group summary

• See details about a particular media stream group by entering this command:

show media-stream group detail media_stream_name

• See details of the 802.11a or 802.11b media resource reservation configuration by entering this command:

show {802.11a | 802.11b} media-stream rrc

• Enable debugging of the media stream history by entering this command:

debug media-stream history {enable | disable}

Configuring Multicast Domain Name System

Information About Multicast Domain Name System

Multicast Domain Name System (mDNS) service discovery provides a way to announce and discover the services on the local network. The mDNS service discovery enables wireless clients to access Apple services such as Apple Printer and Apple TV advertised in a different Layer 3 network. mDNS performs DNS queries over IP multicast. mDNS supports zero-configuration IP networking. As a standard, mDNS uses multicast IP address 224.0.0.251 as the destination address and 5353 as the UDP destination port.

Location Specific Services

The processing of mDNS service advertisements and mDNS query packets support Location-Specific Services

(LSS). All the valid mDNS service advertisements that are received by the controller are tagged with the MAC address of the AP that is associated with the service advertisement from the service provider while inserting the new entry into the service provider database. The response formulation to the client query filters the wireless entries in the SP-DB using the MAC address of the AP associated with the querying client. The wireless service provider database entries are filtered based on the AP-NEIGHBOR-LIST if LSS is enabled

260

Cisco Wireless Controller Configuration Guide, Release 8.3

Configuring Multicast Domain Name System

for the service. If LSS is disabled for any service, the wireless service provider database entries are not filtered when they respond to any query from a wireless client for the service.

LSS applies only to wireless service provider database entries. There is no location awareness for wired service provider devices.

The status of LSS cannot be enabled for services with ORIGIN set to wired and vice-versa.

mDNS AP

The mDNS AP feature allows the controller to have visibility of wired service providers that are on VLANs that are not visible to the controller. You can configure any AP as an mDNS AP and enable the AP to forward mDNS packets to the controller. VLAN visibility on the controller is achieved by APs that forward the mDNS advertisements to the controller. The mDNS packets between the AP and the controller are forwarded in

Control and Provisioning of Wireless Access Points (CAPWAP) data tunnel that is similar to the mDNS packets from a wireless client. Only CAPWAP v4 tunnels are supported. APs can be in either the access port or the trunk port to learn the mDNS packets from the wired side and forward them to the controller.

You can use the configurable knob that is provided on the controller to start or stop mDNS packet forwarding from a specific AP. You can also use this configuration to specify the VLANs from which the AP should snoop the mDNS advertisements from the wired side. The maximum number of VLANs that an AP can snoop is 10.

If the AP is in the access port, you should not configure any VLANs on the AP to snoop. The AP sends untagged packets when a query is to be sent. When an mDNS advertisement is received by the mDNS AP, the VLAN information is not passed on to the controller. The service provider's VLAN that is learned through the mDNS AP's access VLAN is maintained as 0 in the controller.

By default, the mDNS AP snoops in native VLAN. When an mDNS AP is enabled, native VLAN snooping is enabled by default and the VLAN information is passed as 0 for advertisements received on the native

VLAN.

The mDNS AP feature is supported only on local mode and monitor mode APs.

The mDNS AP configuration is retained on those mDNS APs even if global mDNs snooping is disabled.

Note

There is no check to ensure that no two mDNS APs are duplicating the same traffic for the same service.

But, for the same VLAN, there is such a check.

If an mDNS AP is reset or associated with the same controller or another controller, one of the following occurs:

• If the global snooping is disabled on the controller, a payload is sent to the AP to disable mDNS snooping.

• If the global snooping is enabled on the controller, the configuration of the AP before the reset or the association procedure is retained.

The process flow for the mDNS AP feature is as follows:

• Uplink (Wired infrastructure to AP to Controller):

Receives the 802.3 mDNS packet on configured VLANs.

Forwards the received mDNS packet over CAPWAP.

Populates multicast group ID (MGID) based on the received VLAN.

Cisco Wireless Controller Configuration Guide, Release 8.3

261

Configuring Multicast Domain Name System

• Downlink (Controller to AP to Wired Infrastructure):

Receives an mDNS query over CAPWAP from the controller.

Forwards the query as 802.3 packet to wired infrastructure.

The VLAN is identified from dedicated MGIDs.

Per-Service SP Count Limit

The following list shows the global service provider limit per controller model:

• Cisco 8500 Series Wireless LAN Controller—16000

• Cisco Flex 7500 Series Wireless LAN Controller—16000

• Cisco 5500 Series Wireless LAN Controller—6400

• Cisco 2500 Series Wireless LAN Controller—6400

If the total number of service providers for all services is within the specified limit, any service is free to learn or discover as many other services. There is no per service reservation or restriction, which allows flexibility to accommodate more service providers for any service with respect to other services.

Priority MAC Support

You can configure up to 50 MAC addresses per service; these MAC addresses are the service provider MAC addresses that require priority. This guarantees that any service advertisements originating from these MAC addresses for the configured services are learned even if the service provider database is full by deleting the last nonpriority service provider from the service that has the highest number of service providers. When you configure the priority MAC address for a service, there is an optional parameter called ap-group, which is applicable only to wired service providers to associate a sense of location to the wired service provider devices.

When a client mDNS query originates from this ap-group, the wired entries with priority MAC and ap-group are looked up and the wired entries are listed first in the aggregated response.

Origin-Based Service Discovery

You can configure a service to filter inbound traffic that is based on its origin, that is either wired or wireless.

All the services that are learned from an mDNS AP are treated as wired. When the learn origin is wired, the

LSS cannot be enabled for the service because LSS applies only to wireless services.

A service that has its origin set to wireless cannot be changed to wired if the LSS status is enabled for the service because LSS is applicable only to wireless service provider database. If you change the origin between wired and wireless, the service provider database entries with the prior origin type is cleared.

Restrictions for Configuring Multicast DNS

• mDNS over IPv6 is not supported.

• mDNS is not supported on access points in FlexConnect mode in a locally switched WLAN and mesh access points.

• mDNS is not supported on remote LANs.

• mDNS is not supported on Cisco AP1240 and Cisco AP1130.

262

Cisco Wireless Controller Configuration Guide, Release 8.3

Configuring Multicast Domain Name System

• Third-party mDNS servers or applications are not supported on the Cisco WLC using the mDNS feature.

Devices that are advertised by the third-party servers or applications are not populated on the mDNS service or device table correctly on the Cisco WLC.

• In a Layer2 network, if Apple servers and clients are in the same subnet, mDNS snooping is not required on the Cisco WLC. However, this relies on the switching network to work. If you use switches that do not work as expected with mDNS snooping, you must enable mDNS on the Cisco WLC.

• Video is not supported on Apple iOS 6 with WMM in enabled state.

• mDNS APs cannot duplicate the same traffic for the same service or VLAN.

• LSS filtering is restricted to only wireless services.

• The LSS, mDNS AP, Priority MAC address, and origin-based discovery features cannot be configured using the controller GUI.

• mDNS-AP feature is not supported in CAPWAP V6.

• ISE dynamic mDNS policy mobility is not supported.

• mDNS user profile mobility is not supported in guest anchors.

• Mobility: ISE dynamic mDNS policy creation in foreign controllers is inconsistent.

• Apple devices such as iPads and iPhones can discover Apple TV through Bluetooth. This might result in Apple TVs being visible to end users. Because Apple TVs are not supported on mDNS access policy, we recommend that you disable Bluetooth on Apple TVs.

Configuring Multicast DNS (GUI)

Step 1

Step 2

Configure the global mDNS parameters and the Master Services Database by following these steps: a) Choose Controller > mDNS > General.

b) Select or unselect the mDNS Global Snooping check box to enable or disable snooping of mDNS packets, respectively.

c) Enter the mDNS query interval in minutes. The query interval is the frequency at which the controller queries for a service.

d) Choose a service from the Select Service drop-down list.

Note

To add a new mDNS-supported service to the list, choose Other. Specify the service name and the service string. The controller snoops and learns about the mDNS service advertisements only if the service is available in the Master Services Database. The controller can snoop and learn a maximum of 64 services.

e) Select or unselect the Query Status check box to enable or disable an mDNS query for a service, respectively.

f) Click Add.

g) Click Apply.

h) To view the details of an mDNS service, hover your cursor over the blue drop-down arrow of a service, and choose

Details.

Configure an mDNS profile by following these steps: a) Choose Controller > mDNS > Profiles.

The controller has a default mDNS profile, which is default-mdns-profile. It is not possible to delete the default profile.

b) To create a new profile, click New, enter a profile name, and click Apply.

Cisco Wireless Controller Configuration Guide, Release 8.3

263

Configuring Multicast Domain Name System

Step 3

c) To edit a profile, click a profile name on the mDNS Profiles page; from the Service Name drop-down list, choose a service to be associated with the profile, and click Apply.

You can add multiple services to a profile.

Click Save Configuration.

What to Do Next

After creating a new profile, you must map the profile to an interface group, an interface, or a WLAN. Clients receive service advertisements only for the services associated with the profile. The highest priority is given to the profiles associated with interface groups, followed by the interface profiles, and then the WLAN profiles.

Each client is mapped to a profile based on the order of priority.

• Map an mDNS profile to an interface group by following these steps:

Choose Controller > Interface Groups.

Click the corresponding interface group name.

The Interface Groups > Edit page is displayed.

From the mDNS Profile drop-down list, choose a profile.

• Map an mDNS profile to an interface by following these steps:

Choose Controller > Interfaces.

Click the corresponding interface name.

The Interfaces > Edit page is displayed.

From the mDNS Profile drop-down list, choose a profile.

• Map an mDNS profile to a WLAN by following these steps:

Choose WLANs. click the WLAN ID to open the WLANs > Edit page.

Click the corresponding WLAN ID.

The WLANs > Edit page is displayed.

Click the Advanced tab.

Select the mDNS Snooping check box.

From the mDNS Profile drop-down list, choose a profile.

Note

The wireless controller advertises the services from the wired devices (such as Apple TVs) learnt over

VLANs, when:

• mDNS snooping is enabled in the WLAN Advanced options.

• mDNS profile is enabled either at interface group (if available), interface, or WLAN.

264

Cisco Wireless Controller Configuration Guide, Release 8.3

Configuring Multicast Domain Name System

Configuring Multicast DNS (CLI)

• Configure mDNS snooping by entering this command:

config mdns snooping {enable | disable}

• Configure mDNS services by entering this command:

config mdns service {{create service-name service-string origin {wireless | wired | all} lss {enable |

disable} [query] [enable | disable]} | delete service-name}

• Configure a query for an mDNS service by entering this command:

config mdns service query {enable | disable} service-name

• Configure a query interval for mDNS services by entering this command:

config mdns query interval value-in-minutes

• Configure an mDNS profile by entering this command:

config mdns profile {create | delete} profile-name

Note

If you try to delete an mDNS profile that is already associated with an interface group, an interface, or a WLAN, an error message is displayed.

• Configure mDNS services to a profile by entering this command:

config mdns profile service {add | delete} profile-name service-name

• Map an mDNS profile to an interface group by entering this command:

config interface group mdns-profile {interface-group-name | all} {mdns-profile-name | none}

Note

If the mDNS profile name is none, no profiles are attached to the interface group. Any existing profile that is attached is removed.

• View information about an mDNS profile that is associated with an interface group by entering this command:

show interface group detailed interface-group-name

• Map an mDNS profile to an interface by entering this command:

config interface mdns-profile {management | {interface-name | all}} {mdns-profile-name | none}

• View information about the mDNS profile that is associated with an interface by entering this command:

show interface detailed interface-name

• Configure mDNS for a WLAN by entering this command:

config wlan mdns {enable | disable} {wlan-id | all}

• Map an mDNS profile to a WLAN by entering this command:

config wlan mdns profile {wlan-id | all} {mdns-profile-name | none}

• View information about an mDNS profile that is associated with a WLAN by entering this command:

Cisco Wireless Controller Configuration Guide, Release 8.3

265

Configuring Multicast Domain Name System

show wlan wlan-id

• View information about all mDNS profiles or a particular mDNS profile by entering this command:

show mdns profile {summary | detailed mdns-profile-name}

• View information about all mDNS services or a particular mDNS service by entering this command:

show mdns service {summary | detailed mdns-service-name}

• View information about the mDNS domain names that are learned by entering this command:

show mdns domain-name-ip summary

• View the mDNS profile for a client by entering this command:

show client detail client-mac-address

• View the mDNS details for a network by entering this command:

show network summary

• Clear the mDNS service database by entering this command:

clear mdns service-database {all | service-name}

• View events related to mDNS by entering this command:

debug mdns message {enable | disable}

• View mDNS details of the events by entering this command:

debug mdns detail {enable | disable}

• View errors related to mDNS processing by entering this command:

debug mdns error {enable | disable}

• Configure debugging of all mDNS details by entering this command:

debug mdns all {enable | disable}

• Location Specific Service-related commands:

◦Enable or disable location specific service on a specific mDNS service or all mDNS services by entering this command:

config mdns service lss {enable | disable} {service-name | all}

Note

By default, LSS is in disabled state.

Impact on High Availability: Requires to be synchronized with the standby controller.

◦View the status of LSS by entering these commands:

Summary—show mdns service summary

Detailed—show mdns service detailed service-name

◦Configure troubleshooting HA-related mDNS by entering this command:

debug mdns ha {enable | disable}

• Origin-based service discovery-related commands:

266

Cisco Wireless Controller Configuration Guide, Release 8.3

Configuring Multicast Domain Name System

◦ Configure learning of services from wired, wireless, or both by entering this command:

config mdns service origin {Wireless | Wired | All} {service-name | all}

It is not possible to configure wired services if LSS is enabled and vice versa. It is not possible to enable LSS for wired-only service learn origin.

Impact on High Availability: Requires to be synchronized with the standby controller.

◦View the status of origin-based service discovery by entering this command:

Summary—show mdns service summary

Detailed—show mdns service detailed service-name

◦View all the service advertisements that are present in the controller, but not discovered because of restrictions on learning those services, by entering this command:

show mdns service not-learnt

Service advertisements across all VLANs and origin types that are not learned are displayed.

• Priority MAC address-related commands:

◦Configure per-service MAC addresses of service-providing devices to ensure that they are snooped and discovered even if the service provider database is full, by entering this command:

config mdns service priority-mac {add | delete} priority-mac-addr service-name ap-group

ap-group-name

The optional AP group is applicable only to wired service provider devices to give them a sense of location; these service providers are placed higher in the order than the other wired devices.

◦View the status of Priority MAC address by entering this command:

Detailed—show mdns service detailed service-name

• mDNS AP-related commands:

◦Enable or disable mDNS forwarding on an AP that is associated with the controller by entering this command:

config mdns ap {enable | disable} {ap-name | all} vlan vlan-id

There is no default mDNS AP. VLAN ID is an optional node.

Impact on High Availability: The static configuration is synchronized to the standby controller.

◦Configure the VLAN on which the AP should snoop, and forward the mDNS packets by entering this command:

config mdns ap vlan {add | delete} vlan-id ap-name

◦View all the APs for which mDNS forwarding is enabled by entering this command:

show mdns ap summary

Information about Bonjour gateway based on access policy

From 7.4 release WLC supports Bonjour gateway functionality on WLC itself for which you need not even enable multicast on the controller. The WLC explores all Bonjour discovery packets and does not forward them on AIR or Infra network.

Bonjour is Apple's version of Zeroconf - it is Multicast Domain Name System (mDNS) with DNS-SD (Domain

Name System-Service Discovery). Apple devices will advertise their services via IPv4 and IPv6 simultaneously

Cisco Wireless Controller Configuration Guide, Release 8.3

267

Configuring Multicast Domain Name System

(IPv6 link local and Globally Unique). To address this issue Cisco WLC acts as a Bonjour Gateway. The

WLC listens for Bonjour services and by caching those Bonjour advertisements (AirPlay, AirPrint etc) from the source/host e.g. AppleTV and responds to Bonjour clients when they ask/request for a service.

Bonjour gateway has inadequate capabilities to filter cached wired or wireless service instances based on the credentials of the querying client and its location.

Currently the limitations are:

• Location-Specific Services (LSS) filters the wireless service instances only while responding to a query from wireless clients. The filtering is based on the radio neighborhood of the querying client.

• LSS cannot filter wired service instance because of no sense of location.

• LSS filtering is per service type and not per client. It means that all clients receive the location based filtered response if LSS is enabled for the service type and clients cannot override the behavior.

• There is no other filtering mechanism based on client role or user-id.

The requirement is to have configuration per service instance.

Following are the three criteria of the service instance sharing:

• User-id

• Client-role

• Client location

The configuration can be applied to wired and wireless service instances. The response to any query is on the policy configured for each service instance. The response enables the selective sharing of service instances based on the location, user-id or role.

As the most service publishing devices are wired, the configuration allows filtering of wired services at par with the wireless service instances.

There are two levels of filtering client queries:

At the service type level by using the mDNS profile

At the service instance level using the access policy associated with the service.

Restrictions to the Bonjour gateway based on access policy

• The total number of policies that can be created is same as the number of service instances that are supported on the platform. Hundred policies can be supported; 99 policies and one default policy.

• The number of rules per policy is limited to one.

• Policy and rules can be created irrespective of the service instances. The policy is applied only when it is complete and discovers the target service instances.

• A service instance can be associated with a maximum of five policies.

• Five service groups can be assigned for a MAC address.

268

Cisco Wireless Controller Configuration Guide, Release 8.3

Configuring Multicast Domain Name System

Creating Bonjour Access Policy through Prime Infrastructure

The admin user can create the Bonjour access policy using the GUI of the Prime Infrastructure (PI).

Step 1

Step 2

Step 3

Step 4

Step 5

Choose Administration > AAA > Users > Add User.

Choose mDNS Policy Admin.

Add or remove the devices in the mDNS Device Filter. Click Save.

Add the users for a device in the Users list dialog box. Click Save.

Note

See Cisco Prime Infrastructure Administrator Guide for the release 2.2 for more details.

Configuring mDNS Service Groups (GUI)

Step 1

Step 2

Step 3

Step 4

Choose Controller > mDNS > mDNS Policies.

Select service group from the list of Group Names.

Under Service Instance List perform the following steps: a) Enter the service provider MAC address in MAC address.

b) Enter the name of service provider in Name. Click Add.

c) From the Location Type drop-down list, choose the type of location.

Note

If the location is selected as 'Any', the policy checks on the location attribute are not performed.

In the case of mDNS policy filtered by AP groups, the design is for substring match. The policy is applied on the first substring match.

Note

The list of current service instances associated with the service group is shown in a table.

Under Policy / Rule enter the role names and the user names as the criteria of enforcing the policy.

Cisco Wireless Controller Configuration Guide, Release 8.3

269

Configuring Multicast Domain Name System

Configuring mDNS Service Groups (CLI)

Step 1

Step 2

Step 3

Step 4

Step 5

Enable or disable the mDNS policy by entering this command: config mdns policy enable | disable

Create or delete a mDNS policy service group by entering this command: config mdns policy service-group create |

delete <service-group-name>

Configure the parameters of a service group by entering this command: config mdns policy service-group device-mac

add <service-group-name> <mac-addr> <device name> location-type [<AP_LOCATION | AP_NAME | AP_GROUP>]

device-location [<location string | any | same>]

Configure the user role for a service-group by entering this command: config mdns policy service-group user-role add

| delete <service-group-name> <user-role-name>

Configure the user name for a service-group by entering this command: config mdns policy service-group user-name

add | delete <service-group-name> <user-name>

270

Cisco Wireless Controller Configuration Guide, Release 8.3

C H A P T E R

Cisco WLC Security

•

FIPS, CC, and UCAPL, page 271

•

Cisco TrustSec, page 274

FIPS, CC, and UCAPL

Information About FIPS

Federal Information Processing Standard (FIPS) 140-2 is a security standard used to validate cryptographic modules. The cryptographic modules are produced by the private sector for use by the U.S. government and other regulated industries (such as financial and healthcare institutions) that collect, store, transfer, share and disseminate sensitive but unclassified (SBU) information.

FIPS 140-2 specifies that a cryptographic module should be a set of hardware, software, firmware, or some combination that implements cryptographic functions or processes, including cryptographic algorithms and, optionally, key generation, and is contained within a defined cryptographic boundary. FIPS specifies certain crypto algorithms as secure, and it also identifies which algorithm should be used if a cryptographic module is to be called FIPS compliant. For more information on FIPS, see http://csrc.nist.gov/ .

About Roles and Services

• AP Role—Role of an access point associated with the controller (MFP, 802.11i, iGTK).

• Client Role—Role of a wireless client associated with the controller.

• User Role—A management user with read only privileges.

• Crypto Officer (CO) Role—A management user with read and write privileges, who can perform the cryptographic initialization and management operations.

Note

There are four levels of increased security defined in FIPS 140-2.

Cisco Wireless Controller Configuration Guide, Release 8.3

271

FIPS, CC, and UCAPL

FIPS Self-Tests

A cryptographic module must perform power-up self-tests and conditional self-tests to ensure that it is functional.

Power-up self-tests run automatically after the device powers up. A device goes into FIPS mode only after all self-tests are successfully completed. If any self-test fails, the device logs a system message and moves into an error state.

Using a known-answer test (KAT), a cryptographic algorithm is run on data for which the correct output is already known, and then the calculated output is compared to the previously generated output. If the calculated output does not equal the known answer, the known-answer test fails.

Power-up self-tests include the following:

• Software integrity

• Algorithm tests

Conditional self-tests must be run when an applicable security function or operation is invoked. Unlike the power-up self-tests, conditional self-tests are executed each time their associated function is accessed.

The device uses a cryptographic algorithm known-answer test (KAT) to test FIPS mode for each FIPS

140-2-approved cryptographic function (encryption, decryption, authentication, and random number generation) implemented on the device. The device applies the algorithm to data for which the correct output is already known. It then compares the calculated output to the previously generated output. If the calculated output does not equal the known answer, the KAT fails.

Conditional self-tests run automatically when an applicable security function or operation is invoked. Unlike the power-up self-tests, conditional self-tests are executed each time their associated function is accessed.

Conditional self-tests include the following:

• Pair-wise consistency test—This test is run when a public or private key-pair is generated.

• Continuous random number generator test—This test is run when a random number is generated.

• Bypass

• Software load

Information About CC

The Common Criteria (CC) is a testing standard to verify that a product provides security functions that is claimed by its developer. CC evaluation is against a created protection profile (PP) or security target (ST).

The four security levels in FIPS 140-2 do not map directly to specific CC EALs or CC functional requirements.

For more information on CC, see Common Criterial Portal and CC evaluation and validation scheme .

To configure the controller into CC mode of operation, refer the Admin Guidance Document published under the Certified Product page of the Common Criterial Portal website .

After providing CC for the controller, the controller series name is listed in the Common Criterial Portal .

Click the Security Documents tab to view the list of documented available for the controller.

272

Cisco Wireless Controller Configuration Guide, Release 8.3

FIPS, CC, and UCAPL

Information About UCAPL

The US Department of Defense (DoD) Unified Capabilities Approved Product List (APL) certification process is the responsibility of the Defense Information Systems Agency (DISA) Unified Capabilities Certification

Office (UCCO). Certifications are performed by approved distributed testing centers including the Joint

Interoperability Test Command (JITC).

DoD customers can only purchase unified capabilities related equipment, both hardware and software, that has been certified. Certified equipment is listed on the DoD UC APL. UC APL certifications verify the system complies with and is configured consistent with the DISA Field Security Office (FSO) Security Technical

Implementation Guides (STIG).

For more information about the UC APL process, see Defense Information System Agency .

Configuring FIPS (CLI)

Step 1

Step 2

Configure FIPS on the controller by entering this command:

config switchconfig fips-prerequisite {enable | disable }

View the FIPS configuration by entering this command:

show switchconfig

Information similar to the following appears:

802.3x Flow Control Mode......................... Disable

FIPS prerequisite features....................... Enabled

WLANCC prerequisite features..................... Enabled

UCAPL prerequisite features...................... Disabled secret obfuscation............................... Enabled

Configuring CC (CLI)

Before You Begin

FIPS must be enabled on the controller.

Step 1

Step 2

Configure FIPS on the controller by entering this command:

config switchconfig wlancc {enable | disable }

View the FIPS configuration by entering this command:

show switchconfig

Information similar to the following appears:

802.3x Flow Control Mode......................... Disable

FIPS prerequisite features....................... Enabled

WLANCC prerequisite features..................... Enabled

Cisco Wireless Controller Configuration Guide, Release 8.3

273

Cisco TrustSec

UCAPL prerequisite features...................... Disabled secret obfuscation............................... Enabled

Configuring UCAPL (CLI)

Before You Begin

FIPS and WLAN CC must be enabled on the controller.

Step 1

Step 2

Configure UCAPL on the controller by entering this command:

config switchconfig ucapl {enable | disable }

View the FIPS configuration by entering this command:

show switchconfig

Information similar to the following appears:

802.3x Flow Control Mode......................... Disable

FIPS prerequisite features....................... Enabled

WLANCC prerequisite features..................... Enabled

UCAPL prerequisite features...................... Enabled secret obfuscation............................... Enabled

Cisco TrustSec

Information About Cisco TrustSec

Cisco TrustSec enables organizations to secure their networks and services through identity-based access control to anyone, anywhere, anytime. The solution also offers data integrity and confidentiality services, policy-based governance, and centralized monitoring, troubleshooting, and reporting services. Cisco TrustSec can be combined with personalized, professional service offerings to simplify solution deployment and management, and is a foundational security component to Cisco Borderless Networks.

The Cisco TrustSec security architecture helps build secure networks by establishing domains of trusted network devices. Each device in the domain is authenticated by its peers. Communication on the links between the devices in the domain is secured with a combination of encryption, message integrity check, and data path replay protection mechanisms. Cisco TrustSec uses a device and user credentials acquired during authentication for classifying the packets by security groups (SGs), as they enter the network. This packet classification is maintained by tagging packets on ingress to the Cisco TrustSec network so that they can be correctly identified to apply security and other policy criteria along the data path. The tag, called the security group tag (SGT), allows the network to enforce the access control policy by enabling the end-point device to act upon the SGT to filter traffic. Note that the Cisco TrustSec security group tag is applied only when you enable AAA override on a WLAN.

274

Cisco Wireless Controller Configuration Guide, Release 8.3

Cisco TrustSec

One of the components of Cisco TrustSec architecture is the security group-based access control. In the security group-based access control component, access policies in the Cisco TrustSec domain are topology-independent, based on the roles (as indicated by the security group number) of source and destination devices rather than on network addresses. Individual packets are tagged with the security group number of the source.

The Cisco TrustSec solution is implemented across the following three distinct phases:

• Client classification at ingress by a centralized policy database (Cisco ISE) and assigning unique SGT to clients based on client identity attributes such as the role and so on.

• Propagation of IP-to-SGT binding to neighboring devices using the SGT Exchange Protocol (SXP) or inline tagging methods or both.

• Security Group Access Control List (SGACL) policy enforcement. Cisco AP is the enforcement point for central or local switching (central authentication).

SGT Exchange Protocol

Cisco devices use the SGT Exchange Protocol (SXP) to propagate SGTs across network devices that do not have hardware support for Cisco TrustSec. The SXP is the software solution to eliminate the need for Cisco

TrustSec hardware upgrade on all Cisco switches. Cisco WLC supports the SXP as part of Cisco TrustSec architecture. The SXP sends SGT information to the Cisco TrustSec-enabled switches so that appropriate role-based access control lists (RBAC lists) can be activated depending on the role information present in the

SGT. To implement the SXP on a network, only the egress distribution switch has to be Cisco TrustSec-enabled, and all the other switches can be non-Cisco TrustSec-capable switches.

The SXP runs between the access layer and the distribution switch or between two distribution switches. The

SXP uses TCP as the transport layer. Cisco TrustSec authentication is performed for the host (client) joining the network on the access layer switch, which is similar to an access switch with Cisco TrustSec-enabled hardware. The access layer switch is not Cisco TrustSec hardware enabled. Therefore, data traffic is not encrypted or cryptographically authenticated when it passes through the access layer switch. The SXP is used to pass the IP address of the authenticated device, which is a wireless client, and the corresponding SGT up to the distribution switch. If the distribution switch is Cisco TrustSec hardware enabled, the switch inserts the

SGT into the packet on behalf of the access layer switch. If the distribution switch is not Cisco TrustSec hardware enabled, the SXP on the distribution switch passes the IP-SGT mapping to all the distribution switches that have Cisco TrustSec hardware. On the egress side, the enforcement of the RBAC lists occurs at the egress L3 interface on the distribution switch.

The following are some guidelines for Cisco TrustSec SXP:

• The SXP is supported only on the following security policies:

◦WPA2-dot1x

◦WPA-dot1x

◦MAC filtering using RADIUS servers

◦Web authentication using RADIUS servers for user authentication

• The SXP is supported for both IPv4 and IPv6 clients.

• By default, the Cisco WLC always works in the Speaker mode.

• From Release 8.3, the SXP on the Cisco WLC is supported for both centrally and locally switched networks.

• IP-SGT mapping can be done on the WLANs as well for clients that are not authenticated by Cisco ISE.

Cisco Wireless Controller Configuration Guide, Release 8.3

275

Cisco TrustSec

For more information about Cisco TrustSec, see http://www.cisco.com/c/en/us/solutions/enterprise-networks/trustsec/index.html

Guidelines and Restrictions on Cisco TrustSec

• SXP is supported only in centrally switched networks that have central authentication.

• By default, SXP is supported for APs that work in local mode only.

• The configuration of the default password should be consistent for both the Cisco WLC and the switch.

• Fault tolerance is not supported because fault tolerance requires local switching on APs.

• Static IP-SGT mapping for local authentication of users is not supported.

• IP-SGT mapping requires authentication with external Cisco ISE servers.

• In auto-anchor/guest-anchor mobility, the SGT information passed by the RADIUS server to a foreign

Cisco WLC can be communicated to the anchor Cisco WLC through the EoIP/CAPWAP mobility tunnel.

The anchor Cisco WLC can then build the SGT-IP mapping and communicate it to another peer via

SXP.

Configuring Cisco TrustSec

Configuring Cisco TrustSec on Cisco WLC (GUI)

Step 1

Step 2

Step 3

Choose Security > TrustSec > General.

The General page is displayed.

Check the CTS check box to enable Cisco TrustSec. By default, Cisco TrustSec is in disabled state.

Save the configuration.

Configuring Cisco TrustSec on Cisco WLC (CLI)

• Enable Cisco TrustSec on Cisco WLC by entering this command:

config cts enable

Note

If you enable Cisco TrustSec, the SGACL is also enabled in the Cisco WLC. Also, you will need to manually enable inline tagging.

276

Cisco Wireless Controller Configuration Guide, Release 8.3

Cisco TrustSec

Configuring SXP

Configuring SXP on Cisco WLC (GUI)

Step 1

Step 2

Step 3

Step 4

Step 5

Choose Security > TrustSec > SXP Config.

The SXP Configuration page is displayed with the following SXP configuration details:

• Total SXP Connections—Number of SXP connections that are configured.

• SXP State—Status of SXP connections as either disabled or enabled.

• SXP Mode—SXP mode of the Cisco WLC. The Cisco WLC is always set to Speaker mode for SXP connections.

• Default Password—Password for MD5 authentication of SXP messages. We recommend that the password contain a minimum of 6 characters.

• Default Source IP—IP address of the management interface. SXP uses the default source IP address for all new

TCP connections.

• Retry Period—SXP retry timer. The default value is 120 seconds (2 minutes). The valid range is 0 to 64000 seconds. The SXP retry period determines how often the controller retries for an SXP connection. When an SXP connection is not successfully set up, the controller makes a new attempt to set up the connection after the SXP retry period timer expires. Setting the SXP retry period to 0 seconds disables the timer and retries are not attempted.

This page also displays the following information about SXP connections:

• Peer IP Address—The IP address of the peer, that is, the IP address of the next-hop switch to which the Cisco

WLC is connected. There is no effect on the existing TCP connections when you configure a new peer connection.

• Source IP Address—The IP address of the source, that is, the management IP address of the Cisco WLC.

• Connection Status—Status of the SXP connection.

From the SXP State drop-down list, choose Enabled to enable SXP.

Enter the default password that should be used to make an SXP connection. We recommend that the password contain a minimum of 6 characters.

In the Retry Period field, enter the time, in seconds, that determines how often the Cisco TrustSec software retries for an SXP connection.

Click Apply to commit your changes.

Configuring SXP on Cisco WLC (CLI)

• Enable or disable the SXP on the controller by entering this command:

config cts sxp {enable | disable}

• Configure the default password for MD5 authentication of SXP messages by entering this command:

config cts sxp default password password

Cisco Wireless Controller Configuration Guide, Release 8.3

277

Cisco TrustSec

• Configure the IP address of the next-hop switch with which the controller is connected by entering this command:

config cts sxp connection peer ip-address

• Configure the interval between connection attempts by entering this command:

config cts sxp retry period time-in-seconds

• Remove an SXP connection by entering this command:

config cts sxp connection delete ip-address

• See a summary of the SXP configuration by entering this command:

show cts sxp summary

The following is a sample output of this command:

SXP State........................................ Enable

SXP Mode......................................... Speaker

Default Password................................. ****

Default Source IP................................ 209.165.200.224

Connection retry open period .................... 120

• See the list of SXP connections that are configured by entering this command:

show cts sxp connections

The following is a sample output of this command:

Total num of SXP Connections..................... 1

SXP State........................................ Enable

Peer IP Source IP Connection Status

-----------------------------

209.165.200.229

209.165.200.224

-----------------

• Establish connection between the controller and a Cisco Nexus 7000 Series switch by following either of these steps:

◦Enter the following commands:

config cts sxp version sxp version 1 or 2 1

2 config cts sxp disable

3 config cts sxp enable

◦If SXP version 2 is used on the controller and version 1 is used on the Cisco Nexus 7000 Series switch, an amount of retry period is required to establish the connection. We recommend that you initially have less interval between connection attempts. The default is 120 seconds.

278

Cisco Wireless Controller Configuration Guide, Release 8.3

P A R T

III

Mobility Groups

•

Overview, page 281

•

Configuring Auto-Anchor Mobility, page 287

•

Mobility Groups, page 295

•

Configuring New Mobility, page 309

•

Monitoring and Validating Mobility, page 313

C H A P T E R

Overview

•

Information About Mobility, page 281

Information About Mobility

Mobility, or roaming, is a wireless LAN client’s ability to maintain its association seamlessly from one access point to another securely and with as little latency as possible. This section explains how mobility works when controllers are included in a wireless network.

When a wireless client associates and authenticates to an access point, the access point’s controller places an entry for that client in its client database. This entry includes the client’s MAC and IP addresses, security context and associations, quality of service (QoS) contexts, the WLAN, and the associated access point. The controller uses this information to forward frames and manage traffic to and from the wireless client.

Cisco Wireless Controller Configuration Guide, Release 8.3

281

Information About Mobility

This figure shows a wireless client that roams from one access point to another when both access points are joined to the same controller.

Figure 25: Intracontroller Roaming

When the wireless client moves its association from one access point to another, the controller simply updates the client database with the newly associated access point. If necessary, new security context and associations are established as well.

The process becomes more complicated, however, when a client roams from an access point joined to one controller to an access point joined to a different controller. It also varies based on whether the controllers are operating on the same subnet.

282

Cisco Wireless Controller Configuration Guide, Release 8.3

Information About Mobility

This figure shows intercontroller roaming, which occurs when the wireless LAN interfaces of the controllers are on the same IP subnet.

Figure 26: Intercontroller Roaming

When the client associates to an access point joined to a new controller, the new controller exchanges mobility messages with the original controller, and the client database entry is moved to the new controller. New security context and associations are established if necessary, and the client database entry is updated for the new access point. This process remains transparent to the user.

Note

All clients configured with 802.1X/Wi-Fi Protected Access (WPA) security complete a full authentication in order to comply with the IEEE standard.

Cisco Wireless Controller Configuration Guide, Release 8.3

283

Information About Mobility

This figure shows intersubnet roaming, which occurs when the wireless LAN interfaces of the controllers are on different IP subnets.

Figure 27: Intersubnet Roaming

Inter-subnet roaming is similar to inter-controller roaming in that the controllers exchange mobility messages on the client roam. However, instead of moving the client database entry to the new controller, the original controller marks the client with an “Anchor” entry in its own client database. The database entry is copied to the new controller client database and marked with a “Foreign” entry in the new controller. The roam remains transparent to the wireless client, and the client maintains its original IP address.

In inter-subnet roaming, WLANs on both anchor and foreign controllers need to have the same network access privileges and no source-based routing or source-based firewalls in place. Otherwise, the clients may have network connectivity issues after the handoff.

In a static anchor setup using controllers and ACS, if AAA override is enabled to dynamically assign VLAN and QoS, the foreign controller updates the anchor controller with the right VLAN after a Layer 2 authentication

(802.1x). For Layer 3 RADIUS authentication, the RADIUS requests for authentication are sent by the anchor controller.

Mobility is not supported for SSIDs with security type configured for Webauth on MAC filter failure.

If the management VLAN of one Cisco WLC is present as a dynamic VLAN on another Cisco WLC, the mobility feature is not supported.

Note

If a client roams in web authentication state, the client is considered as a new client on another controller instead of considering it as a mobile client.

284

Cisco Wireless Controller Configuration Guide, Release 8.3

Information About Mobility

Note

When the primary and secondary WLCs fail to ping each other’s IPv6 addresses, and they are in the same

VLAN, you need to disable snooping to get the WLCs to ping each other successfully.

Note

New Mobility with WebAuth and MAC filter is not supported. For a client, if L2 authentication fails and it falls back to L3 authentication and then tries to roam to a different Cisco WLC, the roaming will fail.

The same behavior is applicable to FlexConnect central switching and local mode as well.

Note

Cisco Wireless Controllers (that are mobility peers) must use the same DHCP server to have an updated client mobility move count on intra-VLAN.

Cisco Wireless Controller Configuration Guide, Release 8.3

285

Information About Mobility

286

Cisco Wireless Controller Configuration Guide, Release 8.3

C H A P T E R

Configuring Auto-Anchor Mobility

•

Information About Auto-Anchor Mobility, page 287

•

Guest Anchor Priority, page 291

Information About Auto-Anchor Mobility

You can use auto-anchor mobility (also called guest tunneling) to improve load balancing and security for roaming clients on your wireless LANs. Under normal roaming conditions, client devices join a wireless LAN and are anchored to the first controller that they contact. If a client roams to a different subnet, the controller to which the client roamed sets up a foreign session for the client with the anchor controller. However, when you use the auto-anchor mobility feature, you can specify a controller or set of controllers as the anchor points for clients on a wireless LAN.

In auto-anchor mobility mode, a subset of a mobility group is specified as the anchor controllers for a WLAN.

You can use this feature to restrict a WLAN to a single subnet, regardless of a client’s entry point into the network. Clients can then access a guest WLAN throughout an enterprise but still be restricted to a specific subnet. Auto-anchor mobility can also provide geographic load balancing because the WLANs can represent a particular section of a building (such as a lobby, a restaurant, and so on), effectively creating a set of home controllers for a WLAN. Instead of being anchored to the first controller that they happen to contact, mobile clients can be anchored to controllers that control access points in a particular vicinity.

When a client first associates to a controller of a mobility group that has been preconfigured as a mobility anchor for a WLAN, the client associates to the controller locally, and a local session is created for the client.

Clients can be anchored only to preconfigured anchor controllers of the WLAN. For a given WLAN, you should configure the same set of anchor controllers on all controllers in the mobility group.

When a client first associates to a controller of a mobility group that has not been configured as a mobility anchor for a WLAN, the client associates to the controller locally, a local session is created for the client, and the client is announced to the other controllers in the mobility list. If the announcement is not answered, the controller contacts one of the anchor controllers configured for the WLAN and creates a foreign session for the client on the local switch. Packets from the client are encapsulated through a mobility tunnel using EtherIP and sent to the anchor controller, where they are decapsulated and delivered to the wired network. Packets to the client are received by the anchor controller and forwarded to the foreign controller through a mobility tunnel using EtherIP. The foreign controller decapsulates the packets and forwards them to the client.

If multiple controllers are added as mobility anchors for a particular WLAN on a foreign controller, the foreign controller internally sorts the controller by their IP address. The controller with the lowest IP address is the

Cisco Wireless Controller Configuration Guide, Release 8.3

287

Information About Auto-Anchor Mobility

first anchor. For example, a typical ordered list would be 172.16.7.25, 172.16.7.28, 192.168.5.15. If the first client associates to the foreign controller's anchored WLAN, the client database entry is sent to the first anchor controller in the list, the second client is sent to the second controller in the list, and so on, until the end of the anchor list is reached. The process is repeated starting with the first anchor controller. If any of the anchor controller is detected to be down, all the clients anchored to the controller are deauthenticated, and the clients then go through the authentication/anchoring process again in a round-robin manner with the remaining controller in the anchor list. This functionality is also extended to regular mobility clients through mobility failover. This feature enables mobility group members to detect failed members and reroute clients.

Restrictions on Auto-Anchor Mobility

• Mobility list members can send ping requests to one another to check the data and control paths among them to find failed members and reroute clients. You can configure the number and interval of ping requests that are sent to each anchor controller. This functionality provides guest N+1 redundancy for guest tunneling and mobility failover for regular mobility.

• You must add controllers to the mobility group member list before you can designate them as mobility anchors for a WLAN.

• You can configure multiple controllers as mobility anchors for a WLAN.

• You must configure the WLANs on both the foreign controller and the anchor controller with mobility anchors. On the anchor controller, configure the anchor controller itself as a mobility anchor. On the foreign controller, configure the anchor as a mobility anchor.

• It is not possible for clients, WGB, and wired clients to directly connect to a DMZ guest anchor and move to a foreign controller.

• Auto-anchor mobility is not supported for use with DHCP option 82.

• When using the guest N+1 redundancy and mobility failover features with a firewall, make sure that the following ports are open:

◦UDP 16666 for tunnel control traffic

◦IP Protocol 97 for user data traffic

◦UDP 161 and 162 for SNMP

• In case of roaming between anchor controller and foreign mobility, the client addresses learned at the anchor controller is shown at the foreign controller. You must check the foreign controller to view the

RA throttle statistics.

• For Layer 3 RADIUS authentication, the RADIUS requests for authentication are sent by the anchor controller.

• The mobility anchor is not supported on virtual wireless LAN controllers.

• In a guest anchor Cisco WLC deployment, ensure that the foreign Cisco WLC does not have a WLAN mapped to a VLAN that is associated with the guest anchor Cisco WLC.

• In Old Mobility, when roaming from foreign to anchor WLC, the other foreign WLCs in the mobility group do not receive mobile announce messages.

288

Cisco Wireless Controller Configuration Guide, Release 8.3

Information About Auto-Anchor Mobility

Configuring Auto-Anchor Mobility (GUI)

Step 1

Step 2

Step 3

Step 4

Step 5

Step 6

Step 7

Step 8

Configure the controller to detect failed anchor controllers within a mobility group as follows: a) Choose Controller > Mobility Management > Mobility Anchor Config to open the Mobility Anchor Config page.

b) In the Keep Alive Count text box, enter the number of times a ping request is sent to an anchor controller before the anchor is considered to be unreachable. The valid range is 3 to 20, and the default value is 3.

c) In the Keep Alive Interval text box, enter the amount of time (in seconds) between each ping request that is sent to an anchor controller. The valid range is 1 to 30 seconds, and the default value is 10 seconds.

d) In the DSCP Value text box, enter the DSCP value. The default is 0.

Note

While configuring the Mobility DSCP value, the mobility control socket (i.e control messages exchanged between mobility peers only and not the data) is also updated. The configured value must reflect in the IPV4 header TOS field. This is a global configuration on the controller that is used to communicate among configured mobility peers only.

e) Click Apply to commit your changes.

Choose WLANs to open the WLANs page.

Click the blue drop-down arrow for the desired WLAN or wired guest LAN and choose Mobility Anchors. The Mobility

Anchors page appears.

This page lists the controllers that have already been configured as mobility anchors and shows the current state of their data and control paths. Controllers within a mobility group communicate among themselves over a well-known UDP port and exchange data traffic through an Ethernet-over-IP (EoIP) tunnel. They send mpings, which test mobility control packet reachability over the management interface over mobility UDP port 16666 and they send epings, which test the mobility data traffic over the management interface over EoIP port 97. The Control Path text box shows whether mpings have passed (up) or failed (down), and the Data Path text box shows whether epings have passed (up) or failed (down).

If the Data or Control Path text box shows “down,” the mobility anchor cannot be reached and is considered failed.

Select the IPv4/IPv6 address of the controller to be designated a mobility anchor in the Switch IP Address (Anchor) drop-down list.

Click Mobility Anchor Create. The selected controller becomes an anchor for this WLAN or wired guest LAN.

Note

To delete a mobility anchor for a WLAN or wired guest LAN, hover your cursor over the blue drop-down arrow for the anchor and choose Remove.

Click Save Configuration.

Repeat Step 4 and Step 6 to set any other controllers as mobility anchors for this WLAN or wired guest LAN.

Configure the same set of mobility anchors on every controller in the mobility group.

Configuring Auto-Anchor Mobility (CLI)

• The controller is programmed to always detect failed mobility list members. To change the parameters for the ping exchange between mobility members, enter these commands:

◦config mobility group keepalive count count—Specifies the number of times a ping request is sent to a mobility list member before the member is considered to be unreachable. The valid range is 3 to 20, and the default value is 3.

Cisco Wireless Controller Configuration Guide, Release 8.3

289

Information About Auto-Anchor Mobility

◦config mobility group keepalive interval seconds—Specifies the amount of time (in seconds) between each ping request sent to a mobility list member. The valid range is 1 to 30 seconds, and the default value is 10 seconds.

• Disable the WLAN or wired guest LAN for which you are configuring mobility anchors by entering this command:

config {wlan | guest-lan} disable {wlan_id | guest_lan_id}

• Create a new mobility anchor for the WLAN or wired guest LAN by entering one of these commands:

◦config mobility group anchor add {wlan | guest-lan} {wlan_id | guest_lan_id}

anchor_controller_ip_address

◦config {wlan | guest-lan} mobility anchor add {wlan_id | guest_lan_id}

anchor_controller_ip_address

Note

The wlan_id or guest_lan_id must exist and be disabled, and the

anchor_controller_ip_address must be a member of the default mobility group.

Note

Auto-anchor mobility is enabled for the WLAN or wired guest LAN when you configure the first mobility anchor.

• Delete a mobility anchor for the WLAN or wired guest LAN by entering one of these commands:

◦config mobility group anchor delete {wlan | guest-lan} {wlan_id | guest_lan_id} anchor_controller_ip_address

◦config {wlan | guest-lan} mobility anchor delete {wlan_id | guest_lan_id} anchor_controller_ip_address

Note

The wlan_id or guest_lan_id must exist and be disabled.

Note

Deleting the last anchor disables the auto-anchor mobility feature and resumes normal mobility for new associations.

• Save your settings by entering this command:

save config

• See a list and status of controllers configured as mobility anchors for a specific WLAN or wired guest

LAN by entering this command:

show mobility anchor {wlan | guest-lan} {wlan_id | guest_lan_id}

290

Cisco Wireless Controller Configuration Guide, Release 8.3

Guest Anchor Priority

Note

The wlan_id and guest_lan_id parameters are optional and constrain the list to the anchors in a particular WLAN or guest LAN. To see all of the mobility anchors on your system, enter the show mobility anchor command.

The Status text box shows one of these values:

UP—The controller is reachable and able to pass data.

CNTRL_PATH_DOWN—The mpings failed. The controller cannot be reached through the control path and is considered failed.

DATA_PATH_DOWN—The epings failed. The controller cannot be reached and is considered failed.

CNTRL_DATA_PATH_DOWN—Both the mpings and epings failed. The controller cannot be reached and is considered failed.

• See the status of all mobility group members by entering this command:

show mobility summary

• Troubleshoot mobility issues by entering these commands:

◦debug mobility handoff {enable | disable}—Debugs mobility handoff issues.

◦debug mobility keep-alive {enable | disable} all—Dumps the keepalive packets for all mobility anchors.

◦debug mobility keep-alive {enable | disable} IP_address—Dumps the keepalive packets for a specific mobility anchor.

Guest Anchor Priority

The guest anchor priority feature provides a mechanism that gives "active/standby" load distribution amongst the anchor WLCs. This is achieved by assigning a fixed priority to each anchor WLC, by distributing the load to highest priority WLC and in round-robin fashion if they have the same priority value.

Releases Prior to 8.1

With Release 8.1

All guest clients are load balanced in round robin fashion amongst anchor WLCs

All guest clients are sent to anchor controller with highest priority in relation to local internal WLC

If an anchor fails, guest clients will be load balanced amongst remaining anchor WLCs

If an anchor fails, guest clients will be sent to the next highest priority or round robin if remaining anchors have same priority value

You can configure a priority to the guest anchor when you configure a WLAN. Priority values range from 1

(high) to 3 (low) or primary, secondary or tertiary and defined priority is displayed with guest anchor. Only one priority value is allowed per anchor WLC. Selection of guest anchor is round-robin based on a single priority value. If a guest anchor is down, the fallback would be on guest anchors with equal priority. If all guest anchors with same priority value are down, the selection would be on a round-robin basis on next highest

Cisco Wireless Controller Configuration Guide, Release 8.3

291

Guest Anchor Priority

priority and so on. Default priority value is 3. If WLC is upgraded to Release 8.1, it will be marked with priority 3. Priority configurations are retained across reboots. The priority configuration would be synchronized on HA pair for seamless switchover. Same set of rules apply in determining the anchor WLC regardless of

IPv4 and/or IPv6 addressing. That is, highest priority value is determinant and not addressing including dual stack case.

Restrictions

• No hard limit on the number of times a priority value is used

• Feature applies only to wireless and "old" mobility model

• Maximum supported anchor per WLAN is 24 (same as maximum anchor per WLAN in releases prior to 8.1)

• Downgrading from Release 8.1 would void this feature since it is not supported on earlier images

• If a guest anchor with higher priority comes up, the existing connections will not shift to the new high priority anchor and only the new connections will go to it

• This feature is applicable when all internal and anchor WLCs are using Release 8.1

• There should not be a local address with priority of zero at the Internal/Foreign controller. Priority 0 in the output indicates a local IP address. For example at the anchor WLC on DMZ with tunnel termination

Deployment Considerations

• Priority configuration should only be done on foreign controller WLAN. On the mobility list if you are seeing value zero and non-zero that means the same controller is acting as Anchor for few WLANs and foreign controller for few WLAN, if you have WLC in DMZ and there is no APs connected to it, then we should not see any non-zero priority for any of its WLANs, as this should be the terminating point for all the clients on the network.

• Ideally we should not see priority zero on foreign WLC and non-zero on anchor WLC. example:

10.10.10.10(SF) and 20.20.20.20(NY) should not have any priority with zero and DMZ controller

172.10.10.10(SF) and 172.20.20.20(NY) should not have any priority with non-zero values.

• Here priority values zero is not configurable when we select the controller own IP Address as anchor.

It will automatically set the priority zero if controller own IP address is selected as anchor.

Examples

• Local anchor WLCs may be grouped together with higher priority value than group of remote anchor

WLCs

• Guest client traffic goes to Anchor WLC(s) that is/are local to internal WLC rather than remote one(s) due to having higher priority value

• Guest client traffic will be load balanced in round-robin across local anchor WLCs since local anchors have same priority value

• If all local anchor WLCs fail then traffic will be load balanced in round-robin across remote anchor

WLC with next priority level

292

Cisco Wireless Controller Configuration Guide, Release 8.3

Guest Anchor Priority

Configuring Guest Anchor Priority (GUI)

Step 1

Step 2

Step 3

Choose WLANs.

Mouse over the blue down arrow and click Mobility Anchors.

On the Mobility Anchors page, select the mobility anchor from the Switch IP Address (Anchor) drop-down list and assign a priority.

Configuring Guest Anchor Priority (CLI)

• To configure Guest Anchor priority:

config wlan mobility anchor add wlan-id ip-addr priority prioirity-number

• To validate proper anchor WLC through assigned client address:

show client summary ip

• To check whether the expected anchor is getting the request:

debug mobility handoff enable

• To check the anchor priority list of a WLAN:

test mobility anchor-prioritylist wlan-id

Cisco Wireless Controller Configuration Guide, Release 8.3

293

Guest Anchor Priority

294

Cisco Wireless Controller Configuration Guide, Release 8.3

C H A P T E R

Mobility Groups

•

Information About Mobility, page 295

•

Information About Mobility Groups, page 299

•

Prerequisites for Configuring Mobility Groups, page 304

•

Configuring Mobility Groups (GUI), page 306

•

Configuring Mobility Groups (CLI), page 307

Information About Mobility

Cisco Wireless Controller Configuration Guide, Release 8.3

295

Information About Mobility

This figure shows a wireless client that roams from one access point to another when both access points are joined to the same controller.

Figure 28: Intracontroller Roaming

296

Cisco Wireless Controller Configuration Guide, Release 8.3

Information About Mobility

This figure shows intercontroller roaming, which occurs when the wireless LAN interfaces of the controllers are on the same IP subnet.

Figure 29: Intercontroller Roaming

Note

All clients configured with 802.1X/Wi-Fi Protected Access (WPA) security complete a full authentication in order to comply with the IEEE standard.

Cisco Wireless Controller Configuration Guide, Release 8.3

297

Information About Mobility

This figure shows intersubnet roaming, which occurs when the wireless LAN interfaces of the controllers are on different IP subnets.

Figure 30: Intersubnet Roaming

(802.1x). For Layer 3 RADIUS authentication, the RADIUS requests for authentication are sent by the anchor controller.

Mobility is not supported for SSIDs with security type configured for Webauth on MAC filter failure.

If the management VLAN of one Cisco WLC is present as a dynamic VLAN on another Cisco WLC, the mobility feature is not supported.

Note

If a client roams in web authentication state, the client is considered as a new client on another controller instead of considering it as a mobile client.

298

Cisco Wireless Controller Configuration Guide, Release 8.3

Information About Mobility Groups

Note

When the primary and secondary WLCs fail to ping each other’s IPv6 addresses, and they are in the same

VLAN, you need to disable snooping to get the WLCs to ping each other successfully.

Note

The same behavior is applicable to FlexConnect central switching and local mode as well.

Note

Cisco Wireless Controllers (that are mobility peers) must use the same DHCP server to have an updated client mobility move count on intra-VLAN.

Information About Mobility Groups

A mobility group is a set of controllers, identified by the same mobility group name, that defines the realm of seamless roaming for wireless clients. By creating a mobility group, you can enable multiple controllers in a network to dynamically share information and forward data traffic when inter-controller or inter-subnet roaming occurs. Controllers in the same mobility group can share the context and state of client devices as well as their list of access points so that they do not consider each other’s access points as rogue devices. With this information, the network can support inter-controller wireless LAN roaming and controller redundancy.

Note

When an AP moves from one WLC to another WLC (when both WLCs are mobility peers), a client associated to the first WLC before the move may be anchored to it even after the move. To prevent such a scenario, you should remove the mobility peer configuration of the WLC.

Cisco Wireless Controller Configuration Guide, Release 8.3

299

Information About Mobility Groups

Note

Controllers do not have to be of the same model to be a member of a mobility group. Mobility groups can be comprised of any combination of controller platforms.

Figure 31: Example of a Single Mobility Group

As shown above, each controller is configured with a list of the other members of the mobility group. Whenever a new client joins a controller, the controller sends out a unicast message (or multicast message if mobility multicast is configured) to all of the controllers in the mobility group. The controller to which the client was previously connected passes on the status of the client.

For example, if a controller supports 6000 access points, a mobility group that consists of 24 such controllers supports up to 144,000 access points (24 * 6000 = 144,000 access points).

Mobility groups enable you to limit roaming between different floors, buildings, or campuses in the same enterprise by assigning different mobility group names to different controllers within the same wireless network.

You can configure both IPv4 and IPv6 multicast address for a mobility group. When both the address formats are configured:

• For all IPv4 mobility group members in the mobility group, the IPv4 multicast group is displayed in the mobility summary information.

• For all IPv6 mobility group members in the mobility group, the IPv6 multicast group is displayed in the mobility summary information.

300

Cisco Wireless Controller Configuration Guide, Release 8.3

Information About Mobility Groups

• If you have configured IPv4 multicast for a mobility group, the IPv4 multicast address is not displayed in the mobility summary information if there are no IPv4 mobility group members.

• If you have configured IPv6 multicast for a mobility group, the IPv6 multicast address is not displayed in the mobility summary information if there are no IPv6 mobility group members.

This figure shows the results of creating distinct mobility group names for two groups of controllers.

Figure 32: Two Mobility Groups

The controllers in the ABC mobility group share access point and client information with each other. The controllers in the ABC mobility group do not share the access point or client information with the XYZ controllers, which are in a different mobility group. Likewise, the controllers in the XYZ mobility group do not share access point or client information with the controllers in the ABC mobility group. This feature ensures mobility group isolation across the network.

Every controller maintains information about its peer controllers in a mobility list. Controllers can communicate across mobility groups and clients may roam between access points in different mobility groups if the controllers are included in each other’s mobility lists. In the following example, controller 1 can communicate with either controller 2 or 3, but controller 2 and controller 3 can communicate only with controller 1 and not with each other. Similarly, clients can roam between controller 1 and controller 2 or between controller 1 and controller

3 but not between controller 2 and controller 3.

Cisco Wireless Controller Configuration Guide, Release 8.3

301

Information About Mobility Groups

Table 12: Example

Controller 1

Mobility group: A

Mobility list:

Controller 1 (group A)

Controller 2 (group A)

Controller 3 (group C) ?

Controller 2

Mobility group: A

Mobility list:

Controller 1 (group A)

Controller 2 (group A)

Controller 3

Mobility group: C

Mobility list:

Controller 1 (group A)

Controller 3 (group C)

In a mobility list, the following combinations of mobility groups and members are allowed:

• 3 mobility groups with 24 members in each group

• 12 mobility groups with 6 members in each group

• 24 mobility groups with 3 members in each group

• 72 mobility groups with 1 member in each group

The controller supports seamless roaming across multiple mobility groups. During seamless roaming, the client maintains its IP address across all mobility groups; however, Cisco Centralized Key Management

(CCKM) and proactive key caching (PKC) are supported only for inter-mobility-group roaming. When a client crosses a mobility group boundary during a roam, the client is fully authenticated, but the IP address is maintained, and mobility tunneling is initiated for Layer 3 roaming.

Note

When a controller is added to a mobility group, some of the APs (which are running in local mode) do not get the complete controllers list updated, those APs are connected to controllers that are in the same mobility group. You can view the controller list in the APs using the command "show capwap client config" AP-NAME command. For example, if the mobility group is for 19 controllers and then you add two more controllers to the mobility group, the AP shows 19 controllers instead of 21 in its list. To address this issue, you can reboot the AP or move it to another controller that is part of the same mobility group to get the controller list updated. This issue is observed in AP1242 connected to different 5508 controllers running code 7.6.120.0.

Note

When client moves to a non anchored SSID from an anchored sSSID on foreign, there is a stale entry on foreign .This happens when multicast mobile announce does not reach from foreign to guest anchor due to whatsoever reason, due to this the service is not impacted and configuration goes unnoticed but silently leaks MSCB on GA .There is no debug or error message shown nor does the GA runs a timer per client to cleanup. A HandoffEnd needs to be sent from foreign to Anchor since there is no timer.

Messaging Among Mobility Groups

The controller provides intersubnet mobility for clients by sending mobility messages to other member controllers.

302

Cisco Wireless Controller Configuration Guide, Release 8.3

Information About Mobility Groups

• The controller sends a Mobile Announce message to members in the mobility list each time that a new client associates to it. The controller sends the message only to those members that are in the same group as the controller (the local group) and then includes all of the other members while sending retries.

• You can configure the controller to use multicast to send the Mobile Announce messages. This behavior allows the controller to send only one copy of the message to the network, which destines it to the multicast group that contains all the mobility members. To derive the maximum benefit from multicast messaging, we recommend that it be enabled on all group members.

Using Mobility Groups with NAT Devices

Mobility message payloads carry IP address information about the source controller. This IP address is validated with the source IP address of the IP header. This behavior is a problem when a NAT device is introduced in the network because it changes the source IP address in the IP header. In the guest WLAN feature, any mobility packet, that is being routed through a NAT device is dropped because of the IP address mismatch.

The mobility group lookup uses the MAC address of the source controller. Because the source IP address is changed due to the mapping in the NAT device, the mobility group database is searched before a reply is sent to get the IP address of the requesting controller. This process is done using the MAC address of the requesting controller.

When configuring the mobility group in a network where NAT is enabled, enter the IP address that is sent to the controller from the NAT device rather than the controller’s management interface IP address. Also, make sure that the following ports are open on the firewall if you are using a firewall such as PIX:

• UDP 16666 for tunnel control traffic

• IP protocol 97 for user data traffic

• UDP 161 and 162 for SNMP

Note

Client mobility among controllers works only if auto-anchor mobility (also called guest tunneling) is enabled. See the Configuring Auto-Anchor Mobility and Mobility Tunneling sections for details on these mobility options.

Rogue Detection Behavior in Mobility Groups

The Rogue Detection Behavior in Mobility Groups in RRM perspective is:

• The AP's recognize another as a valid RF neighbor if the RF domain name is the same.

• The AP sends the information to WLC.

• The WLC uses the AP's information to establish a connection with other valid WLC's and each WLC would do a series of checks during this time (for country matches, version, hierarchy, scale limits, and others) before forming an auto mode RF group(RRM) either as a leader or a member.

• All AP's which are not part of this RF group is considered to be a foreign AP (equivalent to a rogue AP).

• Rogue found on wire via Rogue Detector AP will be contained using APs that are seeing the Rouge through wirelessly.

Cisco Wireless Controller Configuration Guide, Release 8.3

303

Prerequisites for Configuring Mobility Groups

The scenario where there are different RF group names if the APs can hear each other is:

• RF group names are usually consistent across a single deployment.

• APs which have unrecognizable neighbor packets or wrong entries are deemed rogues.

• If there are Cisco APs with two different RF groups. They would hear each other but will not populate the other in the RF neighbor list. (This RF list is sent to WLC for further munching as discussed above)

• Usually when two local neighborhoods have widely varying RF characteristics, then the network admin may adopt two RF group names to separate the two RF neighborhood or they may belong two different networks.

• AP neighborhood determines RF grouping(auto-mode) /Rogue classification and other and not vice-versa.

Prerequisites for Configuring Mobility Groups

Before you add controllers to a mobility group, you must verify that the following requirements have been met for all controllers that are to be included in the group:

• IP connectivity must exist between the management interfaces of all controllers.

Note

You can verify IP connectivity by pinging the controllers.

Note

Mobility control packets can use any interface address as the source, based on routing table. It is recommended that all controllers in the mobility group should have the management interface in the same subnet. A topology where one controller's management interface and other controller's dynamic interface are on same subnet not recommended for seamless mobility.

• When controllers in the mobility list use different software versions, Layer 2 or Layer 3 clients have limited roaming support. Layer 2 or Layer 3 client roaming is supported only between controllers that use the same version or with controllers that run versions 7.X.X.

Note

If you inadvertently configure a controller with a failover controller that runs a different software release, the access point might take a long time to join the failover controller because the access point starts the discovery process in CAPWAP and then changes to

LWAPP discovery.

• All controllers must be configured with the same virtual interface IP address.

Note

If necessary, you can change the virtual interface IP address by editing the virtual interface name on the Controller > Interfaces page.

304

Cisco Wireless Controller Configuration Guide, Release 8.3

Prerequisites for Configuring Mobility Groups

Note

If all the controllers within a mobility group are not using the same virtual interface, inter-controller roaming may appear to work, but the handoff does not complete, and the client loses connectivity for a period of time.

• You must have gathered the MAC address and IP address of every controller that is to be included in the mobility group. This information is necessary because you will be configuring all controllers with the MAC address and IP address of all the other mobility group members.

Note

You can find the MAC and IP addresses of the other controllers to be included in the mobility group on the Controller > Mobility Groups page of each controller’s GUI.

• When you configure mobility groups using a third-party firewall, for example, Cisco PIX, or Cisco ASA, you must open port 16666, and IP protocol 97.

• For intercontroller CAPWAP data and control traffic, you must open the ports 5247 and 5246.

This table lists the protocols and port numbers that must be used for management and operational purposes:

Table 13: Protocol/Service and Port Number

Protocol/Service

SSH/Telnet

TFTP

NTP/SNTP

SNMP

HTTPS/HTTP

Syslog

Radius Auth/Account

Port Number

TCP Port 22 or 29

UDP Port 69

UDP Port 123

UDP Port 161 for gets and sets and UDP port 162 for traps.

TCP port 443 for HTTPS and port 80 for HTTP

TCP port 514

UDP port 1812 and 1813

Note

To view information on mobility support across controllers with different software versions, see the http://www.cisco.com/c/en/us/td/docs/wireless/compatibility/matrix/compatibility-matrix.html

. .

Note

You cannot perform port address translation (PAT) on the firewall. You must configure one-to-one network address translation (NAT).

Cisco Wireless Controller Configuration Guide, Release 8.3

305

Configuring Mobility Groups (GUI)

Configuring Mobility Groups (GUI)

Step 1

Step 2

Step 3

Step 4

Choose Controller > Mobility Management > Mobility Groups to open the Static Mobility Group Members page.

This page shows the mobility group name in the Default Mobility Group text box and lists the MAC address and IPv4/IPv6 address of each controller that is currently a member of the mobility group. The first entry is the local controller, which cannot be deleted.

Note

If you want to delete any of the remote controllers from the mobility group, hover your cursor over the blue drop-down arrow for the desired controller and choose Remove.

Perform one of the following to add controllers to a mobility group:

• If you are adding only one controller or want to individually add multiple controllers, click New.

• If you are adding multiple controllers and want to add them in bulk, click EditAll.

Note

The EditAll option enables you to enter the MAC and IPv4/IPv6 addresses of all the current mobility group members and then copy and paste all the entries from one controller to the other controllers in the mobility group.

Click New to open the Mobility Group Member > New page.

Add a controller to the mobility group as follows:

In the Member IP Address text box, enter the management interface IPv4/IPv6 address of the controller to be added.

Note

If you are configuring the mobility group in a network where network address translation (NAT) is enabled, enter the IPv4/IPv6 address that is sent to the controller from the NAT device rather than the controller’s management interface IPv4/IPv6 address. Otherwise, mobility will fail among controllers in the mobility group.

In the Member MAC Address text box, enter the MAC address of the controller to be added.

In the Group Name text box, enter the name of the mobility group.

Note

The mobility group name is case sensitive.

In the Hash text box, enter the hash key of the peer mobility controller, which should be a virtual controller in the same domain.

You must configure the hash only if the peer mobility controller is a virtual controller in the same domain.

Note

Hash is not supported for IPv6 members.

Click Apply to commit your changes. The new controller is added to the list of mobility group members on the Static

Mobility Group Members page.

Click Save Configuration.

Repeat

Step a

through

Step e

to add all of the controllers in the mobility group.

Repeat this procedure on every controller to be included in the mobility group. All controllers in the mobility group must be configured with the MAC address and IPv4/IPv6 address of all other mobility group members.

The Mobility Group Members > EditAll page lists the MAC address, IPv4/IPv6 address, and mobility group name

(optional) of all the controllers currently in the mobility group. The controllers are listed one per line with the local controller at the top of the list.

306

Cisco Wireless Controller Configuration Guide, Release 8.3

Configuring Mobility Groups (CLI)

Step 5

Step 6

Step 7

Step 8

Step 9

Step 10

Step 11

Step 12

Note

If desired, you can edit or delete any of the controllers in the list.

Add more controllers to the mobility group as follows:

Click inside the edit box to start a new line.

Enter the MAC address, the management interface IPv4/IPv6 address, and the name of the mobility group for the controller to be added.

Note

You should enter these values on one line and separate each value with one or two spaces.

Note

The mobility group name is case sensitive.

Repeat

Step a

and

Step b

for each additional controller that you want to add to the mobility group.

Highlight and copy the complete list of entries in the edit box.

Click Apply to commit your changes. The new controllers are added to the list of mobility group members on the

Static Mobility Group Members page.

Click Save Configurationto save your changes.

Paste the list into the text box on the Mobility Group Members > Edit All page of all the other controllers in the mobility group and click Apply and Save Configuration.

Choose Mobility Management > Multicast Messaging to open the Mobility Multicast Messaging page.

The names of all the currently configured mobility groups appear in the middle of the page.

On the Mobility Multicast Messaging page, check the Enable Multicast Messaging check box to enable the controller to use multicast mode to send Mobile Announce messages to the mobility members. If you leave it unselected, the controller uses unicast mode to send the Mobile Announce messages. The default value is unselected.

If you enabled multicast messaging in the previous step, enter the multicast group IPv4 address for the local mobility group in the Local Group Multicast IPv4 Address text box. This address is used for multicast mobility messaging.

Note

In order to use multicast messaging, you must configure the IPv4 address for the local mobility group.

Note

In release 8.0, IPv6 is not supported for mobility multicast.

Click Apply to commit your changes.

If desired, you can also configure the multicast group IPv4 address for non-local groups within the mobility list. To do so, click the name of a non-local mobility group to open the Mobility Multicast Messaging > Edit page, and enter the multicast group IPv4 address for the non-local mobility group in the Multicast IP Address text box.

Note

If you do not configure the multicast IPv4 address for non-local groups, the controller uses unicast mode to send mobility messages to those members.

Click Apply.

Click Save Configuration.

Configuring Mobility Groups (CLI)

Step 1

Check the current mobility settings by entering this command:

Cisco Wireless Controller Configuration Guide, Release 8.3

307

Configuring Mobility Groups (CLI)

Step 2

Step 3

Step 4

Step 5

Step 6

Step 7

Step 8

Step 9

Step 10

Step 11 show mobility summary

Create a mobility group by entering this command:

config mobility group domain domain_name

Note

Enter up to 31 case-sensitive ASCII characters for the group name. Spaces are not allowed in mobility group names.

Add a group member by entering this command:

config mobility group member add mac_address ip_address

Note

If you are configuring the mobility group in a network where network address translation (NAT) is enabled, enter the IP address that is sent to the controller from the NAT device rather than the controller’s management interface IP address. Otherwise, mobility will fail among controllers in the mobility group.

Enter the config mobility group member delete mac_address command if you want to delete a group member.

To configure the hash key of a peer mobility controller, which is a virtual controller in the same domain, enter this command:

config mobility group member hash peer-ip-address key

Enable or disable multicast mobility mode by entering this command:

config mobility multicast-mode {enable | disable} local_group_multicast_address where local_group_multicast_address is the multicast group IPv4 address for the local mobility group. This address is used for multicast mobility messaging.

Note

In order to use multicast messaging, you must configure the IPv4 address for the local mobility group.

Note

In release 8.0, IPv6 is not supported for mobility multicast.

If you enable multicast mobility mode, the controller uses multicast mode to send Mobile Announce messages to the local group. If you disable multicast mobility mode, the controller uses unicast mode to send the Mobile Announce messages to the local group. The default value is disabled.

(Optional) You can also configure the multicast group IPv4 address for non-local groups within the mobility list. To do so, enter this command:

config mobility group multicast-address group_name IP_address

If you do not configure the multicast IPv4 address for non-local groups, the controller uses unicast mode to send mobility messages to those members.

Verify the mobility configuration by entering this command:

show mobility summary

To see the hash key of mobility group members in the same domain, enter this command:

show mobility group member hash

Save your changes by entering this command:

save config

Repeat this procedure on every controller to be included in the mobility group. All controllers in the mobility group must be configured with the MAC address and IP address of all other mobility group members.

Enable or disable debugging of multicast usage for mobility messages by entering this command:

debug mobility multicast {enable | disable}

308

Cisco Wireless Controller Configuration Guide, Release 8.3

C H A P T E R

Configuring New Mobility

•

Information About New Mobility, page 309

•

Restrictions for New Mobility , page 309

•

Configuring New Mobility (GUI), page 310

•

Configuring New Mobility (CLI) , page 311

Information About New Mobility

New Mobility enables Cisco WLCs to be compatible with converged access controllers with Wireless Control

Module (WCM) such as the Cisco Catalyst 3850 Series Switches and the Cisco 5760 Series Wireless LAN

Controllers. New Mobility provides the ability to run Mobility Controller (MC) functionality on a Cisco WLC in the Converged Access mode with a Catalyst 3850 mobility agent (MA)

The Mobility Controller is a part of a hierarchical architecture that consists of a Mobility Agent and Mobility

Oracle.

A group of Cisco Catalyst 3850 Series Switches' Mobility Agents can form a switch peer group. The internal

Mobility Agent of Cisco WLCs form an independent switch peer group. The Mobility Controller, Mobility

Agent, and Mobility Oracle can be in a single Cisco WLC. Each Mobility Controller forms a subdomain that can have multiple switch peer groups. The Cisco WLCs are Mobility Agents by default. However, Cisco

Catalyst 3850 Series Switch can function both as Mobility Agent and Mobility Controller, or only as a Mobility

Agent.

By default, New Mobility is disabled. When you enable or disable new mobility, you must save the configuration and reboot the controller.

Note

With Release 8.1 in a New Mobility environment, Cisco WLCs running Cisco Wireless software cannot function as mobility controllers (MC). However, the Cisco WLCs can function as guest anchors.

Restrictions for New Mobility

• The keepalives between Mobility Controller and Mobility Oracle are not DTLS encrypted.

Cisco Wireless Controller Configuration Guide, Release 8.3

309

Configuring New Mobility (GUI)

• For seamless mobility, the controller should either use new mobility or old mobility (flat mobility).

• Interoperability between two types of mobility is not supported. When you downgrade the controller from Release 7.5 to a controller software release that does not support new mobility, such as Releases

7.4.100.0, 7.3.101.0, 7.2, 7.0, or earlier (all releases prior to 7.3.112.0), the controller automatically transits to flat mobility (old mobility). This is due to the difference in mobility architecture and noninteroperability between flat mobility (EOIP tunnels) and new mobility(CAPWAP tunnels).

• High availability for Mobility Oracle is not supported.

• When a client associates for the very first time as local, then in the Cisco WLC, the MA sends a 'handoff complete' message to the MC to update the client database in the MC. However, the 'handoff complete' message is sent in a 'DHCP REQD' state because of which the IP address of the client is 0.0.0.0 for the very first time. This event is triggered by timer expiry.

• IPv6 is not supported with new mobility.

Configuring New Mobility (GUI)

Step 1

Step 2

Step 3

Step 4

Step 5

Step 6

Step 7

Step 8

Step 9

Step 10

Choose Controller > Mobility Management > Mobility Configuration to enable and configure new mobility on the controller.

Note

When you enable or disable new mobility, you must save the configuration and reboot the controller.

To configure new mobility, select or unselect the Enable New Mobility (Converged Access) check box.

Note

When you enable new mobility, you must save the configuration and reboot the controller.

To configure the controller as Mobility Oracle, select or unselect the Mobility Oracle check box.

Note

Mobility Oracle is optional; it maintains the client database under one complete mobility domain.

To configure multicast mode in a mobility group, select or unselect the Multicast Mode check box.

In the Multicast IP Address text box, enter the multicast IP address of the switch peer group.

In the Mobility Oracle IP Address text box, enter the IP address of the Mobility Oracle.

You cannot enter a value for this field if you have checked the Mobility Oracle check box.

In the Mobility Controller Public IP Address text box, enter the IP address of the controller, if there is no network address translation (NAT).

Note

If the controller has NAT configured, the public IP address will be the network address translated IP address.

Note

New mobility does not support

IPv6.

In the Mobility Keep Alive Count text box, enter the number of times a ping request is sent to a peer controller before the peer is considered to be unreachable. The range is from 3 to 20. The default value is 3.

In the Mobility Keep Alive Interval text box, enter the amount of time, in seconds, between each ping request sent to an peer controller. The range is from 1 to 30 seconds. The default value is 10 seconds.

In the Mobility DSCP text box, enter the DSCP value that you can set for the mobility controller. The range is from 0 to 63. The default value is 0.

Note

310

Cisco Wireless Controller Configuration Guide, Release 8.3

Configuring New Mobility (CLI)

Step 13

Step 14

Step 15

Step 16

Step 17

Step 18

Step 19

Step 11

Step 12

Click Apply.

Choose Controller > Mobility Management > Switch Peer Group to add or remove members to and from the switch peer group.

This page lists all the switch peer groups and their details, such as bridge domain ID, multicast IP address, and status of the multicast mode. Click the name of the switch peer group to navigate to the Edit page and update the parameters, if required.

Choose Controller > Mobility Management > Mobility Controller to view all the mobility controllers and their details, such as IP address, MAC address, client count, and link status.

Choose Controller > Mobility Management > Mobility Clients to view all the mobility clients and their parameters.

In the Client MAC Address and Client IP Address text boxes, enter the MAC address and IP address of the mobility client, respectively.

In the Anchor MC IP Address and Anchor MC Public IP Address text boxes, enter the IP address and public IP address of the anchor Mobility Controller, respectively.

In the Foreign MC IP Address and Foreign MC Public IP Address text boxes, enter the IP address and public IP address of the foreign MC, respectively.

In the Client Association Time text box, enter the time at which the mobility client should be associated with the Mobility

Controller.

In the Client Entry Update Timestamp text box, enter the timestamp at which the client entry should be updated.

Configuring New Mobility (CLI)

• Enable or disable new mobility on the controller by entering this command:

config mobility new-architecture {enable | disable}

Note

When you enable or disable new mobility, you must save the configuration and reboot the controller.

• Enable the Mobility Oracle or configure an external Mobility Oracle by entering this command:

config mobility oracle{enable| disable | ip ip_address}

Here, ip_address is the IP address of the Mobility Oracle. The Mobility Oracle maintains the client database under one complete mobility domain. It consists of a station database, an interface to the

Mobility Controller, and an NTP/SNTP server. There can be only one Mobility Oracle in the entire mobility domain.

• Configure the MAC address of the member switch for compatibility between the flat (old) and new mobility by entering this command:

config mobility group member add ip_address{[group-name] | mac-address | [public-ip-address]} where ip_address is the IP address of the member.

group-name is the member switch group name, if it is different from the default group name.

mac-address is the MAC address of the member switch.

Cisco Wireless Controller Configuration Guide, Release 8.3

311

Configuring New Mobility (CLI)

Note

If the controller has NAT configured, the public IP address will be the network address translated IP address.

Note

New mobility does not support IPv6.

• View the details of the mobility controllers according to the Mobility Oracle by entering this command:

show mobility oracle summary

• View the summary and details of the Mobility Oracle client database by entering this command:

show mobility oracle client {summary | detail}

• Verify the mobility statistics by entering this command:

show mobility statistics

• Verify the mobility configuration by entering this command:

show mobility summary

• Save your changes by entering this command:

save config

• Enable or disable debugging of mobility packets by entering this command:

debug mobility packet {enable | disable}

• Enable or disable debugging of the Mobility Oracle events and errors by entering this command:

debug mobility oracle {events | errors} {enable| disable}

312

Cisco Wireless Controller Configuration Guide, Release 8.3

C H A P T E R

Monitoring and Validating Mobility

•

Running Mobility Ping Tests, page 313

•

Information About WLAN Mobility Security Values, page 314

Running Mobility Ping Tests

Information About Mobility Ping Tests

Controllers in a mobility list communicate with each other by controlling information over a well-known

UDP port and exchanging data traffic through an Ethernet-over-IP (EoIP) tunnel. Because UDP and EoIP are not reliable transport mechanisms, there is no guarantee that a mobility control packet or data packet will be delivered to a mobility peer. Mobility packets may be lost in transit due to a firewall filtering the UDP port or EoIP packets or due to routing issues.

Restrictions on Mobility Ping Tests

• You can test the mobility communication environment by performing mobility ping tests. These tests may be used to validate connectivity between members of a mobility group (including guest controllers).

Two ping tests are available:

◦Mobility ping over UDP—This test runs over mobility UDP port 16666. It tests whether the mobility control packet can be reached over the management interface.

◦Mobility ping over EoIP—This test runs over EoIP. It tests the mobility data traffic over the management interface.

• Only one mobility ping test per controller can be run at a given time.

• These ping tests are not Internet Control Message Protocol (ICMP) based. The term “ping” is used to indicate an echo request and an echo reply message.

Cisco Wireless Controller Configuration Guide, Release 8.3

313

Information About WLAN Mobility Security Values

Note

Any ICMP packet greater than 1280 bytes will always be responded with a packet that is truncated to 1280 bytes. For example, a ping with a packet that is greater than 1280 bytes from a host to the management interface is always responded with a packet that is truncated to 1280 bytes.

• Mobility pings on ports 16666 and 16667 are notable exemptions and these ports cannot be blocked by any ACL.

Running Mobility Ping Tests (CLI)

• To test the mobility UDP control packet communication between two controllers, enter this command:

mping mobility_peer_IP_address

The mobility_peer_IP_address parameter must be the IP address of a controller that belongs to the mobility list.

• To test the mobility EoIP data packet communication between two controllers, enter this command:

eping mobility_peer_IP_address

The mobility_peer_IP_address parameter must be the IP address of a controller that belongs to the mobility list.

• To troubleshoot your controller for mobility ping, enter these commands: config logging buffered debugging

show logging

To troubleshoot your controller for mobility ping over UDP, enter this command to display the mobility control packet:

debug mobility handoff enable

Note

We recommend using an ethereal trace capture when troubleshooting.

Information About WLAN Mobility Security Values

For any anchoring or mobility event, the WLAN security policy values on each controller must match. These values can be validated in the controller debugs. This table lists the WLAN mobility security values and their corresponding security policy.

Table 14: WLAN Mobility Security Values

Security Hexadecimal Value

0x00000000

Security Policy

Security_None

314

Cisco Wireless Controller Configuration Guide, Release 8.3

Security Hexadecimal Value

0x00000001

0x00000002

0x00000004

0x00000008

0x00000010

0x00000020

0x00000040

0x00000080

0x00000100

0x00000200

0x00000400

0x00000800

0x00001000

Information About WLAN Mobility Security Values

Security Policy

Security_WEP

Security_802_1X

Security_IPSec*

Security_IPSec_Passthrough*

Security_Web

Security_PPTP*

Security_DHCP_Required

Security_WPA_NotUsed

Security_Cranite_Passthrough*

Security_Fortress_Passthrough*

Security_L2TP_IPSec*

Security_802_11i_NotUsed

Note

Controllers running software release 6.0 or later do not support this security policy.

Security_Web_Passthrough

Cisco Wireless Controller Configuration Guide, Release 8.3

315

Information About WLAN Mobility Security Values

316

Cisco Wireless Controller Configuration Guide, Release 8.3

P A R T

Wireless

•

Country Codes, page 319

•

Radio Bands, page 323

•

Radio Resource Management, page 335

•

Wireless Quality of Service, page 377

•

Location Services, page 445

•

Wireless Intrusion Detection System, page 473

•

Advanced Wireless Tuning, page 531

C H A P T E R

Country Codes

•

Information About Configuring Country Codes, page 319

•

Restrictions on Configuring Country Codes, page 320

•

Configuring Country Codes (GUI), page 320

•

Configuring Country Codes (CLI), page 321

Information About Configuring Country Codes

Controllers and access points are designed for use in many countries with varying regulatory requirements.

The radios within the access points are assigned to a specific regulatory domain at the factory (such as -E for

Europe), but the country code enables you to specify a particular country of operation (such as FR for France or ES for Spain). Configuring a country code ensures that each radio’s broadcast frequency bands, interfaces, channels, and transmit power levels are compliant with country-specific regulations.

The following are some guidelines for configuring country codes:

• Generally, you configure one country code per controller, the one matching the physical location of the controller and its access points. However, you can configure more than one country code per Cisco

WLC. Prior to Release 8.2, you could configure up to 20 country codes per Cisco WLC; from Release

8.2 onwards, you can configure up to 110 country codes per Cisco WLC. This multiple-country support enables you to manage access points in various countries from a single Cisco WLC.

• Although the controller supports different access points in different regulatory domains (countries), it requires all radios in a single access point to be configured for the same regulatory domain. For example, you should not configure a Cisco 1231 access point’s 802.11b/g radio for the US (-A) regulatory domain and its 802.11a radio for the Great Britain (-E) regulatory domain. Otherwise, the controller allows only one of the access point’s radios to turn on, depending on which regulatory domain you selected for the access point on the controller. Therefore, make sure that the same country code is configured for both of the access point’s radios.

For a complete list of country codes supported per product, see http://tools.cisco.com/cse/prdapp/jsp/ externalsearch.do?action=externalsearch&page=EXTERNAL_SEARCH or http://www.cisco.com/c/en/us/products/collateral/wireless/access-points/product_data_sheet0900aecd80537b6a.html

Cisco Wireless Controller Configuration Guide, Release 8.3

319

Restrictions on Configuring Country Codes

• When the multiple-country feature is being used, all controllers that are going to join the same RF group must be configured with the same set of countries, configured in the same order.

• When multiple countries are configured and the RRM auto-RF feature is enabled, the RRM assigns the channels that are derived by performing a union of the allowed channels per the AP country code. The

APs are assigned channels by the RRM based on their PID country code. APs are only allowed to use legal frequencies that match their PID country code. Ensure that your AP's country code is legal in the country that it is deployed.

• The country list configured on the RF group leader determines what channels the members would operate on. This list is independent of what countries have been configured on the RF group members.

Information About Japanese Country Codes

Country codes define the channels that can be used legally in each country. These country codes are available for Japan:

• JP—Allows only -J radios to join the controller

• J2—Allows only -P radios to join the controller

• J3—Uses the -U frequencies but allows -U, -P and -Q (other than 1550/1600/2600/3600) radios to join the WLC

• J4—Allows 2.4G JPQU and 5G PQU to join the controller.

Note

The 1550, 1600, 2600, and 3600 APs require J4.

See the Channels and Maximum Power Settings for Cisco Aironet Lightweight Access Points document for the list of channels and power levels supported by access points in the Japanese regulatory domains.

Restrictions on Configuring Country Codes

• The access point can only operate on the channels for the countries that they are designed for.

Note

If an access point was already set to a higher legal power level or is configured manually, the power level is limited only by the particular country to which that access point is assigned.

Configuring Country Codes (GUI)

Step 1

Disable the 802.11 networks as follows: a) Choose Wireless > 802.11a/n/ac > Network.

320

Cisco Wireless Controller Configuration Guide, Release 8.3

Configuring Country Codes (CLI)

Step 2

Step 3

Step 4

Step 5

Step 6

Step 7

Step 8

b) Unselect the 802.11a Network Status check box.

c) Click Apply.

d) Choose Wireless > 802.11a/n/ac > Network.

e) Unselect the 802.11b/g Network Status check box.

f) Click Apply.

Choose Wireless > Country to open the Country page.

Select the check box for each country where your access points are installed. If you selected more than one check box, a message appears indicating that RRM channels and power levels are limited to common channels and power levels.

Click OK to continue or Cancel to cancel the operation.

Click Apply.

If you selected multiple country codes in Step 3, each access point is assigned to a country.

See the default country chosen for each access point and choose a different country if necessary as follows:

Note

If you remove a country code from the configuration, any access points currently assigned to the deleted country reboot and when they rejoin the controller, they get re-assigned to one of the remaining countries if possible.

a) Perform one of the following:

• Leave the 802.11 networks disabled.

• Reenable the 802.11 networks and then disable only the access points for which you are configuring a country code. To disable an access point, choose Wireless > Access Points > All APs, click the link of the desired access point, choose Disable from the Status drop-down list, and click Apply.

b) Choose Wireless > Access Points > All APs to open the All APs page.

c) Click the link for the desired access point.

d) Choose the Advanced tab to open the All APs > Details for (Advanced) page.

The default country for this access point appears in the Country Code drop-down list.

e) If the access point is installed in a country other than the one shown, choose the correct country from the drop-down list. The box contains only those country codes that are compatible with the regulatory domain of at least one of the access point’s radios.

f) Click Apply.

g) Repeat these steps to assign all access points joined to the controller to a specific country.

h) Reenable any access points that you disabled in Step a.

Reenable the 802.11 networks if you did not enable them in Step 6.

Click Save Configuration.

Configuring Country Codes (CLI)

Step 1

Step 2

See a list of all available country codes by entering this command:

show country supported

Disable the 802.11 networks by entering these commands:

config 802.11a disable network

Cisco Wireless Controller Configuration Guide, Release 8.3

321

Configuring Country Codes (CLI)

Step 3

Step 4

Step 5

Step 6

Step 7

Step 8

Step 9

Step 10

Step 11 config 802.11b disable network

Configure the country codes for the countries where your access points are installed by entering this command:

config country code1[,code2,code3,...]

If you are entering more than one country code, separate each by a comma (for example, config country US,CA,MX).

Enter Y when prompted to confirm your decision.

Verify your country code configuration by entering this command:

show country

See the list of available channels for the country codes configured on your controller by entering this command:

show country channels

Save your changes by entering this command:

save config

See the countries to which your access points have been assigned by entering this command:

To see a summary of specific access point you can specify the access point name. You can also use wildcard searches when filtering for access points.

show ap summary

If you entered multiple country codes in Step 3, follow these steps to assign each access point to a specific country: a) Perform one of the following:

• Leave the 802.11 networks disabled.

• Reenable the 802.11 networks and then disable only the access points for which you are configuring a country code. To Reenable the networks, enter this command:

config 802.11{a | b} enable network

To disable an access point, enter this command:

config ap disable ap_name b) To assign an access point to a specific country, enter this command:

config ap country code {ap_name | all}

Make sure that the country code you choose is compatible with the regulatory domain of at least one of the access point’s radios.

Note

If you enabled the networks and disabled some access points and then run the config ap country code all command, the specified country code is configured on only the disabled access points. All other access points are ignored.

c) To reenable any access points that you disabled in Step a, enter this command:

config ap enable ap_name

If you did not reenable the 802.11 networks in Step 9, enter these commands to reenable them now:

config 802.11{a | b} enable network

Save your changes by entering this command:

save config

322

Cisco Wireless Controller Configuration Guide, Release 8.3

C H A P T E R

Radio Bands

•

Modulations and Data Rates, page 323

Modulations and Data Rates

802.11 Bands

Information About Configuring 802.11 Bands

You can configure the 802.11b/g/n (2.4-GHz) and 802.11a/n/ac (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/ac 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.

Configuring the 802.11 Bands (GUI)

Step 1

Step 2

Step 3

Step 4

Choose Wireless > 802.11a/n/ac or 802.11b/g/n > Network to open the Global Parameters page.

Select the 802.11a (or 802.11b/g) Network Status check box to enable the 802.11a or 802.11b/g band. To disable the band, unselect the check box. The default value is enabled. You can enable both the 802.11a and 802.11b/g bands.

If you enabled the 802.11b/g band in Step 2, select the 802.11g Support check box if you want to enable 802.11g network support. The default value is enabled. If you disable this feature, the 802.11b band is enabled without 802.11g support.

Specify the period at which the SSID is broadcast by the access point by entering a value between 20 and 1000 milliseconds

(inclusive) in the Beacon Period text box. The default value is 100 milliseconds.

Note

The beacon period in controllers is listed in terms of milliseconds. The beacon period can also be measured in time units, where one time unit equals 1024 microseconds or 102.4 milliseconds. If a beacon interval is listed as 100 milliseconds in a controller, it is only a rounded off value for 102.4 milliseconds. Due to hardware limitation in certain radios, even though the beacon interval is, say 100 time units, it is adjusted to 102 time units, which roughly equals 104.448 milliseconds. When the beacon period is to be represented in terms of time units, the value is adjusted to the nearest multiple of 17.

Cisco Wireless Controller Configuration Guide, Release 8.3

323

Modulations and Data Rates

Step 5

Step 6

Step 7

Step 8

Step 9

Step 10

Step 11

Step 12

Specify the size at which packets are fragmented by entering a value between 256 and 2346 bytes (inclusive) in the

Fragmentation Threshold text box. Enter a low number for areas where communication is poor or where there is a great deal of radio interference.

Make access points advertise their channel and transmit power level in beacons and probe responses for CCX clients.

Select the DTPC Support check box. Otherwise, unselect this check box. The default value is enabled.

Client devices using dynamic transmit power control (DTPC) receive the channel and power level information from the access points and adjust their settings automatically. For example, a client device used primarily in Japan could rely on

DTPC to adjust its channel and power settings automatically when it travels to Italy and joins a network there.

Note

On access points that run Cisco IOS software, this feature is called world

mode.

DTPC and 801.11h power constraint cannot be enabled simultaneously.

Specify the maximum allowed clients by entering a value between 1 to 200 in the Maximum Allowed Client text box.

The default value is 200.

Select or unselect the RSSI Low Check check box to enable or disable the RSSI Low Check feature.

Service providers can use the RSSI Low Check feature to prevent clients from connecting to their Wi-Fi network unless the client has a viable connection. In many scenarios, even though clients can hear beacons and connect to Wi-Fi, the signal might not be strong enough to support a stable connection. Use this feature to determine how strong a client must be heard for it to associate with the Wi-Fi network.

If you enable the RSSI Low Check feature, when a client sends an association request to the AP, the controller gets the

RSSI value from the association message and compares it with the RSSI threshold that is configured. If the RSSI value from the association message is less than the RSSI threshold value, the controller rejects the association request. Note that this is only for association frames, and not for other messages.

The default RSSI Low Check value is –80 dBm, which means an association request from a client can be rejected if the

AP hears a client with a signal that is weaker than –80 dBm. If you lower the value to –90 dBm, clients are allowed to connect at a further distance, but there is also a higher probability of the connection quality being poor. We recommend that you do not go higher than –80 dBm, for example –70 dBm, because this makes the cell size significantly smaller.

Enter the RSSI Threshold value.

The default value is –80 dBm.

Use the Data Rates options to specify the rates at which data can be transmitted between the access point and the client.

These data rates are available:

• 802.11a—6, 9, 12, 18, 24, 36, 48, and 54 Mbps

• 802.11b/g—1, 2, 5.5, 6, 9, 11, 12, 18, 24, 36, 48, or 54 Mbps

For each data rate, choose one of these options:

• Mandatory—Clients must support this data rate in order to associate to an access point on the controller.

• Supported—Any associated clients that support this data rate may communicate with the access point using that rate. However, the clients are not required to be able to use this rate in order to associate.

• Disabled—The clients specify the data rates used for communication.

Click Apply.

Click Save Configuration.

324

Cisco Wireless Controller Configuration Guide, Release 8.3

Modulations and Data Rates

Configuring the 802.11 Bands (CLI)

Step 1

Step 2

Step 3

Step 4

Step 5

Step 6

Step 7

Step 8

Step 9

Disable the 802.11a band by entering this command:

config 802.11a disable network

Note

The 802.11a band must be disabled before you can configure the 802.11a network parameters in this section.

Disable the 802.11b/g band by entering this command:

config 802.11b disable network

Note

The 802.11b band must be disabled before you can configure the 802.11b network parameters in this section.

Specify the rate at which the SSID is broadcast by the access point by entering this command:

config {802.11a | 802.11b} beaconperiod time_unit where time_unit is the beacon interval in time units (TUs). One TU is 1024 microseconds. You can configure the access point to send a beacon every 20 to 1000 milliseconds.

Specify the size at which packets are fragmented by entering this command:

config {802.11a | 802.11b} fragmentation threshold where threshold is a value between 256 and 2346 bytes (inclusive). Specify a low number for areas where communication is poor or where there is a great deal of radio interference.

Make access points advertise their channel and transmit power level in beacons and probe responses by entering this command:

config {802.11a | 802.11b } dtpc {enable | disable}

The default value is enabled. Client devices using dynamic transmit power control (DTPC) receive the channel and power level information from the access points and adjust their settings automatically. For example, a client device used primarily in Japan could rely on DTPC to adjust its channel and power settings automatically when it travels to Italy and joins a network there.

Note

On access points that run Cisco IOS software, this feature is called world

mode.

Specify the maximum allowed clients that can be configured by entering this command:

config {802.11a | 802.11b} max-clients max_allow_clients

The valid range is between 1 to 200.

Configure the RSSI Low Check feature by entering this command:

config 802.11{a | b} rssi-check {enable | disable}

Configure the RSSI Threshold value by entering this command:

config 802.11{a | b} rssi-threshold value-in-dBm

Note

The default value is –80 dBm.

Specify the rates at which data can be transmitted between the controller and the client by entering this command:

config {802.11a | 802.11b} rate {disabled | mandatory | supported} rate where

• disabled—Clients specify the data rates used for communication.

• mandatory—Clients support this data rate in order to associate to an access point on the controller.

Cisco Wireless Controller Configuration Guide, Release 8.3

325

Modulations and Data Rates

• supported—Any associated clients that support this data rate may communicate with the access point using that rate. However, the clients are not required to be able to use this rate in order to associate.

• rate—The rate at which data is transmitted:

◦6, 9, 12, 18, 24, 36, 48, and 54 Mbps (802.11a)

◦1, 2, 5.5, 6, 9, 11, 12, 18, 24, 36, 48, or 54 Mbps (802.11b/g)

Step 10

Step 11

Step 12

Step 13

Step 14

Enable the 802.11a band by entering this command:

config 802.11a enable network

The default value is enabled.

Enable the 802.11b band by entering this command:

config 802.11b enable network

The default value is enabled.

Enable or disable 802.11g network support by entering this command:

config 802.11b 11gSupport {enable | disable}

The default value is enabled. You can use this command only if the 802.11b band is enabled. If you disable this feature, the 802.11b band is enabled without 802.11g support.

Enter the save config command to save your changes.

View the configuration settings for the 802.11a or 802.11b/g band by entering this command:

show {802.11a | 802.11b}

Information similar to the following appears:

802.11a Network............................... 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.............................. Mandatory

802.11a 9M Rate.............................. Supported

802.11a 12M Rate............................. Mandatory

802.11a 18M Rate............................. Supported

802.11a 24M Rate............................. Mandatory

802.11a 36M Rate............................. Supported

802.11a 48M Rate............................. Supported

802.11a 54M Rate............................. Supported

...

Beacon Interval.................................. 100

...

Default Channel............................... 36

Default Tx Power Level........................ 1

DTPC Status................................... Enabled

Fragmentation Threshold....................... 2346

Maximum Number of Clients per AP................. 200

326

Cisco Wireless Controller Configuration Guide, Release 8.3

Modulations and Data Rates

802.11n Parameters

Information About Configuring the 802.11n Parameters

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.

Starting in release 7.4, the 802.11n-only access points can filter out clients without high-throughput information element on the association request. The 802.11n-only access points access points reject association requests from clients without high-throughput information element (11n).

In the 802.11n high-throughput mode, there are no 802.11a/b/g stations using the same channel. The 802.11a/b/g devices cannot communicate with the 802.11n high-throughput mode access point, where as the 802.11n-only mode access point uses 802.11a/g rates for beacons or management frames.

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.

Configuring the 802.11n Parameters (GUI)

Step 1

Step 2

Step 3

Choose Wireless > 802.11a/n/ac or 802.11b/g/n > High Throughput to open the (5 GHz or 2.4 GHz) High Throughput page.

Select the 11n Mode check box to enable 802.11n support on the network. The default value is enabled.

If you want to disable 802.11n mode when both 802.11n and 802.11ac modes are enabled, you must disable the 802.11ac

mode first.

Select the check boxes of the desired rates to specify the modulation and coding scheme (MCS) rates at which data can be transmitted between the access point and the client. These data rates, which are calculated for a 20-MHz channel width using a short guard interval, are available:

• 0 (7 Mbps)

• 1 (14 Mbps)

• 2 (21 Mbps)

• 3 (29 Mbps)

• 4 (43 Mbps)

• 5 (58 Mbps)

Cisco Wireless Controller Configuration Guide, Release 8.3

327

Modulations and Data Rates

Step 4

Step 5

Step 6

• 6 (65 Mbps)

• 7 (72 Mbps)

• 8 (14 Mbps)

• 9 (29 Mbps)

• 10 (43 Mbps)

• 11 (58 Mbps)

• 12 (87 Mbps)

• 13 (116 Mbps)

• 14 (130 Mbps)

• 15 (144 Mbps)

Any associated clients that support the selected rates may communicate with the access point using those rates.

However, the clients are not required to be able to use this rate in order to associate. The MCS settings determine the number of spatial streams, the modulation, the coding rate, and the data rate values that are used.

Click Apply.

Use the 802.11n data rates that you configured by enabling WMM on the WLAN as follows: a) Choose WLANs to open the WLANs page.

b) Click the ID number of the WLAN for which you want to configure WMM mode.

c) When the WLANs > Edit page appears, choose the QoS tab to open the WLANs > Edit (Qos) page.

d) From the WMM Policy drop-down list, choose Required or Allowed to require or allow client devices to use WMM.

Devices that do not support WMM cannot join the WLAN.

If you choose Allowed, devices that cannot support WMM can join the WLAN but will not benefit from the 802.11n

rates.

e) Click Apply.

Click Save Configuration.

Note

To determine if an access point supports 802.11n, look at the 11n Supported text box on either the 802.11a/n/ac

(or 802.11b/g/n) Cisco APs > Configure page or the 802.11a/n/ac (or 802.11b/g/n) AP Interfaces > Details page.

Configuring the 802.11n Parameters (CLI)

• 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.

328

Cisco Wireless Controller Configuration Guide, Release 8.3

Modulations and Data Rates

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: a) Disable the network by entering this command:

config {802.11a | 802.11b} disable network b) 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.

Note

For 802.11ac, all packets are A-MPDU. The A-MSDU option does not apply for 802.11ac.

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 15: Traffic Type Priority Levels

User Priority

Traffic Type

Best effort

Background

Spare

Excellent effort

Controlled load

Video, less than 100-ms latency and jitter

Voice, less than 10-ms latency and jitter

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.

c) Reenable the network by entering this command:

config {802.11a | 802.11b} enable network

Cisco Wireless Controller Configuration Guide, Release 8.3

329

Modulations and Data Rates

• 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.11ac

Information About Configuring the 802.11ac Parameters

The 802.11ac radio module for the Cisco Aironet 3600 Series access point and Cisco Aironet 3700 Series access point provides enterprise-class reliability and wired-network-like performance. It supports three spatial streams and 80 MHz-wide channels for a maximum data rate of 1.3 Gbps. This is three times the maximum data rate of today's high-end enterprise 802.11n access point.

The 802.11ac radio in slot 2 is a slave radio for which you can configure specific parameters. Because the

802.11ac is a slave radio, it inherits many properties from the main 802.11a/n radio on slot 1. The parameters that you can configure for the 802.11ac radio are as follows:

• Admin status—Interface status of the radio that you can enable or disable. By default, the Admin status is in an enabled state. If you disable 802.11n, the 802.11ac radio is also disabled.

• Channel width—You can choose the RF channel width as 20 MHz, 40 MHz, or 80 MHz. If you choose the channel width as 80 MHz, you must enable the 802.11ac mode on the High Throughput page.

Note

The 11ac Supported field is a nonconfigurable parameter that appears for the 802.11ac

slave radio in slot 2.

Note

When the Cisco Aironet 3600 Series access point with 802.11ac radio module is in unsupported mode such as Monitor and Sniffer, Admin Status and Channel Width will not be configured.

This section provides instructions to manage 802.11ac devices such as the Cisco Aironet 3600 Series Access

Points and Cisco Aironet 3700 Series Access Point on your network.

Note

AP3600 and AP3700 with the 802.11ac module can advertise only the first 8 WLANs on the 5-GHz radios.

330

Cisco Wireless Controller Configuration Guide, Release 8.3

Modulations and Data Rates

Changing the 802.11n radio channel also changes the 802.11ac channels.

Ensure that your WLAN has WMM enabled and open or WPA2/AES for 802.11ac to be supported. Otherwise, the speed of 802.11ac is not available, even on 802.11ac clients.

For more information about the 802.11ac module on the Cisco Aironet 3600 Series access point, see http:// www.cisco.com/c/en/us/products/wireless/aironet-3600-series/relevant-interfaces-and-modules.html

802.11ac Wave 2 and MU-MIMO

The 802.11ac Wave 2 introduces additional capabilities beyond what were added with Wave 1. It utilizes

MU-MIMO technology and other advancements to help increase wireless performance for applications such as HD video streaming. Wave 2 provides better RF efficiency that Wave 1 provides, in addition to a number of other features that further improve wireless connectivity.

MU-MIMO

MU-MIMO is short for Multi-User, Multiple-Input, Multiple-Output. MU-MIMO is an enhanced form of the

MIMO technology that enables multiple independent radio terminals to access a system.

With 802.11n or 802.11ac Wave 1, an access point can transmit multiple spatial streams at the same time, but only directed to a single wireless client. This means only a single device gets data at a time. This is referred to as single-user MIMO (SU-MIMO).

802.11ac Wave 2 allows for MU-MIMO, which enables multiple users to simultaneously receive data from the AP simultaneously using the same channel. With MU-MIMO a Wave 2 capable access point is able to use its antenna resources to transmit to multiple clients, all at the same time and over the same channel.

MU-MIMO is used in the downstream direction and requires the wireless clients to also be Wave 2 capable.

More Spatial Streams

802.11ac Wave 2 allows for up to eight spatial streams. However, initial Wave2 implementations will only increase the number of spatial streams from 3 to 4 as compared to Wave 1 implementations. The support of an additional spatial stream allows for additional increased performance as compared to 3 SS APs.

References

For more information on these technologies, see the following documents on Cisco.com:

• Cisco 802.11ac Wave 2 FAQs at http://www.cisco.com/c/en/us/solutions/collateral/enterprise-networks/

802-11ac-solution/q-and-a-c67-734152.html

• Fundamentals of 802.11ac Wave 2 post on the Cisco Interaction Network at http://blogs.cisco.com/cin/ fundamentals-of-802-11ac-wave-2

• 802.11ac: The Fifth Generation of Wi-Fi technical white paper at http://www.cisco.com/c/en/us/products/ collateral/wireless/aironet-3600-series/white_paper_c11-713103.html

Explicit Compressed Beamforming Feedback

The AP 1850 supports standards-based Explicit Compressed Beamforming Feedback (ECBF) as defined in the 802.11ac standards. With ECBF the client provides estimates of the wireless channel conditions to the access point. As these are based on explicit channel measurements from the client, both the AP and the client must support it. For 802.11ac, the access point’s ECBF is typically referred to as Transmit Beamforming or

TxBF for short.

While both TxBF and ClientLink 3.0 improve the performance of wireless client devices, ClientLink3.0

provides an additional advantage over TxBF. ClientLink3.0 technology does not depend on any client-side hardware or software capabilities and operates seamlessly in mixed-mode environments where 802.11ac and

802.11a/n clients coexist on the same access point. In comparison, TxBF requires client-side support to take

Cisco Wireless Controller Configuration Guide, Release 8.3

331

Modulations and Data Rates

advantage of the performance improvements of beamforming and therefore benefits only 802.11ac clients that support TxBF.

The Cisco 1850 AP supports TxBF but not beamforming to legacy client devices. Therefore, Cisco 1850 AP does not support ClientLink 3.0.

Note

ClientLink 3.0 is supported on the Cisco Aironet 2700 and 3700 Series 802.11ac APs.

Note

You can disable TxBF only on the Cisco Aironet 1140, 1260, 1550, and 3500 APs that support ClientLink

1.0. It cannot be disabled on the APs that supports ClientLink 2.0 and above.

Restrictions for 802.11ac Support

• The 802.11ac module is supported only on the Cisco Aironet 3600 Series Access Points.

• The 802.11ac module is turned off if the built-in 5-GHz radio is turned off.

• You must ensure that the configuration of the channel, power values, and the mode of the 802.11ac

module is the same as those of the built-in 5-GHz radio on the AP. Also, the 802.11ac module serves only 802.11ac clients.

• The 802.11ac module main channel cannot be changed individually.

• This 802.11ac support is applicable only to the following controller platforms:

◦Cisco 2504 WLC

◦Cisco 5508 WLC

◦Cisco 5520 WLC

◦Cisco Flex 7510 WLC

◦Cisco 8510 WLC

◦Cisco 8540 WLC

• Controllers do not support High availability for 802.11ac modules. The 802.11ac configuration (802.11ac

Data Rates and 802.11ac Global mode) on the controller is not synchronized with the standby controller.

This might result in client throughput fluctuations and reassociations when you explicitly disable those configurations on the active controller.

In addition, the 802.11ac Global mode configuration controls whether the radio module is enabled. If

802.11ac Global mode is enabled on one controller but not on another, the 802.11ac module might be disabled if the access point associates with a controller on which 802.11ac Global mode is disabled.

• When changing AP from static to auto channel assignment, by default AP moves to best possible bandwidth supported by the radio and a valid channel. Channel number and width assignment may be suboptimal until next DCA cycle gets started.

• SSIDs with TKIP and SSIDs with TKIP+AES are not enabled on the 802.11ac radios. Therefore, all the

5-GHz clients are expected to associate with the 802.11n radios.

332

Cisco Wireless Controller Configuration Guide, Release 8.3

Modulations and Data Rates

Configuring the 802.11ac High-Throughput Parameters (GUI)

Step 1

Step 2

Step 3

Step 4

Choose Wireless > 802.11a/n/ac > High Throughput (802.11n/ac).

Select the 11ac mode check box to enable the 802.11ac support on the network.

Note

You can modify the 802.11ac status only if the 802.11n mode is enabled.

Ensure that all of the 0 to 31 MCS data rate indices are enabled (which is the default setting).

Save the configuration.

Configuring MU-MIMO (GUI)

This feature is applicable only to Cisco Aironet 1850 Series APs.

Step 1

Step 2

Choose WLANs and click the WLAN ID.

In the Advanced tab, check or uncheck the 11ac MU-MIMO check box.

Configuring the 802.11ac High-Throughput Parameters (CLI)

• Enable or disable 802.11ac support by entering this command:

config 802.11a 11acSupport {enable | disable}

• Configure MCS transmit rates by entering this command:

config 802.11a 11acSupport mcs tx {rate-8 | rate-9} ss spatial-stream-value {enable | disable}

Note

Ensure that all of the 0 to 31 MCS data rate indices are enabled (which is the default setting). In 8.1 and later releases, RF profiles should include MCS 0-31 instead of MCS 0-23 in earlier releases.

Configuring MU-MIMO (CLI)

This feature is applicable only to Cisco Aironet 1850 Series APs.

Step 1

Step 2

Enable or disable MU-MIMO by entering this command:

config wlan mu-mimo {enable | disable} wlan-id

See the status of MU-MIMO by entering this command:

show interfaces Dot11Radio Dot11-radio-interface-number mumimo wlan-id

Cisco Wireless Controller Configuration Guide, Release 8.3

333

Modulations and Data Rates

334

Cisco Wireless Controller Configuration Guide, Release 8.3

C H A P T E R

Radio Resource Management

•

Radio Resource Management, page 335

•

RF Groups, page 342

•

Off-Channel Scanning and Neighbor Discovery, page 350

•

Channels, page 356

•

Transmit Power, page 365

•

RF Profiles, page 369

Radio Resource Management

Information About Radio Resource Management

The Radio Resource Management (RRM) software embedded in the Cisco Wireless LAN Controller acts as a built-in RF engineer to consistently provide real-time RF management of your wireless network. RRM enables Cisco WLCs to continually monitor their associated lightweight access points for the following information:

• Traffic load—The total bandwidth used for transmitting and receiving traffic. It enables wireless LAN managers to track and plan network growth ahead of client demand.

• Interference—The amount of traffic coming from other 802.11 sources.

• Noise—The amount of non-802.11 traffic that is interfering with the currently assigned channel.

• Coverage—The received signal strength (RSSI) and signal-to-noise ratio (SNR) for all connected clients.

• Other—The number of nearby access points.

Using this information, RRM can periodically reconfigure the 802.11 RF network for best efficiency. To do this, RRM performs these functions:

• Radio resource monitoring

• Transmit power control

• Dynamic channel assignment

Cisco Wireless Controller Configuration Guide, Release 8.3

335

Radio Resource Management

• Coverage hole detection and correction

Radio Resource Monitoring

RRM automatically detects and configures new Cisco WLCs and lightweight access points as they are added to the network. It then automatically adjusts associated and nearby lightweight access points to optimize coverage and capacity.

Lightweight access points can simultaneously scan all valid 802.11a/b/g channels for the country of operation as well as for channels available in other locations. The access points go “off-channel” for a period not greater than 60 ms to monitor these channels for noise and interference. Packets collected during this time are analyzed to detect rogue access points, rogue clients, ad-hoc clients, and interfering access points.

Note

In the presence of voice traffic (in the last 100 ms), the access points defer off-channel measurements.

Each access point spends only 0.2 percent of its time off-channel. This activity is distributed across all access points so that adjacent access points are not scanning at the same time, which could adversely affect wireless

LAN performance.

Note

When there are numerous rogue access points in the network, the chance of detecting rogues on channels

157 or 161 by a FlexConnect or local mode access point is small. In such cases, the monitor mode AP can be used for rogue detection.

Benefits of RRM

RRM produces a network with optimal capacity, performance, and reliability. It frees you from having to continually monitor the network for noise and interference problems, which can be transient and difficult to troubleshoot. RRM ensures that clients enjoy a seamless, trouble-free connection throughout the Cisco unified wireless network.

RRM uses separate monitoring and control for each deployed network: 802.11a and 802.11b/g. The RRM algorithms run separately for each radio type (802.11a and 802.11b/g). RRM uses both measurements and algorithms. RRM measurements can be adjusted using monitor intervals, but they cannot be disabled. RRM algorithms are enabled automatically but can be disabled by statically configuring channel and power assignment. The RRM algorithms run at a specified updated interval, which is 600 seconds by default.

Information About Configuring RRM

The controller’s preconfigured RRM settings are optimized for most deployments. However, you can modify the controller’s RRM configuration parameters at any time through either the GUI or the CLI.

You can configure these parameters on controllers that are part of an RF group or on controllers that are not part of an RF group.

The RRM parameters should be set to the same values on every controller in an RF group. The RF group leader can change as a result of controller reboots or depending on which radios hear each other. If the RRM parameters are not identical for all RF group members, varying results can occur when the group leader changes.

336

Cisco Wireless Controller Configuration Guide, Release 8.3

Radio Resource Management

Using the controller GUI, you can configure the following RRM parameters: RF group mode, transmit power control, dynamic channel assignment, coverage hole detection, profile thresholds, monitoring channels, and monitor intervals.

Restrictions for Configuring RRM

• The OEAP 600 series access points do not support RRM. The radios for the 600 series OEAP access points are controlled through the local GUI of the 600 series access points and not through the Cisco

WLC. Attempting to control the spectrum channel or power, or disabling the radios through the Cisco

WLC will fail to have any effect on the 600 series OEAP.

Configuring RRM (CLI)

Step 1

Step 2

Step 3

Disable the 802.11 network by entering this command:

config {802.11a | 802.11b} disable network

Choose the Transmit Power Control version by entering this command:

config advanced {802.11a | 802.11b} tpc-version {1 | 2} where:

• TPCv1: Coverage-optimal—(Default) Offers strong signal coverage and stability with negligent intercell interferences and sticky client syndrome.

• TPCv2: Interference-optimal—For scenarios where voice calls are extensively used. Tx power is dynamically adjusted with the goal of minimum interference. It is suitable for dense networks. In this mode, there can be higher roaming delays and coverage hole incidents.

Perform one of the following to configure transmit power control:

• Have RRM automatically set the transmit power for all 802.11 radios at periodic intervals by entering this command:

config {802.11a | 802.11b} txPower global auto

• Have RRM automatically reset the transmit power for all 802.11a or 802.11b/g radios one time by entering this command:

config {802.11a | 802.11b} txPower global once

• Configure the transmit power range that overrides the Transmit Power Control algorithm, use this command to enter the maximum and minimum transmit power used by RRM:

Note

In Cisco WLC software release 7.6 or later releases, disabling the 802.11 network is not required for this command.

config {802.11a | 802.11b} txPower global {max | min} txpower where txpower is a value from –10 to 30 dBM. The minimum value cannot be greater than the maximum value; the maximum value cannot be less than the minimum value.

If you configure a maximum transmit power, RRM does not allow any access point to exceed this transmit power

(whether the maximum is set at RRM startup, or by coverage hole detection). For example, if you configure a maximum transmit power of 11 dBm, then no access point would transmit above 11 dBm, unless the access point is configured manually.

Cisco Wireless Controller Configuration Guide, Release 8.3

337

Radio Resource Management

Step 4

Step 5

• Manually change the default transmit power setting by entering this command:

config advanced {802.11a | 802.11b} {tpcv1-thresh | tpcv2-thresh} threshold where threshold is a value from –80 to –50 dBm. Increasing this value causes the access points to operate at higher transmit power rates. Decreasing the value has the opposite effect.

In applications with a dense population of access points, it may be useful to decrease the threshold to –80 or –75 dBm in order to reduce the number of BSSIDs (access points) and beacons seen by the wireless clients. Some wireless clients may have difficulty processing a large number of BSSIDs or a high beacon rate and may exhibit problematic behavior with the default threshold.

• Configure the Transmit Power Control Version 2 on a per-channel basis by entering this command:

config advanced {802.11a | 802.11b} tpcv2-per-chan {enable | disable}

Perform one of the following to configure dynamic channel assignment (DCA):

• Have RRM automatically configure all 802.11 channels based on availability and interference by entering this command:

config {802.11a | 802.11b} channel global auto

• Have RRM automatically reconfigure all 802.11 channels one time based on availability and interference by entering this command:

config {802.11a | 802.11b} channel global once

• Disable RRM and set all channels to their default values by entering this command:

config {802.11a | 802.11b} channel global off

• Restart aggressive DCA cycle by entering this command:

config {802.11a | 802.11b} channel global restart

• To specify the channel set used for DCA by entering this command:

config advanced {802.11a | 802.11b} channel {add | delete} channel_number

You can enter only one channel number per command. This command is helpful when you know that the clients do not support certain channels because they are legacy devices or they have certain regulatory restrictions.

Configure additional DCA parameters by entering these commands:

• config advanced {802.11a | 802.11b} channel dca anchor-time value—Specifies the time of day when the DCA algorithm is to start. value is a number between 0 and 23 (inclusive) representing the hour of the day from 12:00 a.m. to 11:00 p.m.

• config advanced {802.11a | 802.11b} channel dca interval value—Specifies how often the DCA algorithm is allowed to run. value is one of the following: 1, 2, 3, 4, 6, 8, 12, or 24 hours or 0, which is the default value of 10 minutes (or 600 seconds).

Note

If your Cisco WLC supports only OfficeExtend access points, we recommend that you set the DCA interval to 6 hours for optimal performance. For deployments with a combination of OfficeExtend access points and local access points, the range of 10 minutes to 24 hours can be used.

• config advanced {802.11a | 802.11b} channel dca sensitivity {low | medium | high}—Specifies how sensitive the DCA algorithm is to environmental changes such as signal, load, noise, and interference when determining whether to change channel.

338

Cisco Wireless Controller Configuration Guide, Release 8.3

Radio Resource Management

◦low means that the DCA algorithm is not particularly sensitive to environmental changes.

◦medium means that the DCA algorithm is moderately sensitive to environmental changes.

◦high means that the DCA algorithm is highly sensitive to environmental changes.

The DCA sensitivity thresholds vary by radio band, as noted in following table.

Table 16: DCA Sensitivity Thresholds

Option

High

Medium

Low

2.4-GHz DCA Sensitivity Threshold 5-GHz DCA Sensitivity Threshold

5 dB

10 dB

20 dB

5 dB

15 dB

20 dB

• config advanced 802.11a channel dca chan-width {20 | 40 | 80}—Configures the DCA channel width for all

802.11n radios in the 5-GHz band.

where

◦20 sets the channel width for 802.11n radios to 20 MHz. This is the default value.

◦40 sets the channel width for 802.11n radios to 40 MHz.

Note

If you choose 40, be sure to set at least two adjacent channels in the config advanced 802.11a

channel {add | delete} channel_number command in Step 4 (for example, a primary channel of 36 and an extension channel of 40). If you set only one channel, that channel is not used for 40-MHz channel width.

If you choose 40, you can also configure the primary and extension channels used by individual access points.

To override the globally configured DCA channel width setting, you can configure an access point’s radio mode using the config 802.11a chan_width Cisco_AP {20 | 40 | 80| 160| best} command. If you change the static configuration to global on the access point radio, the global DCA configuration overrides the channel width configuration that the access point was previously using. It can take up to 30 minutes (depending on how often DCA is configured to run) for the change to take effect.

◦80 sets the channel width for the 802.11ac radios to 80 MHz.

◦160 sets the channel width for the 802.11ac radio to 160 MHz.

◦best sets the channel width for the 802.11ac radio to best suitable bandwidth.

• Configure slot-specific channel width by entering this command:

config slot slot-id ap-name {20 | 40 | 80}

• config advanced {802.11a | 802.11b} channel outdoor-ap-dca {enable | disable}—Enables or disables to the

Cisco WLC to avoid checks for non-DFS channels.

Note

This parameter is applicable only for deployments having outdoor access points such as 1522 and

1524.

Cisco Wireless Controller Configuration Guide, Release 8.3

339

Radio Resource Management

Step 6

Step 7

• config advanced {802.11a | 802.11b} channel foreign {enable | disable}—Enables or disables foreign access point interference avoidance in the channel assignment.

• config advanced {802.11a | 802.11b} channel load {enable | disable}—Enables or disables load avoidance in the channel assignment.

• config advanced {802.11a | 802.11b} channel noise {enable | disable}—Enables or disables noise avoidance in the channel assignment.

• config advanced {802.11a | 802.11b} channel update—Initiates an update of the channel selection for every

Cisco access point.

Configure coverage hole detection by entering these commands:

Note

You can disable coverage hole detection on a per-WLAN basis.

• config advanced {802.11a | 802.11b} coverage {enable | disable}—Enables or disables coverage hole detection.

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 enabled.

• config advanced {802.11a | 802.11b} coverage {data | voice} rssi-threshold rssi—Specifies the minimum receive signal strength indication (RSSI) value for 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 or voice queue with an RSSI value below the value 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 for data packets and –75 dBm for voice packets. The access point takes RSSI measurements every 5 seconds and reports them to the Cisco WLC in

90-second intervals.

• config advanced {802.11a | 802.11b} coverage level global clients—Specifies 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.

• config advanced {802.11a | 802.11b} coverage exception global percent—Specifies 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%.

• config advanced {802.11a | 802.11b} coverage {data | voice} packet-count packets—Specifies the minimum failure count threshold for uplink data or voice packets. The valid range is 1 to 255 packets, and the default value is 10 packets.

• config advanced {802.11a | 802.11b} coverage {data | voice} fail-rate percent—Specifies the failure rate threshold for uplink data or voice packets. The valid range is 1 to 100%, and the default value is 20%.

Note

If both the number and percentage of failed packets exceed the values entered in the packet-count and

fail-rate commands for a 5-second period, the client is considered to be in a pre-alarm condition. The

Cisco WLC uses this information to distinguish between real and false coverage holes. False positives are generally due to the poor roaming logic implemented on most clients. A coverage hole is detected if both the number and percentage of failed clients meet or exceed the values entered in the coverage level global and coverage exception global commands over a 90-second period. The Cisco WLC determines if the coverage hole can be corrected and, if appropriate, mitigates the coverage hole by increasing the transmit power level for that specific access point.

Configure RRM NDP mode by entering this command:

340

Cisco Wireless Controller Configuration Guide, Release 8.3

Radio Resource Management

Step 8

Step 9

Step 10

config advanced 802.11{a|b} monitor ndp-mode {protected | transparent}

This command configures NDP mode. By default, the mode is set to “transparent”. The following options are available:

• Protected—Packets are encrypted.

• Transparent—Packets are sent as is.

Note

See the discovery type by entering the show advanced 802.11{a|b} monitor command.

Configure 802.11a or 802.11b/g network neighbor timeout-factor by entering this command:

config {802.11a | 802.11b} monitor timeout-factor factor-bw-5-to-60-minutes

If you are using Release 8.1 or a later release, we recommend that you set the timeout factor to 60 minutes. If the access point radio does not receive a neighbor packet from an existing neighbor within 60 minutes, the Cisco WLC deletes the neighbor from the neighbor list.

Note

The Neighbor Timeout Factor was hardcoded to 60 minutes in Release 7.6, but was changed to 5 minutes in

Release 8.0.100.0.

Enable the 802.11a or 802.11b/g network by entering this command:

config {802.11a | 802.11b} enable network

Note

To enable the 802.11g network, enter config 802.11b 11gSupport enable after the config 802.11b enable

network command.

Save your settings by entering this command:

save config

Viewing RRM Settings (CLI)

To see 802.11a and 802.11b/g RRM settings, use these commands:

show advanced {802.11a | 802.11b} ?

where ? is one of the following:

• ccx {global | Cisco_AP}—Shows the CCX RRM configuration.

• channel—Shows the channel assignment configuration and statistics.

• coverage—Shows the coverage hole detection configuration and statistics.

• logging—Shows the RF event and performance logging.

• monitor—Shows the Cisco radio monitoring.

• profile {global | Cisco_AP}—Shows the access point performance profiles.

• receiver—Shows the 802.11a or 802.11b/g receiver configuration and statistics.

• summary—Shows the configuration and statistics of the 802.11a or 802.11b/g access points.

• txpower—Shows the transmit power assignment configuration and statistics.

Cisco Wireless Controller Configuration Guide, Release 8.3

341

RF Groups

Debug RRM Issues (CLI)

Use these commands to troubleshoot and verify RRM behavior:

debug airewave-director ? where ? is one of the following:

• all—Enables debugging for all RRM logs.

• channel—Enables debugging for the RRM channel assignment protocol.

• detail—Enables debugging for RRM detail logs.

• error—Enables debugging for RRM error logs.

• group—Enables debugging for the RRM grouping protocol.

• manager—Enables debugging for the RRM manager.

• message—Enables debugging for RRM messages.

• packet—Enables debugging for RRM packets.

• power—Enables debugging for the RRM power assignment protocol as well as coverage hole detection.

• profile—Enables debugging for RRM profile events.

• radar—Enables debugging for the RRM radar detection/avoidance protocol.

• rf-change—Enables debugging for RRM RF changes.

RF Groups

Information About RF Groups

An RF group is a logical collection of Cisco WLCs that coordinate to perform RRM in a globally optimized manner to perform network calculations on a per-radio basis. An RF group exists for each 802.11 network type. Clustering Cisco WLCs into a single RF group enable the RRM algorithms to scale beyond the capabilities of a single Cisco WLC.

RF group is created based on following parameters:

• User-configured RF network name.

• Neighbor discovery performed at the radio level.

• Country list configured on MC.

RF grouping runs between MCs.

Lightweight access points periodically send out neighbor messages over the air. Access points using the the same RF group name validate messages from each other.

When access points on different Cisco WLCs hear validated neighbor messages at a signal strength of –80 dBm or stronger, the Cisco WLCs dynamically form an RF neighborhood in auto mode. In static mode, the leader is manually selected and the members are added to the RF Group. To know more about RF Group modes,

RF Group Leader .

342

Cisco Wireless Controller Configuration Guide, Release 8.3

RF Groups

Note

RF groups and mobility groups are similar in that they both define clusters of Cisco WLCs, but they are different in terms of their use. An RF group facilitates scalable, system-wide dynamic RF management while a mobility group facilitates scalable, system-wide mobility and Cisco WLC redundancy.

RF Group Leader

Starting in the 7.0.116.0 release, the RF Group Leader can be configured in two ways as follows:

• Auto Mode—In this mode, the members of an RF group elect an RF group leader to maintain a “master” power and channel scheme for the group. The RF grouping algorithm dynamically chooses the RF group leader and ensures that an RF group leader is always present. Group leader assignments can and do change (for instance, if the current RF group leader becomes inoperable or if RF group members experience major changes).

• Static Mode—In this mode, the user selects a Cisco WLC as an RF group leader manually. In this mode, the leader and the members are manually configured and are therefore fixed. If the members are unable to join the RF group, the reason is indicated. The leader tries to establish a connection with a member every 1 minute if the member has not joined in the previous attempt.

The RF group leader analyzes real-time radio data collected by the system, calculates the power and channel assignments, and sends them to each of the Cisco WLCs in the RF group. The RRM algorithms ensure system-wide stability and restrain channel and power scheme changes to the appropriate local RF neighborhoods.

In Cisco WLC software releases prior to 6.0, the dynamic channel assignment (DCA) search algorithm attempts to find a good channel plan for the radios associated to Cisco WLCs in the RF group, but it does not adopt a new channel plan unless it is considerably better than the current plan. The channel metric of the worst radio in both plans determines which plan is adopted. Using the worst-performing radio as the single criterion for adopting a new channel plan can result in pinning or cascading problems.

Pinning occurs when the algorithm could find a better channel plan for some of the radios in an RF group but is prevented from pursuing such a channel plan change because the worst radio in the network does not have any better channel options. The worst radio in the RF group could potentially prevent other radios in the group from seeking better channel plans. The larger the network, the more likely pinning becomes.

Cascading occurs when one radio’s channel change results in successive channel changes to optimize the remaining radios in the RF neighborhood. Optimizing these radios could lead to their neighbors and their neighbors’ neighbors having a suboptimal channel plan and triggering their channel optimization. This effect could propagate across multiple floors or even multiple buildings, if all the access point radios belong to the same RF group. This change results in considerable client confusion and network instability.

The main cause of both pinning and cascading is the way in which the search for a new channel plan is performed and that any potential channel plan changes are controlled by the RF circumstances of a single radio. In Cisco WLC software release 6.0, the DCA algorithm has been redesigned to prevent both pinning and cascading. The following changes have been implemented:

• Multiple local searches—The DCA search algorithm performs multiple local searches initiated by different radios within the same DCA run rather than performing a single global search driven by a single radio. This change addresses both pinning and cascading while maintaining the desired flexibility and adaptability of DCA and without jeopardizing stability.

Cisco Wireless Controller Configuration Guide, Release 8.3

343

RF Groups

• Multiple channel plan change initiators (CPCIs)—Previously, the single worst radio was the sole initiator of a channel plan change. Now each radio within the RF group is evaluated and prioritized as a potential initiator. Intelligent randomization of the resulting list ensures that every radio is eventually evaluated, which eliminates the potential for pinning.

• Limiting the propagation of channel plan changes (Localization)—For each CPCI radio, the DCA algorithm performs a local search for a better channel plan, but only the CPCI radio itself and its one-hop neighboring access points are actually allowed to change their current transmit channels. The impact of an access point triggering a channel plan change is felt only to within two RF hops from that access point, and the actual channel plan changes are confined to within a one-hop RF neighborhood. Because this limitation applies across all CPCI radios, cascading cannot occur.

• Non-RSSI-based cumulative cost metric—A cumulative cost metric measures how well an entire region, neighborhood, or network performs with respect to a given channel plan. The individual cost metrics of all access points in that area are considered in order to provide an overall understanding of the channel plan’s quality. These metrics ensure that the improvement or deterioration of each single radio is factored into any channel plan change. The objective is to prevent channel plan changes in which a single radio improves but at the expense of multiple other radios experiencing a considerable performance decline.

The RRM algorithms run at a specified updated interval, which is 600 seconds by default. Between update intervals, the RF group leader send