Table Of Contents
Configuring Controller Settings
Using the Configuration Wizard
Before You Start
Resetting the Device to Default Settings
Resetting to Default Settings Using the CLI
Resetting to Default Settings Using the GUI
Running the Configuration Wizard on the CLI
Managing the System Time and Date
Configuring an NTP Server to Obtain the Time and Date
Configuring the Time and Date Manually
Enabling and Disabling 802.11 Bands
Configuring Administrator Usernames and Passwords
Configuring RADIUS Settings
Configuring SNMP
Changing the Default Values of SNMP Community Strings
Using the GUI to Change the SNMP Community String Default Values
Using the CLI to Change the SNMP Community String Default Values
Changing the Default Values for SNMP v3 Users
Using the GUI to Change the SNMP v3 User Default Values
Using the CLI to Change the SNMP v3 User Default Values
Configuring Aggressive Load Balancing
Using the GUI to Configure Aggressive Load Balancing
Using the CLI to Configure Aggressive Load Balancing
Enabling 802.3x Flow Control
Enabling System Logging
Using the GUI to Enable System Logging
Using the GUI to View Message Logs
Using the CLI to Enable System Logging
Using the CLI to View Message Logs
Configuring 802.3 Bridging
Using the GUI to Configure 802.3 Bridging
Using the CLI to Configure 802.3 Bridging
Enabling Dynamic Transmit Power Control
Configuring Multicast Mode
Understanding Multicast Mode
Guidelines for Using Multicast Mode
Enabling Multicast Mode
Configuring Client Roaming
Intra-Controller Roaming
Inter-Controller Roaming
Inter-Subnet Roaming
Voice-over-IP Telephone Roaming
CCX Layer 2 Client Roaming
Using the GUI to Configure CCX Client Roaming Parameters
Using the CLI to Configure CCX Client Roaming Parameters
Using the CLI to Obtain CCX Client Roaming Information
Using the CLI to Debug CCX Client Roaming Issues
Configuring Voice and Video Parameters
Call Admission Control
Bandwidth-Based CAC
Load-Based CAC
Expedited Bandwidth Requests
U-APSD
Traffic Stream Metrics
Using the GUI to Configure Voice Parameters
Using the GUI to Configure Video Parameters
Using the GUI to View Voice and Video Settings
Using the CLI to Configure Voice Parameters
Using the CLI to Configure Video Parameters
Using the CLI to View Voice and Video Settings
Configuring Cisco Discovery Protocol
Using the GUI to Configure Cisco Discovery Protocol
Using the GUI to View Cisco Discovery Protocol Information
Using the CLI to Configure Cisco Discovery Protocol
Using the CLI to View Cisco Discovery Protocol Information
Configuring RFID Tag Tracking
Using the CLI to Configure RFID Tag Tracking
Using the CLI to View RFID Tag Tracking Information
Viewing Location Information
Configuring the Supervisor 720 to Support the WiSM
General WiSM Guidelines
Configuring the Supervisor
Using the Wireless LAN Controller Network Module
Configuring Controller Settings
This chapter describes how to configure settings on the controllers. It contains these sections:
•
Using the Configuration Wizard
•Managing the System Time and Date
•Enabling and Disabling 802.11 Bands
•Configuring Administrator Usernames and Passwords
•Configuring RADIUS Settings
•Configuring SNMP
•Changing the Default Values of SNMP Community Strings
•Changing the Default Values for SNMP v3 Users
•Configuring Aggressive Load Balancing
•Enabling 802.3x Flow Control
•Enabling System Logging
•Configuring 802.3 Bridging
•Enabling Dynamic Transmit Power Control
•Configuring Multicast Mode
•Configuring Client Roaming
•Configuring Voice and Video Parameters
•Configuring Cisco Discovery Protocol
•Configuring RFID Tag Tracking
•Viewing Location Information
•Configuring the Supervisor 720 to Support the WiSM
•Using the Wireless LAN Controller Network Module
Using the Configuration Wizard
This section describes how to configure basic settings on a controller for the first time or after the configuration has been reset to factory defaults. The contents of this chapter are similar to the instructions in the quick start guide that shipped with your controller.
You use the configuration wizard to configure basic settings. You can run the wizard on the CLI or the GUI. This section explains how to run the wizard on the CLI.
This section contains these sections:
•Before You Start
•Resetting the Device to Default Settings
•Running the Configuration Wizard on the CLI
Before You Start
You should collect these basic configuration parameters before configuring the controller:
•System name for the controller
•802.11 protocols supported: 802.11a and/or 802.11b/g
•Administrator usernames and passwords (optional)
•Distribution system (network) port static IP address, netmask, and optional default gateway IP address
•Service port static IP address and netmask (optional)
•Distribution system physical port (1000BASE-T, 1000BASE-SX, or 10/100BASE-T)
Note Each 1000BASE-SX connector provides a 100/1000-Mbps wired connection to a network through an 850nM (SX) fiber-optic link using an LC physical connector.
•Distribution system port VALN assignment (optional)
•Distribution system port web and secure web mode settings: enabled or disabled
•Distribution system port Spanning Tree Protocol: enabled/disabled, 802.1D/fast/off mode per port, path cost per port, priority per port, bridge priority, forward delay, hello time, maximum age
•WLAN configuration: SSID, VLAN assignments, Layer 2 security settings, Layer 3 security settings, QoS assignments
•Mobility Settings: Mobility Group Name (optional)
•RADIUS Settings
•SNMP Settings
•NTP server settings (the wizard prompts you for NTP server settings when you run the wizard on a wireless controller network module installed in a Cisco Integrated Services router)
•Other port and parameter settings: service port, Radio Resource Management (RRM), third-party access points, console port, 802.3x flow control, and system logging
Resetting the Device to Default Settings
If you need to start over during the initial setup process, you can reset the controller to factory default settings.
Note After resetting the configuration to defaults, you need a serial connection to the controller to use the configuration wizard.
Resetting to Default Settings Using the CLI
Follow these steps to reset the configuration to factory default settings using the CLI.
Step 1 Enter reset system. At the prompt that asks whether you need to save changes to the configuration, enter Y or N. The unit reboots.
Step 2 When you are prompted for a username, enter recover-config to restore the factory default configuration. The controller reboots and displays this message:
Welcome to the Cisco WLAN Solution Wizard Configuration Tool
Step 3 Use the configuration wizard to enter configuration settings.
Resetting to Default Settings Using the GUI
Follow these steps to return to default settings using the GUI.
Step 1 Open your Internet browser. The GUI is fully compatible with Microsoft Internet Explorer version 6.0 or later on Windows platforms.
Step 2 Enter the controller IP address in the browser address line and press Enter. An Enter Network Password windows appears.
Step 3 Enter your username in the User Name field. The default username is admin.
Step 4 Enter the wireless device password in the Password field and press Enter. The default password is admin.
Step 5 Browse to the Commands > Reset to Factory Defaults page.
Step 6 Click Reset. At the prompt, confirm the reset.
Step 7 Reboot the unit and do not save changes.
Step 8 Use the configuration wizard to enter configuration settings.
Running the Configuration Wizard on the CLI
When the controller boots at factory defaults, the bootup script runs the configuration wizard, which prompts the installer for initial configuration settings. Follow these steps to enter settings using the wizard on the CLI.
Note To configure the controller in the Catalyst 3750G Integrated Wireless LAN Controller Switch, Cisco recommends that you use the GUI configuration wizard that launches from the 3750 Device Manager. Refer to the Catalyst 3750G Integrated Wireless LAN Controller Switch Getting Started Guide for instructions.
Note The available options appear in brackets after each configuration parameter. The default value appears in all uppercase letters.
Note 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.
Note Press the hyphen key if you ever need to return to the previous command line.
Step 1 Connect your computer to the controller using a DB-9 null-modem serial cable.
Step 2 Open a terminal emulator session using these settings:
•9600 baud
•8 data bits
•1 stop bit
•no parity
•no hardware flow control
Step 3 At the prompt, log into the CLI. The default username is admin and the default password is admin.
Step 4 If necessary, enter reset system to reboot the unit and start the wizard.
Step 5 Enter the system name, which is the name you want to assign to the controller. You can enter up to 32 ASCII characters.
Step 6 Enter the administrative username and password to be assigned to this controller. You can enter up to 24 ASCII characters for each. The default administrative username and password are admin and admin, respectively.
Step 7 Enter the service-port interface IP configuration protocol: none or 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.
Step 8 If you entered none in step 7 and need to enter a static IP address for the service port, enter the service-port interface IP address and netmask for the next two prompts.
Step 9 Enable or disable link aggregation (LAG) by choosing yes or NO. Refer to Chapter 3 for more information on LAG.
Step 10 Enter the IP address of the management interface.
Step 11 Enter the IP address of the management interface netmask.
Step 12 Enter the IP address of the default router.
Step 13 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.
Step 14 Enter the network interface (distribution system) physical port number. For the controller, the possible ports are 1 through 4 for a front panel GigE port.
Step 15 Enter the IP address of the default DHCP server that will supply IP addresses to clients, the management interface, and the service port interface if you use one.
Step 16 Enter Layer2 or Layer3 for the LWAPP transport mode. Refer to Chapter 1 for more information on Layer 2 and Layer 3 operation.
Note The controller in the Catalyst 3750G Integrated Wireless LAN Controller Switch operates only in Layer 3 mode.
Step 17 Enter the IP address of the access point manager interface.
Step 18 Enter the IP address of the controller's virtual interface. You should enter a fictitious, unassigned IP address such as 1.1.1.1.
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.
Step 19 If desired, 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. See Chapter 10 and Chapter 11 for more information.
Step 20 Enable or disable symmetric mobility tunneling by entering yes or no. Symmetric mobility tunneling allows inter-subnet mobility to continue when reverse path filtering (RPF) is enabled on a router on any of the subnets. Refer to Chapter 11 for more information.
Step 21 Enter the network name, or service set identifier (SSID). The initial SSID enables basic functionality of the controller and allows access points that have joined the controller to enable their radios.
Step 22 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.
Step 23 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 documentation for more details."
Step 24 Enter the code for the country in which the network is located. Enter help to view the list of available country codes.
Note 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. See the "Enabling and Disabling 802.11 Bands" section for instructions.
Step 25 When you run the wizard on a wireless controller network module installed in a Cisco Integrated Services Router, the wizard prompts you for NTP server settings. The controller network module does not have a battery and cannot save a time setting. It must receive a time setting from an external NTP server when it powers up.
Step 26 Enable or disable support for each of the 802.11b, 802.11a, and 802.11g lightweight access point networks by entering yes or no.
Step 27 Enable or disable the radio resource management (RRM) auto-RF feature by entering yes or no. Refer to Chapter 10 for more information on RRM.
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.
The controller saves your configuration, reboots, and prompts you to log in or to enter recover-config to reset to the factory default configuration and return to the wizard.
Managing the System Time and Date
You can configure the controller to obtain the time and date from a Network Time Protocol (NTP) server, or you can configure the time and date manually.
Configuring an NTP Server to Obtain the Time and Date
Each NTP server IP address is added to the controller database. Each controller searches for an NTP server and obtains the current time upon reboot and at each user-defined polling interval (daily to weekly).
Use the commands to configure an NTP server to obtain the time and date.
1. To specify the NTP server for the controller, enter this command:
config time ntp server index ip_address
2. To specify the polling interval (in seconds), enter this command:
config time ntp interval
Configuring the Time and Date Manually
Use these commands to configure the date and time manually.
1. To check the current system time and date, enter this command:
show time
2. To update the time, according to the Greenwich Mean Time (GMT) time zone, enter this command:
config time manual mm/dd/yy hh:mm:ss
3. To specify the time difference between GMT and the time zone where the controller is located, enter this command:
config time timezone delta_hours
Note Daylight Savings Time (DST) is not supported in controller software release 4.1.
Enabling and Disabling 802.11 Bands
You can enable or disable the 802.11b/g (2.4-GHz) and the 802.11a (5-GHz) bands for the controller to comply with the regulatory requirements in your country. By default, both 802.11b/g and 802.11a are enabled.
On the CLI, enter config 802.11b disable network to disable 802.11b/g operation on the controller. Enter config 802.11b enable network to re-enable 802.11b/g operation.
Enter config 802.11a disable network to disable 802.11a operation on the controller. Enter config 802.11a enable network to re-enable 802.11a operation.
Configuring Administrator Usernames and Passwords
Note The controller does not have a password recovery mechanism. If you use WCS to manage the controller, you should be able to access the controller from WCS and create a new admin user without logging into the controller itself. If you have not saved the configuration on the controller after deleting the user, then rebooting (power cycling) the controller should bring it back up with the deleted user still in the system. If you do not have the default admin account or another user account with which you can log in, your only option is to default the controller to factory settings and reconfigure it from scratch or reload the previously saved configuration.
You can configure administrator usernames and passwords to prevent unauthorized users from reconfiguring the controller and viewing configuration information.
On the CLI, enter config mgmtuser add username password read-write to create a username-password pair with read-write privileges. Enter config mgmtuser add username password read-only to create 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.
To change the password for an existing username, enter config mgmtuser password username new_password
To list configured users, enter show mgmtuser.
Configuring RADIUS Settings
If you need to use a RADIUS server for accounting or authentication, follow these steps on the CLI to configure RADIUS settings for the controller:
Step 1 Enter config radius acct ip-address to configure a RADIUS server for accounting.
Step 2 Enter config radius acct port to specify the UDP port for accounting.
Step 3 Enter config radius acct secret to configure the shared secret.
Step 4 Enter config radius acct enable to enable accounting. Enter config radius acct disable to disable accounting. Accounting is disabled by default.
Step 5 Enter config radius auth ip-address to configure a RADIUS server for authentication.
Step 6 Enter config radius auth port to specify the UDP port for authentication.
Step 7 Enter config radius auth secret to configure the shared secret.
Step 8 Enter config radius auth enable to enable authentication. Enter config radius acct disable to disable authentication. Authentication is disabled by default.
Step 9 Use the show radius acct statistics, show radius auth statistics, and show radius summary commands to verify that the RADIUS settings are correctly configured.
Configuring SNMP
Cisco recommends that you use the GUI to configure SNMP settings on the controller. To use the CLI, follow these steps:
Step 1 Enter config snmp community create name to create an SNMP community name.
Step 2 Enter config snmp community delete name to delete an SNMP community name.
Step 3 Enter config snmp community accessmode ro name to configure an SNMP community name with read-only privileges. Enter config snmp community accessmode rw name to configure an SNMP community name with read-write privileges.
Step 4 Enter config snmp community ipaddr ip-address ip-mask name to configure an IP address and subnet mask for an SNMP community.
Note This command behaves like an SNMP access list. It specifies the IP address from which the device accepts SNMP packets with the associated community. The requesting entity's IP address is ANDed with the subnet mask before being compared to the IP address. If the subnet mask is set to 0.0.0.0, an IP address of 0.0.0.0 matches to all IP addresses. The default value is 0.0.0.0.
Note The controller can use only one IP address range to manage an SNMP community.
Step 5 Enter config snmp community mode enable to enable a community name. Enter config snmp community mode disable to disable a community name.
Step 6 Enter config snmp trapreceiver create name ip-address to configure a destination for a trap.
Step 7 Enter config snmp trapreceiver delete name to delete a trap.
Step 8 Enter config snmp trapreceiver ipaddr old-ip-address name new-ip-address to change the destination for a trap.
Step 9 Enter config snmp trapreceiver mode enable to enable traps. Enter config snmp trapreceiver mode disable to disable traps.
Step 10 Enter config snmp syscontact syscontact-name to configure the name of the SNMP contact. Enter up to 31 alphanumeric characters for the contact name.
Step 11 Enter config snmp syslocation syslocation-name to configure the SNMP system location. Enter up to 31 alphanumeric characters for the location.
Step 12 Use the show snmpcommunity and show snmptrap commands to verify that the SNMP traps and communities are correctly configured.
Step 13 Use the show trapflags command to see the enabled and disabled trapflags. If necessary, use the config trapflags commands to enable or disable trapflags.
Changing the Default Values of SNMP Community Strings
The controller has commonly known default values of "public" and "private" for the read-only and read-write SNMP community strings. Using these standard values presents a security risk. Therefore, Cisco strongly advises that you change these values.
Using the GUI to Change the SNMP Community String Default Values
Follow these steps to change the SNMP community string default values through the controller GUI.
Step 1 Click Management and then Communities under SNMP. The SNMP v1 / v2c Community page appears (see Figure 4-1).
Figure 4-1 SNMP v1 / v2c Community Page
Step 2 If "public" or "private" appears in the Community Name column, hover your cursor over the blue drop-down arrow for the desired community and choose Remove to delete this community.
Step 3 Click New to create a new community. The SNMP v1 / v2c Community > New page appears (see Figure 4-2).
Figure 4-2 SNMP v1 / v2c Community > New Page
Step 4 In the Community Name field, enter a unique name containing up to 16 alphanumeric characters. Do not enter "public" or "private."
Step 5 In the next two fields, enter the IP address from which this device accepts SNMP packets with the associated community and the IP mask.
Step 6 Choose Read Only or Read/Write from the Access Mode drop-down box to specify the access level for this community.
Step 7 Choose Enable or Disable from the Status drop-down box to specify the status of this community.
Step 8 Click Apply to commit your changes.
Step 9 Click Save Configuration to save your settings.
Step 10 Repeat this procedure if a "public" or "private" community still appears on the SNMP v1 / v2c Community page.
Using the CLI to Change the SNMP Community String Default Values
Follow these steps to change the SNMP community string default values through the controller CLI.
Step 1 To see the current list of SNMP communities for this controller, enter this command:
show snmp community
Step 2 If "public" or "private" appears in the SNMP Community Name column, enter this command to delete this community:
config snmp community delete name
The name parameter is the community name (in this case, "public" or "private").
Step 3 To create a new community, enter this command:
config snmp community create name
Enter up to 16 alphanumeric characters for the name parameter. Do not enter "public" or "private."
Step 4 To enter the IP address from which this device accepts SNMP packets with the associated community, enter this command:
config snmp community ipaddr ip_address ip_mask name
Step 5 To specify the access level for this community, enter this command, where ro is read-only mode and rw is read/write mode:
config snmp community accessmode {ro | rw} name
Step 6 To enable or disable this SNMP community, enter this command:
config snmp community mode {enable | disable} name
Step 7 To save your changes, enter save config.
Step 8 Repeat this procedure if you still need to change the default values for a "public" or "private" community string.
Changing the Default Values for SNMP v3 Users
The controller uses a default value of "default" for the username, authentication password, and privacy password for SNMP v3 users. Using these standard values presents a security risk. Therefore, Cisco strongly advises that you change these values.
Note SNMP v3 is time sensitive. Make sure that you have configured the correct time and timezone on your controller.
Using the GUI to Change the SNMP v3 User Default Values
Follow these steps to change the SNMP v3 user default values through the controller GUI.
Step 1 Click Management and then SNMP V3 Users under SNMP. The SNMP V3 Users page appears (see Figure 4-3).
Figure 4-3 SNMP V3 Users Page
Step 2 If "default" appears in the User Name column, hover your cursor over the blue drop-down arrow for the desired user and choose Remove to delete this SNMP v3 user.
Step 3 Click New to add a new SNMP v3 user. The SNMP V3 Users > New page appears (see Figure 4-4).
Figure 4-4 SNMP V3 Users > New Page
Step 4 In the User Profile Name field, enter a unique name. Do not enter "default."
Step 5 Choose Read Only or Read Write from the Access Mode drop-down box to specify the access level for this user.
Step 6 In the next two fields, choose the authentication and privacy protocols to be used, and enter a password for each.
Step 7 Click Apply to commit your changes.
Step 8 Click Save Configuration to save your settings.
Using the CLI to Change the SNMP v3 User Default Values
Follow these steps to change the SNMP v3 user default values through the controller CLI.
Step 1 To see the current list of SNMP v3 users for this controller, enter this command:
show snmpv3user
Step 2 If "default" appears in the SNMP v3 User Name column, enter this command to delete this user:
config snmp v3user delete username
The username parameter is the SNMP v3 username (in this case, "default").
Step 3 To create a new SNMP v3 user, enter this command:
config snmp v3user create username {ro | rw} {none | hmacmd5 | hmacsha} {none | des} auth_password privacy_password
where
•username is the SNMP v3 username,
•ro is read-only mode and rw is read/write mode,
•none, hmacmd5, and hmacsha are the authentication protocol options,
•none and des are the privacy protocol options,
•auth_password is the authentication password, and
•privacy_password is the privacy password.
Do not enter "default" for the username and password parameters.
Step 4 To save your changes, enter save config.
Configuring Aggressive Load Balancing
Enabling aggressive load balancing on the controller allows lightweight access points to load balance wireless clients across access points in an LWAPP system. You can enable aggressive load balancing using the controller GUI or CLI.
When a wireless client attempts to associate to a lightweight access point, association response packets are sent to the client with an 802.11 response packet including status code 17. This code indicates that the access point is too busy to accept any more associations. The client then attempts to associate to a different access point. For example, if load balancing is enabled and the client count is configured as 5 clients, when a sixth client tries to associate to the access point, the client receives an 802.11 response packet with status code 17, indicating that the access point is busy.
Note When you use Cisco 7920 Wireless IP Phones with controllers, make sure that aggressive load balancing is disabled for each controller. Otherwise, the initial roam attempt by the phone may fail, causing a disruption in the audio path.
Using the GUI to Configure Aggressive Load Balancing
Follow these steps to configure aggressive load balancing using the GUI.
Step 1 Click Controller > General to access the General page.
Step 2 From the Aggressive Load Balancing drop-down box, choose either Enabled or Disabled to configure this feature. The default value is Disabled.
Step 3 Click Apply to commit your changes.
Step 4 Click Save Configuration to save your changes.
Using the CLI to Configure Aggressive Load Balancing
Follow these steps to configure aggressive load balancing using the CLI.
Step 1 To enable or disable aggressive load balancing, enter this command:
config load-balancing status {enable | disable}
The default value is disabled.
Step 2 To set the client count for aggressive load balancing, enter this command:
config load-balancing window clients
You can enter a value between 0 and 20 for the clients parameter. The default value is 5.
Step 3 To save your changes, enter this command:
save config
Step 4 To verify your settings, enter this command:
show load-balancing
Information similar to the following appears:
Aggressive Load Balancing........................ Enabled
Aggressive Load Balancing Window.............. 5 clients
Enabling 802.3x Flow Control
802.3x Flow Control is disabled by default. To enable it, enter config switchconfig flowcontrol enable.
Enabling System Logging
System logging allows controllers to log their system events to an external syslog server. System logging is disabled by default. You can use the controller GUI or CLI to enable system logging.
Using the GUI to Enable System Logging
Follow these steps to enable system logging through the GUI.
Step 1 Click Management < Logs < Config. The Syslog Configuration page appears (see Figure 4-5).
Figure 4-5 Syslog Configuration Page
Step 2 Check the Syslog check box to enable system logging or uncheck it to disable system logging. The default value is unchecked.
Step 3 In the Syslog Server IP Address field, enter the IP address of the server to which to send the system log.
Step 4 Choose a logging level from the Message Log Level drop-down box. There are five logging levels from which you can choose:
•Critical Failure
•Software Error
•Authentication or Security Errors
•Unexpected Software Events
•Significant System Events
When you choose a logging level, the system logs messages for that level and for the levels above it. For example, if you choose Unexpected Software Events, the system logs unexpected software events, authentication or security errors, software errors, and critical failures.
Step 5 Click Apply to commit your changes.
Step 6 Click Save Configuration to save your changes
Using the GUI to View Message Logs
To view system message logs through the GUI, click Management < Logs < Message Logs. The Message Logs page appears (see Figure 4-6).
Figure 4-6 Message Logs Page
Using the CLI to Enable System Logging
Follow these steps to enable system logging through the CLI.
Step 1 To enable system logging and set the IP address of the syslog server, enter this command:
config syslog ip_address
Step 2 To set the logging level, enter this command:
config msglog level msg_level
For msg_level, you can enter one of the following five values:
•critical—Critical hardware or software failure
•error—Non-critical software errors
•security—Authentication- or security-related errors
•warning—Unexpected software events
•verbose—Significant system events
Using the CLI to View Message Logs
Use these commands to view system message logs through the CLI.
1. To view the current syslog status, enter this command:
show syslog
2. To view the message logs, enter this command:
show msglog
Configuring 802.3 Bridging
The controller supports 802.3 frames and the applications that use them, such as those typically used for cash registers and cash register servers. However, to make these applications work with the controller, the 802.3 frames must be bridged on the controller.
Support for raw 802.3 frames allows the controller to bridge non-IP frames for applications not running over IP. Only this raw 802.3 frame format is currently supported:
+-------------------+---------------------+-----------------+------------------------+
| Destination | Source | Total packet | Payload .....
| MAC address | MAC address | length |
+-------------------+----------------------+-----------------+------------------------
You can configure 802.3 bridging through the controller GUI in software release 4.1 or later and through the controller CLI in software release 4.0 or later.
Note You can also configure 802.3 bridging using the Cisco Wireless Control System (WCS). Refer to the Cisco Wireless Control System Configuration Guide for instructions.
Using the GUI to Configure 802.3 Bridging
Follow these steps to configure 802.3 bridging using the controller GUI.
Step 1 Click Controller > General to access the General page (see Figure 4-7).
Figure 4-7 General Page
Step 2 From the 802.3 Bridging drop-down box, choose Enabled to enable 802.3 bridging on your controller or Disabled to disable this feature. The default value is Disabled.
Step 3 Click Apply to commit your changes.
Step 4 Click Save Configuration to save your changes.
Using the CLI to Configure 802.3 Bridging
Follow these steps to configure 802.3 bridging using the controller CLI.
Step 1 To see the current status of 802.3 bridging for all WLANs, enter this command:
show network
Step 2 To enable or disable 802.3 bridging globally on all WLANs, enter this command:
config network 802.3-bridging {enable | disable}
The default value is disabled.
Step 3 To save your settings, enter this command:
save config
Enabling Dynamic Transmit Power Control
When you enable Dynamic Transmit Power Control (DTPC), access points add channel and transmit power information to beacons. (On access points that run Cisco IOS software, this feature is called world mode.) Client devices using DTPC receive the information 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. DTPC is enabled by default.
Enter this command to disable or enable DTPC:
config {802.11a | 802.11b} dtpc {enable | disable}
Configuring Multicast 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 an LWAPP 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.
Understanding Multicast Mode
When you enable multicast mode, the controller does not become a member the multicast group. When the controller receives a multicast packet from the wired LAN, the controller encapsulates the packet using LWAPP and forwards the packet to the LWAPP 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.
When the source of the multicast is a wireless client, the multicast packet is unicast to the controller. In this case the controller makes two copies of the packet. One copy is the raw Ethernet packet that the controller sends out to the interface for the wireless LAN on which the client is associated, enabling the receivers on the wired LAN to receive the multicast traffic. The second copy of the packet is LWAPP-encapsulated and is sent to the multicast group. In this case the source of the multicast also receives the multicast packet, which helps the wireless client receive the multicast source.
Guidelines for Using Multicast Mode
Follow these guidelines when you enable multicast mode on your network:
•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.255.255—Limited scope addresses
•When you enable multicast mode on the controller you also must configure an LWAPP multicast group address on the controller. Access points subscribe to the LWAPP multicast group using IGMP.
•Cisco 1100, 1130, 1200, 1230, and 1240 access points use IGMP versions 1, 2, and 3. However, Cisco 1000 series access points use only IGMP v1 to join the multicast group.
•Multicast mode works only in Layer 3 LWAPP mode.
•Access points in monitor mode, sniffer mode, or rogue detector mode do not join the LWAPP multicast group address.
•When using multiple controllers on the network, make sure that the same multicast address is configured on all the controllers.
•Multicast mode does not work across intersubnet mobility events such as guest tunneling, site-specific VLANs, or interface override using RADIUS. However, multicast mode does work in these subnet mobility events when you disable the layer 2 IGMP snooping/CGMP features on the wired LAN.
•The controller drops any multicast packets sent to the UDP port numbers 12222, 12223, and 12224. Make sure the multicast applications on your network do not use those port numbers.
•Cisco recommends that any multicast applications on your network not use the multicast address configured as the LWAPP multicast group address on the controller.
Enabling Multicast Mode
Multicasting is disabled by default. Use the commands in Table 4-1 to configure multicast mode on the controller CLI.
Table 4-1 CLI Commands for Configuring Multicast Mode
Command
|
Multicast Mode
|
config network multicast global
{enable | disable}
|
Enables or disables multicasting.
|
config network multicast mode unicast
|
Configures the controller to use the unicast method to send multicast packets.
|
config network multicast mode multicast multicast-group-ip-address
|
Configures the controller to use the multicast method to send multicast packets to an LWAPP multicast group.
|
You can also enable multicast mode on the Configure > Switch IP System General page on the WCS interface.
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.
Configuring Client Roaming
The Cisco UWN Solution supports seamless client roaming across lightweight access points managed by the same controller, between controllers in the same mobility group on the same subnet, and across controllers in the same mobility group on different subnets. Also, in controller software release 4.1, client roaming with multicast packets is supported.
High-speed roaming of CCXv4-compliant clients at speeds up to 70 mph is supported in outdoor mesh deployments. An example application might be maintaining communication with a terminal in an emergency vehicle as it moves within a mesh public network.
You can adjust the default RF settings (RSSI, hysteresis, scan threshold, and transition time) to fine-tune the operation of client roaming using the controller GUI or CLI.
Intra-Controller Roaming
Each controller supports same-controller client roaming across access points managed by the same controller. This roaming is transparent to the client as the session is sustained, and the client continues using the same DHCP-assigned or client-assigned IP address. The controller provides DHCP functionality with a relay function. Same-controller roaming is supported in single-controller deployments and in multiple-controller deployments.
Inter-Controller Roaming
Multiple-controller deployments support client roaming across access points managed by controllers in the same mobility group and on the same subnet. This roaming is also transparent to the client because the session is sustained and a tunnel between controllers allows the client to continue using the same DHCP- or client-assigned IP address as long as the session remains active. The tunnel is torn down, and the client must reauthenticate when the client sends a DHCP Discover with a 0.0.0.0 client IP address or a 169.254.*.* client auto-IP address or when the operator-set session timeout is exceeded.
Note Cisco 1030 remote edge lightweight access points at a remote location must be on the same subnet to support roaming.
Inter-Subnet Roaming
Multiple-controller deployments support client roaming across access points managed by controllers in the same mobility group on different subnets. This roaming is transparent to the client because the session is sustained and a tunnel between the controllers allows the client to continue using the same DHCP-assigned or client-assigned IP address as long as the session remains active. The tunnel is torn down, and the client must reauthenticate when the client sends a DHCP Discover with a 0.0.0.0 client IP address or a 169.254.*.* client auto-IP address or when the operator-set user timeout is exceeded.
Note Cisco 1030 remote edge lightweight access points at a remote location must be on the same subnet to support roaming.
Voice-over-IP Telephone Roaming
802.11 voice-over-IP (VoIP) telephones actively seek out associations with the strongest RF signal to ensure the best quality of service (QoS) and the maximum throughput. The minimum VoIP telephone requirement of 20-millisecond or shorter latency time for the roaming handover is easily met by the Cisco UWN Solution, which has an average handover latency of 5 or fewer milliseconds when open authentication is used. This short latency period is controlled by controllers rather than allowing independent access points to negotiate roaming handovers.
The Cisco UWN Solution supports 802.11 VoIP telephone roaming across lightweight access points managed by controllers on different subnets, as long as the controllers are in the same mobility group. This roaming is transparent to the VoIP telephone because the session is sustained and a tunnel between controllers allows the VoIP telephone to continue using the same DHCP-assigned IP address as long as the session remains active. The tunnel is torn down, and the VoIP client must reauthenticate when the VoIP telephone sends a DHCP Discover with a 0.0.0.0 VoIP telephone IP address or a 169.254.*.* VoIP telephone auto-IP address or when the operator-set user timeout is exceeded.
CCX Layer 2 Client Roaming
Controller software release 4.1 supports five CCX Layer 2 client roaming enhancements:
•Access point assisted roaming—This feature helps clients save scanning time. When a CCXv2 client associates to an access point, it sends an information packet to the new access point listing the characteristics of its previous access point. Roaming time decreases when the client recognizes and uses an access point list built by compiling all previous access points to which each client was associated and sent (unicast) to the client immediately after association. The access point list contains the channels, BSSIDs of neighbor access points that support the client's current SSID(s), and time elapsed since disassociation.
• Enhanced neighbor list—This feature focuses on improving a CCXv4 client's roam experience and network edge performance, especially when servicing voice applications. The access point provides its associated client information about its neighbors using a neighbor-list update unicast message.
•
