-
User Guide for the CiscoWorks WLSE and WLSE Express, 2.11
-
Index
-
Preface
-
Getting Started
-
Using the Wizard for WDS Deployment
-
Fault Monitoring
-
Managing Devices
-
Using IOS Templates
-
Using Non-IOS Templates
-
Using WLSM Templates
-
Using Wizard Templates
-
Managing Device Configuration
-
Managing Device Firmware
-
Using Reports
-
Configuring the WLAN Radio Environment
-
Using the Radio Manager
-
Managing Your WLAN Radio Environment by Sites
-
Using the Intrusion Detection System
-
Managing the WLSE System
-
Managing the WLSE System via the CLI
-
Using the Internal AAA Server
-
Using the CLI
-
Naming Guidelines
-
Glossary
-
Table Of Contents
Viewing Status of Installed Software
Installing the Software Upgrade
Viewing Software Update History
Data Preserved or Changed After Upgrade
Overview: Authentication Modules
Using an Authentication Module
Enabling Telnet and Selecting SSH Type
Viewing the Last 10 Logged-On Users
Specifying the Backup Location
Configuring a Windows System as a Backup Location
Clearing the Backup/Restore Log
Scheduling and Running Backups
Copying Configuration Data from One WLSE to Another
Managing WLSE Master Configuration Files (WLSE Express Only)
About the Master Configuration Files
Performing Manual Failover to the Standby Node
Upgrading Software on Redundant WLSEs
Backing Up and Restoring on Redundant WLSEs
Changing the Web Timeout Period on Redundant Nodes
Controlling Access via HTTP/HTTPS on Redundant Nodes
Using WLSE Diagnostics Options
Viewing and Creating a Status Report
Viewing and Creating a Self-Test Report
Specifying a Splash Screen Message
Setting Time, Time Servers, Name Servers, and Web Session Timeout
Set the Current Local and UTC Time
Managing Files for the WLSE TFTP Server (WLSE Express Only)
Managing Firmware Version Support
Updating Supported AP Firmware Versions
Viewing Supported AP Firmware Versions
Adding, Modifying, and Deleting Roles
Changing the Default Tab and Subtab
Creating a Link to Another System
Configuring the ACS Failed Login Report Link
Running the ACS Failed Login Report
Managing the WLSE System
This chapter contains the following major topics:
•
Managing Firmware Version Support
Note
Ports Used by the WLSE
Table 16-1 and Table 16-2 list the ports used by WLSE services.
Note
Overview of the Admin Tab
Table 16-3 describes the subtabs and options that are displayed under the Admin tab.
Managing the Appliance
Options under the Appliance subtab allow you to manage the WLSE system and use connectivity tools. When you select Administration > Appliance, the following options are displayed.
Note
Table 16-4 Appliance Subtab Options
Status
Use WLSE log files. Restart the WLSE.
Software
Manage WLSE system software.
Security
Manage WLSE security:
•
•
•
•
Backup and Restore
Back up and restore WLSE data.
Master Configuration
Export WLSE configuration to a file. Used on the WLSE Express only.
Managing WLSE Master Configuration Files (WLSE Express Only)
Redundancy
Manage redundant WLSEs. Two WLSEs are managed as a high-availability cluster.
Diagnostics
Use WLSE status reports. Create and display self tests. Manage processes.
Splash Screen
Add a message to users at login.
Time/NTP/Name/
Web TimeoutSet system time, use NTP, specify name servers, and reset the Web timeout period.
Setting Time, Time Servers, Name Servers, and Web Session Timeout
Configure Mailroute
Specify a mail server for email forwarding.
TFTP Management
Manage files on the WLSE by using the internal TFTP server.
Connectivity Tools
Test network connectivity.
Using WLSE Log Files
This option allows you to view the contents of WLSE log files, download logs, search for data in logs, and email logs.
Note
Procedure
Step 1
Step 2
•
Note
•
Note
Step 3
Note
Step 4
Step 5
Related Topics
Viewing System Information via CLI
About Log Files
The WLSE maintains the following log files:
•
•
Table 16-5 General WLSE Log Files
AAA log files
Logs for the internal AAA server. The internal AAA server is available only on the Wireless LAN Solution Engine Express (WLSE 1030 hardware). For information on these log files, see Using AAA Server Log Files.
Repository.log
Actions performed by the repository web server.
access.log
Web server user access.
backup.log
Appears after you back up WLSE data, restore data, or test the reachability of the backup location. To clear this log, which can become very large, see Clearing the Backup/Restore Log.
ciscoinstall.log
Information on upgrades of the WLSE software.
configbackup.log
The WLSE backs up the startup configuration once a day in order to detect any configuration changes. This log file contains information for that backup process. Information is kept for only the latest backup.
configexport.log
Information generated when a master configuration file is generated (WLSE Express only).
cwexport.log
Information about device exports to CiscoWorks RME.
daemons.log
Messages that dmgtd does not log.
dataUpdate.log
Appears after WLSE software is updated.
db2.log
Database startups due to installations or reboots.
db2runstat.last.log
Information on the latest run of the runstats facility, specifically size information on all the database tables and which tables were updated.
db2runstat.times.log
Summary of recent runs of the runstats facility, specifically which tables were updated and how long it took for the entire run to finish.
db2uext2.log
Generated by the database user exit script, which is part of the redundancy code. This file is for troubleshooting by TAC only.
device_events.log
Logs for the following device events detected by the WLSE:
•
•
•
dhcp.log
Processing that occurs when a WLSE boots up and gets its startup configuration tar file from a TFTP server via DHCP.
diagnostic-info.log
Output of the diagnostic-info CLI command.
dmgtd.log
Process management daemon log.
dumptcp.cap
Binary log file created by the dumptcp CLI command. To view this file, save it to the desktop. Then, use a utility such as tcpdump.
dumptech.tgz
Output of the dumptech CLI command. To view this file, save it to the desktop and unzip the file.
error.log
Web server errors.
faults.log
Device faults.
install.log
Software package installation.
jobvm.log
Errors and other information on scheduled jobs.
logs.tgz
Output of the tarlog CLI command (an archive of system logs). To view these logs, save this file to the desktop, then unzip the file.
mfgtest.log
Manufacturing tests.
mod_jk.log
Messages between Tomcat and Apache.
procps_last.log
Output from last running of the ps CLI command.
redundancy.log
Redundancy messages.
runstats.log
Output of utility that updates statistics on data in tables and indexes.
snmpd.log
SNMP agent log file.
ssl_request.log
Secure HTTPS socket layer web server events.
swan.log
Radio management log.
tftp.log
Access points deployed by the Deployment Wizard (access points that have downloaded the wlsestartup.ini file).
tomcat.log
Java servlet messages, including review and error information for configuration templates.
updateWLSE-x.x.log
Results of upgrading WLSE software; for example, update WLSE-2.11.log.
var_logs.tgz
Output of the tarlog CLI command (an archive of system logs). To view these logs, save this file to the desktop, then unzip the file.
Restarting the WLSE
This option allows you to restart the WLSE. After restarting, discovery and inventory will resume at the next scheduled time.
Note
Procedure
Step 1
Step 2
Note
Related Topics
•
•
Managing WLSE System Software
Caution
Caution
Caution
For information on which previous versions of WLSE software can be upgraded to WLSE 2.11, see the Software Upgrade Guide for the CiscoWorks Wireless LAN Solution Engine on Cisco.com at http://www.cisco.com/univercd/cc/td/doc/product/rtrmgmt/cwparent/cw_1105/wlse/2_11/index.htm.
The options under Admin > Appliance > Software are:
•
•
•
•
•
The topics in this section are:
•
•
•
•
For information on other upgrade methods, see the Software Upgrade Guide for the CiscoWorks Wireless LAN Solution Engine on Cisco.com.
Viewing Status of Installed Software
You can view information about the software currently installed on the WLSE.
Note
Procedure
Step 1
Software Name
Brief description of the software.
Installation Date
Date and time (UTC) the software was installed.
Status
Status of the installation:
Success—Installed with no errors.
Warning—Installed successfully with minor errors.
Error—Installation was unsuccessful.
Details
Detailed install log for this software.
Last Installation Information shows the following information about the most recent software installation:
Step 2
Result: The install log for the selected installation opens, showing information about the most recent software installation.
Related Topics
•
•
•
Managing the Repository
The software repository stores the available software updates for the WLSE. The repository can be either local (on the WLSE) or remote (on a Windows NT, Windows 2000, or Windows XP server). The tasks for managing the repository are:
Downloading the Upgrade Image
To locate the upgrade files, navigate to the Software Center for WLSE on Cisco.com or use the following URL:
http://www.cisco.com/pcgi-bin/tablebuild.pl/wlan-sol-eng
Note
Download the relevant upgrade files:
•
•
Creating the Repository
Adding files to the repository and deleting files from the repository require the use of CLI commands. For more information on CLI commands, see "Command Line Interface (CLI) Commands."
The topics in this section are:
•
Creating a Local Repository
To create a local repository on the WLSE:
Note
Procedure
Step 1
Step 2
repository source ftp://hostname/pathwhere hostname is the name of the remote FTP server and path is the directory path on the remote FTP where you placed the zip file and info file.
Step 3
repository list remoteStep 4
repository add packageFor example, if the name of the zip file is WLSE-2.7-K9.zip, the package is WLSE-2.7-K9.
Creating a Repository on a Windows Server
A remote repository can serve as the repository for numerous WLSEs. You can create a repository on a Windows NT, Windows 2000, or Windows XP server.
Note
Use the following procedure to set up a Windows NT, Windows 2000, or Windows XP server as a remote repository.
Procedure
Step 1
a.
b.
Note
Step 2
Step 3
subst f: d:\WLSE_repository
Note
Step 4
The Appliance Update screen appears in a browser.
Defining the Repository
By defining the repository, you are telling the WLSE where to look for available software updates.
Note
Procedure
Step 1
Step 2
Step 3
Step 4
Related Topics
•
•
Installing the Software Upgrade
Caution
Before upgrading WLSE software, check the readme file that accompanies the image in the Software Center on Cisco.com for possible changes to the procedure, caveats, and new features.
Upgrading on a redundant cluster requires special procedures. Before upgrading software on a redundant cluster of WLSEs, see Upgrading Software on Redundant WLSEs.
When you update or reinstall software, the WLSE stops and restarts. Therefore, you cannot access the WLSE during a software update, and you must log in again after updating software.
Note
Procedure
Step 1
Step 2
Step 3
These tables display the following information about the software you can install.
Name
Software identifier.
Version
Version number.
Summary
Brief description.
Release Date
Release date.
Details
Detailed description.
Step 4
Step 5
Step 6
Step 7
Step 8
If the Appliance Update window reappears, click the Cancel button to remove it.
Step 9
Related Topics
•
•
•
Browsing the Repository
You can browse the available complete images and software upgrades on the repository using this option.
Note
Note
Procedure
Step 1
Step 2
Related Topics
•
•
Viewing Software Update History
This window shows only the update history, not a history of installed images. When you install a complete new image, the previous update history is erased.
Note
Procedure
Step 1
Table 16-6 Software Update History Window
Name
Software identifier.
Version
Software version.
Summary
Summary of the installed software.
Install Date
Date and time (UTC) the software was installed.
Status
Status of the installed software.
Status
The status of the installation:
Success—Software was installed with no errors.
Warning—Software installed successfully with minor errors.
Error—Software installation was unsuccessful.
Details
The detailed install log for this installation, including warning and error messages.
Step 2
Related Topics
•
•
Viewing Software Update Logs
The WLSE maintains the following software update logs:
•
•
To view these logs, select Admin > Appliance > Status > View Log File. These logs are not listed until you have performed an update of WLSE software.
Data Preserved or Changed After Upgrade
For information on data that is not preserved or data that is changed after upgrading to WLSE 2.11, see the Software Upgrade Guide for the CiscoWorks Wireless LAN Solution Engine on Cisco.com.
Managing Security
You can manage the WLSE's by using the options under Admin > Appliance > Security:
•
•
•
•
Related Topics
Overview: Security
The WLSE provides the following security features:
•
•
•
•
Overview: Authentication Modules
The WLSE provides a mechanism for authenticating users through the local authentication module and a local database of user IDs and passwords. Many network managers, however, already have an authentication service. To use your own authentication service instead of the local module, you can select one of the alternative modules:
•
•
•
After you select and configure a module, all authentication transactions are performed by the authentication service associated with that module. Users log in with the user ID and password associated with the current authentication module.
The WLSE determines user roles; therefore, all users must be in the local database of user IDs and passwords. A user's role determines the services and devices that the user can access. Users must have the same user ID locally as they have in the alternative authentication source, but the local password and authentication service password do not have to be same.
Users who are authenticated by an alternative service and who are not in the local database have no roles assigned to them. Users who have no roles see only the splash screen after logging in and cannot view screens or perform tasks.
If the alternative authentication service fails, the WLSE defaults to the Local authentication module. Even if the local user database fails, you can always log in as the admin user.
Related Topics
•
Using an Authentication Module
You can use your existing authentication method to authenticate WLSE users by selecting and configuring one of the WLSE's login modules.
To configure an authentication module for users logging in to the CLI via Telnet or SSH, use the auth CLI command.
After you change the authentication module, you do not have to restart the WLSE. Changing the module does not affect users who are currently logged on. Users who log on after the change use the new module.
Note
Note
Procedure
Step 1
Step 2
Step 3
Step 4
Table 16-7 Authentication Modules
Local
Use local authentication only. This is the default setting. No configuration required.
Primary Server and Secondary Server—IP addresses or device names of the primary and secondary authentication servers. A secondary server is optional.
Shared Secret—Secret key.
Primary Server and Secondary Server—IP addresses or device names of the primary and secondary authentication servers. A secondary server is optional.
Shared Secret—Secret key.
Note
MS NT Domain
Domain—Name of the Windows domain.
Primary Domain Controller and Backup Domain Controller—Names of the primary and backup Windows domain controllers. A backup domain controller is optional.
When entering the primary domain controller:
•
•
Step 5
Related Topics
•
•
Managing SSL (HTTPS)
SSL (secure socket layer) protocol provides a secure connection between Web clients and the WLSE. When you initially set up the WLSE, normally, an unsigned certificate and a CSR (Certificate Signed Request) are automatically generated and SSL is enabled. The unsigned certificate expires in one year. To obtain a permanent, signed certificate, use the following procedure.
Note
Note
Procedure
Step 1
Step 2
Step 3
Step 4
a.
b.
c.
d.
Step 5
a.
b.
# firewall eth0 1741Step 6
Enabling Telnet and Selecting SSH Type
Telnet can be used for connecting to the WLSE through the CLI. By default, Telnet is disabled, which prevents unsecure connections through the CLI.
SSH is enabled by default. SSH provides a secure Telnet connection, encrypting all traffic, including passwords. By default, both SSH1 and SSH2 are used.
Note
Procedure
Step 1
Step 2
Step 3
Changes occur immediately.
Viewing the Last 10 Logged-On Users
To view information about the last 10 users who have logged on to the WLSE:
Note
Procedure
Step 1
The Last 10 Logins table shows the following information for the last 10 logins:
Login Name
User's login name.
Logged In Since
Date and time the user logged in (UTC).
IP Address
IP address of the system from which the user logged in.
Associated role
Role assigned to the user.
Backing Up and Restoring Data
Backup and restore allows you to backup the WLSE's configuration and restore it if necessary.
Caution
The following options are provided for backup and restore:
•
•
•
•
Related Topics
•
About Backup and Restore
Backing up the WLSE saves its configuration data in case you need to restore the data. The backup operation backs up the entire WLSE database and configuration, which includes appliance setup, fault and performance data, device credentials, WLSE users, configuration templates, user-created groups, and jobs.
Backups are typically done on a regular basis (for example, weekly). However, you may choose to back up infrequently and use one or more of the data export mechanisms to gather interesting data from the WLSE.
The backup operation may take some time depending on the size of the database: the larger the database, the more the backup time will be required.
The restore operation includes all the information in the backup, including the information entered during initial configuration of the WLSE (setup program).
The restore process disrupts normal WLSE operation because the process shuts down the WLSE internal database and then restarts it.
You can restore data backed up on one WLSE to another WLSE. For information on restoring from one WLSE to another, see Copying Configuration Data from One WLSE to Another.
Specifying the Backup Location
You must set the backup location before you can run backups. The backup location must be an FTP server because the WLSE uses FTP to transfer the data.
Please observe the following cautions about the backup location:
•
•
•
Note
Procedure
Step 1
Step 2
Step 3
Step 4
The message "Test OK" should be displayed. Any other response indicates a problem with the backup.
Step 5
Related Topics
•
•
•
Configuring a Windows System as a Backup Location
You can use a Windows 2000 Server, Advanced Server, or Windows XP Professional system as a backup location. Before use, the system be configured as follows.
Note
Procedure
Step 1
If this option is not available on the server, first enable it as follows:
a.
b.
c.
Step 2
Step 3
Step 4
•
•
•
Clearing the Backup/Restore Log
To remove the backup.log file from the View Log File window, select Admin > Appliance > Backup and Restore > Configure. Then, click Clear Log. This removes from the View Log File window the file created by the last backup or restore operation. This log file is called backup.log.
Scheduling and Running Backups
Data backed up includes role and user information, discovery configuration information, and other configuration information. The following procedure includes a verification step; it is recommended that you always verify that the backup succeeded. You can run an immediate backup or schedule regular backups.
Before scheduling backups, verify that the system time is set correctly. To set the system time, see Set the Current Local and UTC Time.
Note
Note
Note
Procedure
Step 1
Step 2
Step 3
Step 4
a.
–
–
–
b.
Step 5
Step 6
•
•
•
Related Topics
•
Restoring Data
Caution
After you click Restore and OK in the following procedure, the following occur in sequence:
1.
2.
3.
Note
Procedure
To restore the WLSE's configuration data from a backup:
Step 1
Step 2
Step 3
•
•
Caution
Step 4
Step 5
Result: The WLSE shuts down, the data is restored, then the WLSE restarts.
Related Topics
•
•
•
Copying Configuration Data from One WLSE to Another
You can back up data from one WLSE and copy it to another by using the backup and restore features. If you are replacing one WLSE with another, see the instructions in Installing a Replacement WLSE.
Step 1
Step 2
For information on the setup program and initial configuration, see relevant installation guide for your WLSE hardware.
Step 3
Caution
For more information on restoring backups, see Restoring Data.
Related Topics
Copying Configuration Data to another WLSE via CLI
Managing WLSE Master Configuration Files (WLSE Express Only)
Using this option, you can create master configuration files that contain the current basic configuration data of a WLSE Express and use these files to configure other WLSEs.
For details on the content of the master configuration files, see About the Master Configuration Files.
Use the following procedure to create WLSE configuration files and download them from the WLSE to a TFTP server.
For details on the contents of the configuration files, editing the .xml file, parameters that can be saved, and procedures for using the master configuration to configure other WLSEs, see the Installation and Configuration Guide for the CiscoWorks Wireless LAN Solution Engine Express, Release 2.11.
Note
Procedure
Step 1
a.
b.
c.
d.
Result: The types of data you can include in the configuration files are displayed.
e.
f.
Results: The .xml, .info, and .dat files are created and combined into a tar archive and stored on the WLSE. The name of the archive and the date it was created are added to the Saved Configurations list.
Table 16-8 Data Saved in the Master Configuration Files 1
Faults
Default fault profile settings
X
Notification settings
X
Discover
Discovery schedule, including seed devices and CDP distance setting
X
Device credentials
X
Advanced options (auto-manage, DNS lookup, and name format)
X
Inventory polling parameters
X
AAA server monitoring
X
Client tracking enable
X
Rule Based Groups
User-defined rule-based groups
X
Configure
Templates2
X
X
Startup configuration assignments
X
Auto-managed template assignments
X
Administration
Appliance Settings (redundancy, splash screen)
X
User role definitions
X
Users
X
Radio Management
AP locations
X
Radio management configuration
X
1 For parameters that cannot be saved from the UI, you can add CLI commands to the .xml file. For example, settings for the internal AAA server are not saved from the UI.
2 Any custom commands in templates are saved to the .xml file. Template settings made from the UI are saved in the .dat file.
Step 2
a.
b.
c.
Step 3
Related Topics
About the Master Configuration Files
About the Master Configuration Files
When you use the Master Configuration option, 3 files are created and combined into a tar archive. For example, if you specify the filename "config," a tar archive called myconfig.tar is created. The archive contains the following files:
•
The following parameters must be manually added to the .xml file as CLI commands:
–
–
You can also add other WLSE CLI commands to the .xml file.
For information on editing the .xml file, see the Installation and Configuration Guide for the CiscoWorks Wireless LAN Solution Engine Express, Release 2.11.
•
•
Configuration files can be automatically downloaded to WLSEs by storing the file on a TFTP server and using DHCP to download the file. For more information on this method of configuring WLSEs, see the Installation and Configuration Guide for the CiscoWorks Wireless LAN Solution Engine Express, Release 2.11. For help in locating this guide on Cisco.com, see Finding WLSE Documentation on Cisco.com.
Managing WLSE Redundancy
The redundancy feature allows you to enable high availability through a two-node cluster of WLSEs. If the WLSE designated as the primary node fails, fail-over occurs automatically to the secondary node. If, subsequently, the primary node is back in service and the secondary node fails, failback occurs to the primary node.
Configurable periodic synchronizations between primary and secondary nodes ensure that any data or configuration loss is minimal. During failover, all users are logged out and must log back in.
Tip
Before enabling redundancy, see Redundancy Prerequisites for hardware and configuration prerequisites.
For details on how redundancy works, see About Redundancy.
You can use the redundancy options to:
•
•
•
Related Topics
•
•
•
•
•
Redundancy Prerequisites
Following are the requirements for WLSE redundancy:
•
•
•
•
•
•
•
•
•
About Redundancy
Redundancy is achieved by configuring a cluster of two WLSEs. One WLSE is in active mode, performing all normal WLSE functions. The other WLSE is in warm standby; that is, the system is up but no WLSE applications are running and only certain diagnostic operations are allowed.
The user interface on the standby node is restricted. The only features displayed are the Admin tab and the Appliance subtab. This prevents users from accidentally using the standby node for other operations.
For more information, see the following topics:
•
Redundancy Configuration
Redundancy can only be configured in the Web interface. However, after you have configured it, you can turn it on or off by using the redundancy CLI command.
All redundancy configuration is performed on the primary node, which becomes the active WLSE after you set up redundancy. This configuration, plus all other data, is copied to the secondary node (the standby WLSE) automatically. Periodically, incremental changes are applied to the standby to keep it synchronized with the active node. To make sure the active node is running normally, the standby node periodically checks the active node; and the active node periodically checks the standby node.
Status Checking
Under redundancy, the nodes synchronize with each other, the standby node checks the active node, and the active node checks itself.
Synchronization and checking intervals are configurable by the administrator. The minimum amount of time between data synchronizations is 20 minutes, and the maximum amount of time is 5 hours. The frequency of checks made by the standby node can be set to between 15 seconds and 5 minutes.
A second type of check is done by the active node, which periodically makes the following system checks on itself:
•
•
•
If any of these system checks fail repeatedly on the active node, data will be synchronized with the standby node. Then the standby will become active and the original active node will reboot. This failover will not occur if the active node cannot reach the standby node. In that case, the active node will remain up and running until the standby comes back online.
Failover
If the active node goes down or experiences a transient failure, all users are logged out and must log back in. No matter which node is active, users always log in to the same IP address, called the virtual IP.
When the formerly active node comes back into service, it automatically becomes the standby node. If both WLSEs go down, the current active node may become the standby node if the standby node restarts first.
In case of failover, a small amount of data that has not been committed to the standby will be lost. The amount of potential data loss is limited to the data accumulated during the interval between synchronization of the two nodes. It will take a few minutes for the standby node to become active after it detects that the other node has failed.
Messages
Redundancy troubleshooting messages are logged to the tomcat.log file. To troubleshoot a node, log in using the real IP address, not the virtual IP address.
Changes in Certain Functions under Redundancy
Certain WLSE functions require special treatment on a redundant cluster. See the following:
•
•
•
•
Related Topics
•
Redundancy Email Messages
The messages sent by the redundancy module are described in Table 16-9. The sender of all messages is WLSE@ip_address, where ip_address is the IP address of the WLSE that is sending the message.
These messages are logged in the redundancy.log file. For information on viewing this and other WLSE logs, see Using WLSE Log Files.
Related Topics
•
•
•
Configuring Redundancy
Initial redundancy configuration is performed on the currently active WLSE. Initial configuration is done on whichever WLSE is to be designated as primary.
Subsequent configuration changes can be done on whichever WLSE is in active mode, but the node IP addresses should remain the same as when they were initially configured. If you need to change the node IP addresses, first turn redundancy off, then configure the node IP addresses.
Caution
Note
Procedure
Step 1
Step 2
Step 3
Step 4
After redundancy is turned on, a backup and restore begins.
Step 5
Table 16-10 Redundancy Parameters
Redundancy Enabled
Select to enable redundancy. Deselect to disable redundancy. When this is selected, the other fields in the screen become active.
Admin Password
The admin password on both the active and standby systems. The password must be identical on both systems.
Notification Email
Email address for notification of redundancy events. For information on these notifications, see Redundancy Email Messages. For information on configuring email in general, see Configuring the Mail Route
HTTP Port
Port to use for client connections via HTTP. The default is 1741. The port must be the same on both systems. For information on setting the port, see the http-server port CLI command in "Command Line Interface (CLI) Commands."
VIP IP eth0
Unique IP addresses for the WLSE's Ethernet interfaces. The virtual IP is the address for all accesses to the redundant pair, including logins to the WLSE.
•
•
The VIP is a static (non-DHCP) address that must be officially allocated by the site's network administrator. The VIP must be in the same subnet as the interface. That is, VIP eth0 must be in the same subnet as eth0 and VIP eth1 must be in the same subnet as eth1.
The VIP address is always assigned to the active WLSE. All accesses to the redundant pair are done by using the VIP address. Thus, if a failover occurs, the active WLSE always responds when addressed by the VIP.
VIP IP eth1
This Node IP1
Static IP address of the current (active) node. If both Ethernet interfaces are configured, you can select the address/interface for redundancy communication.
Other Node IP1
Static IP address of the system that will become the standby node.
Minutes between sync
How often the active and standby WLSEs are synchronized. Synchronization consists of incrementally backing up the database on the active WLSE and restoring on the standby WLSE. Default is 60 minutes. Can be set between 15 minutes and 5 hours. On networks with more than 500 devices, it is not recommended that you set this to less than 30 minutes.
Seconds between check of other node
How often to check to make sure both nodes are functioning. Default is 60 seconds. Can be set between 15 seconds and 5 minutes.
Seconds between check of system
How often to check the status of the database and the process daemon manager on the active node.
1 To change a node's IP address, first turn off redundancy, then configure the IP addresses, then turn on redundancy.
Step 6
Step 7
•
•
–
–
Related Topics
•
•
•
•
Checking Redundancy Settings
Note
Procedure
Step 1
Step 2
Step 3
Table 16-11 Redundancy Settings
Redundancy Status
Active—Redundancy is enabled. This is the active node at the current time.
Standby—Redundancy is enabled. This is the standby node at the current time.
Not Configured—Redundancy is not enabled.
HTTP Port
HTTP port configured on both systems.
Notification Email
Email address to which notifications are sent.
Virtual IP eth0
Virtual IP address of Ethernet interface 0.
Virtual IP address of Ethernet interface 1 (if in use).
For more information on virtual IPs, see Table 16-10.
Virtual IP eth1
This Node IP
Static IP address of the current system.
Other Node IP
Static IP address of the other system.
Minutes between sync
Synchronization interval (data copied from the active node to the standby node).
Seconds between check of primary
How often the standby system checks the active system to find out if the primary system is functioning.
Related Topics
•
•
•
•
Viewing the Redundancy Log
The event log contains a listing of all significant redundancy events since the WLSE was started.
Note
Procedure
Select Admin > Appliance > Redundancy > Event Log.
The redundancy log is displayed; for example:
02:24:13 02/13/2004 Lost connectivity with standby on 192.161.98.5302:24:13 02/13/2004 Regained connectivity with standby on 192.161.98.5302:24:13 02/13/2004 Redundancy active mode02:24:13 02/13/2004 Shipped file S0000147.LOG02:24:12 02/13/2004 Shipped file wlse-configs.tgzRelated Topics
Performing Manual Failover to the Standby Node
If you reboot the active node or stop services on it (preferred method), the standby node will automatically become active.
To reboot a WLSE, see Restarting the WLSE.
To stop services on a WLSE, Telnet or SSH to the WLSE and enter the following CLI command:
services stopTo restart services, enter the following CLI command:
services startOnce restarted, the formerly active node will automatically become the standby node.
Related Topics
Upgrading Software on Redundant WLSEs
Both the active and standby node must run the same software release. For information on upgrading software in a redundant cluster, see Upgrading the CiscoWorks Wireless LAN Solution Engine, 2.11 on Cisco.com at http://www.cisco.com/univercd/cc/td/doc/product/rtrmgmt/cwparent/cw_1105/wlse/2_11/index.htm.
TReplacing a Node
If you need to replace a node:
•
•
•
See Configuring Redundancy for information on turning redundancy on and off.
Related Topics
Backing Up and Restoring on Redundant WLSEs
This section contains the following information:
•
•
About Backup and Restore on Redundant Nodes
When backing up and restoring on redundant nodes:
•
•
•
•
Restoring on Redundant Nodes
When restoring data from a previous backup on WLSEs that have been configured for redundancy, use the following procedure.
Procedure
Step 1
Step 2
Step 3
Related Topics
Changing the Web Timeout Period on Redundant Nodes
If WLSE redundancy is in effect, you should stop and restart services on the standby WLSE. Otherwise, resetting the timeout will cause a switchover from the active server to the standby server and the new timeout period will not take effect.
Procedure
Step 1
Step 2
services stopStep 3
Step 4
services start
Controlling Access via HTTP/HTTPS on Redundant Nodes
If you are implementing HTTP/HTTPS access control by using the http-server accept CLI command, you must add each server to the other server's access list.
Assuming that the redundant WLSEs have IP addresses 209.165.202.100 and 209.165.202.200, enter the following CLI command on the WLSE with IP address 209.165.202.100:
http-server accept 209.165.202.200Enter the following CLI command on the WLSE with IP address 209.165.202.200:
http-server accept 209.165.202.100Using WLSE Diagnostics Options
The Diagnostics option provides tools to aid in troubleshooting. You can use these tools when you have a problem that might require assistance from the Cisco Technical Assistance Center (TAC).
The options under Admin > Appliance > Diagnostics are:
•
•
•
Viewing and Creating a Status Report
This option provides a tool to aid in troubleshooting. The WLSE information and status report shows general WLSE status, log files, package information, database status, process status, web server information, Java class information, and log files.
Note
Note
Procedure
Step 1
Step 2
Step 3
Step 4
Related Topics
•
Viewing and Creating a Self-Test Report
This option provides a tool to aid in troubleshooting. Self-tests show the status of WLSE memory, database, DNS setup, and backup location configuration. Reports indicate whether the tests passed or failed. Self-tests are used mainly by the TAC when diagnosing problems.
Note
Note
Procedure
Step 1
Step 2
Step 3
Step 4
Step 5
Related Topics
•
Managing Processes
This option provides a tool to aid in troubleshooting. You can view the status of the major processes running on the WLSE, start and stop processes, and access complete reports.
Note
Procedure
Step 1
Process name
How a process is registered. For information on the processes displayed, see Processes Displayed.
State
Process status and a summary of the log file entries for the process.
Pid
Process ID. A unique number by which the operating system identifies each running program.
RC
Return code. "0" means normal program operation. Any other number typically represents an error. Refer to the error log.
Signo
Signal number. "0" means normal program operation. Any other number is the last signal delivered to the program before it terminated.
Start Time
Time (UTC) and date the process was started.
Stop Time
Time (UTC) and date the process was stopped.
Core
"Not applicable" means the program is running normally.
"Core file created" means the program is not running normally and the operating system has created a core file. The core file stores important data about processes.
Information
What the process is doing. "Not applicable" means the program is not running normally.
Step 2
View details.
Click process name. See Daemon Information.
View process status.
Click process state. See Process Status.
Stop process.
Select process and click Stop. New status and other process information is displayed. The WebServer and Tomcat processes cannot be stopped.
Start process.
Select process and click Start. New status and other process information is displayed.
Update table with latest data.
Click Refresh. The table does not automatically update.
View all processes.
Click Complete Report. The system status is displayed.
Related Topics
Administering Management Services via CLI
Processes Displayed
The Process Report table displays the status of the following major WLSE processes:
WirelessSvcMgr
Process that manages internal radio management tasks.
WLSEjobvm
Job virtual machine.
WLSEFaults
Fault manager.
WebServer
Web server.
Tomcat
Java servlet engine.
Snmptrapd
Trap processes.
ExcepReporter
CDPbrdcast
CDP daemon that identifies Cisco devices to their immediate neighbors.
PerfMon
Process that monitors performance.
Daemon Information
The Daemon Information dialog box displays the following:
Process Status
The system log, which describes the status of the processes running in the system, displays the following:
Specifying a Splash Screen Message
The Splash Screen option allows you to set up a message that is displayed when a user logs in. After viewing the message, the user clicks Agree to continue logging in or Disagree to log out.
Note
Procedure
Step 1
Step 2
Step 3
Note
Setting Time, Time Servers, Name Servers, and Web Session Timeout
The Admin > Appliance > Time/NTP/NAME option allows you to:
•
Set the Current Local and UTC Time
Current local (browser) time appears in most WLSE displays. Universal Coordinated Time (UTC) is the system time and appears in log files.
To set the time that appears in the Web interface, use the following procedure. Because there is a single system clock, setting the time here also updates the UTC time.
Note
Procedure
Step 1
Step 2
Related Topics
Setting the System Clock Manually via CLI
Specify NTP Time Servers
This option allows you to maintain the current time on the WLSE by using NTP (Network Time Protocol) servers.
Note
Procedure
Step 1
Step 2
Step 3
Related Topics
Setting the System Clock Using NTP via CLI
Specify Name Servers
You can specify the addresses of up to three name servers for name and address resolution.
Note
Procedure
Step 1
Step 2
Step 3
Set the Web Timeout Period
The default timeout period for the Web interface is 30 minutes. If there is no input for 30 minutes, you will be logged out.
If WLSE redundancy is in effect, you should stop and restart services on the standby WLSE. Otherwise, resetting the timeout will cause a switchover from the active server to the standby server and the new timeout period will not take effect. For the procedure to reset the web timeout when using redundancy, see Changing the Web Timeout Period on Redundant Nodes.
Note
To reset the timeout period for the Web interface:
Procedure
Step 1
Step 2
a.
b.
Note
Step 3
Configuring the Mail Route
To ensure that WLSE email notifications reach their destinations, you can configure the WLSE's mail route by specifying an SMTP mail server. This setting affects emailing notifications about firmware and configuration jobs, emailing reports, and emailing fault notifications.
Note
Procedure
Step 1
Step 2
Step 3
Related Topics
Configuring the Mail Route via CLI
Managing Files for the WLSE TFTP Server (WLSE Express Only)
Note
You can manage files in the /tftpboot/public directory of the WLSE Express by using the TFTP Management option. For example, you can download images for routers, switches, and other devices in the network and load the images on the devices. The space available in this directory for managing files is 1 gigabyte.
The root directory for the TFTP server is /tftpboot. However, when sending files to the WLSE TFTP server, use a pathname starting with /public (instead of /tftpboot/public).
The following file management operations are permitted:
•
•
•
Note
Procedure
Step 1
Step 2
a.
b.
Result: The file will be copied to the /tftpboot/public directory and listed in the file table. The file table includes information about the total amount of space that has been used and contains the following fields for each stored file:
Step 3
a.
b.
Result: An empty file will be created in the /tftpboot/public directory and listed in the file table.
Note
Step 4
a.
b.
c.
Step 5
a.
b.
Step 6
To deselect a file, click its checkbox in the file table. To deselect all files, click Deselect All.
Using Connectivity Tools
When you select Admin > Appliance > Connectivity Tools, the following options for testing device connectivity and reachability are displayed:
•
•
Using Network Tools
The Network Tools option offers several tools for testing device connectivity.
Note
Procedure
Step 1
Step 2
When you select an option button, the results window tells you whether the connectivity test was successful. Pressing Enter will not work. You must click a button.
Table 16-12 Connectivity Tools
Ping
Tests device reachability.
If successful, statistics are displayed on the packets transmitted and received.
Traceroute
Detects routing errors between the WLSE and a device.
If successful, the routes to the device are displayed.
NSLookup
Looks up hostname or IP address information via the name server.
If successful, displays the name server name and IP address and the device name and IP address.
TCP Port Scan
Finds the active ports on a device.
Displays the active ports.
SNMP Reachable
Tries to reach a device by using SNMP. To reach a device by using SNMP, the device's credentials must be in the WLSE database. To check credentials, select Devices > Discover > Device Credentials > SNMP Communities.
If the device is reachable, its sysObjID is displayed.
If no sysObjID is returned:
•
•
Step 3
Using the SNMP Query Tool
This tool allows you to find the value of a specified SNMP variable. Normally, this tool is used under the direction of Cisco TAC when they are assisting you with troubleshooting a problem.
Note
Procedure
Step 1
Step 2
Step 3
Step 4
Step 5
Managing Firmware Version Support
You can use the WLSE to upgrade and update the firmware on one or more access points, either as a scheduled operation or on demand. To accomplish this, information about supported firmware versions is stored on the WLSE. You can:
•
•
The topics covered in this section are:
•
•
Updating Supported AP Firmware Versions
To provide incremental support for minor updates to currently-supported IOS firmware versions, an incremental update package may be posted on Cisco.com. You can download this file and import it into the WLSE to update versions supported by the WLSE firmware module.
Note
Note
To import new firmware support information:
Procedure
Step 1
http://www.cisco.com/pcgi-bin/tablebuild.pl/wlan-sol-eng
The firmware version update file is listed along with the WLSE software update files.
Step 2
Step 3
Step 4
Step 5
Related Topics
Viewing Supported AP Firmware Versions
Viewing Supported AP Firmware Versions
Note
To display firmware versions currently supported by the WLSE:
Step 1
Step 2
Step 3
Related Topics
Updating Supported AP Firmware Versions
Managing GUI Users
The options displayed when you select Admin > User Admin allow you to manage user roles and logins:
•
•
Related Topics
Overview: Authentication Modules
Managing Roles
Use this option to add, modify, and delete user-defined roles and to modify predefined roles. A user's role determines the tabs and subtabs the user can access. Users who have access to a subtab can perform all of the tasks under the subtab.
This section contains the following topics:
•
•
Overview: Roles
A user's role determines the tabs and subtabs the user can access. Users who have access to a subtab can perform all of the tasks under the subtab.
The XML API privileges are for users who will be using the XML application programming interface (API). If you are using the API, you should create different users for this purpose, and grant such users access to the API only. Access to the API is authenticated and authorization is checked. For more information about the XML API, see the Developer Guide for the CiscoWorks Wireless LAN Solution Engine. This guide is included with the XML API SDK (Software Developer Kit) in the Software Center on Cisco.com.
Although you cannot delete predefined roles, you can modify them. The predefined roles and their default privileges are:
•
•
•
•
You can use these predefined roles to control which features staff members are allowed to access. Less skilled, front-line technical support can be assigned the Help Desk role. More skilled and experiences support staff might be given the Network Operator or Network Administrator roles. The most skilled and experienced staff with direct responsibility for the WLSE should be given the System Admin role.
You cannot modify the privileges of the System Admin role. A user who has the System Admin role can modify other user roles.
Adding, Modifying, and Deleting Roles
You can edit the predefined roles, or you can create new, user-defined roles. You can modify or delete any user-defined roles.
Note
Procedure
Step 1
•
•
•
Step 2
a.
b.
Note
c.
Step 3
Step 4
Related Topics
Managing User Accounts
Using the options under this tab, you can create new user accounts, modify existing users, and delete users. The topics in this section are:
Related Topics
•
Overview: User Accounts
Each new user must be assigned at least one role and assigned a privilege level for accessing the WLSE CLI. There are three possible privilege levels for the WLSE CLI:
•
•
•
The default user (admin) is created when the setup script is run. The admin user has the System Administrator role and level 15 CLI privileges. This user cannot be deleted.
User accounts that you add by using the CLI commands do not have Web interface privileges. You can modify such users in the Web interface and add the appropriate roles to give them access to the Web interface.
Except for the admin user and users with the System Admin role, only the logins created by you are displayed. If logins were created by another user, they are not visible; only their creator can display them. However, the admin user and any user with the System Administrator role can view all users, no matter who created them.
Add Users
Note
Procedure
Step 1
•
•
•
Step 2
Table 16-13 Adding Users
User Name
Name of the new user. Usernames can be up to 32 characters in length and are case-sensitive. Usernames must begin with a character and cannot begin with a number.
The username cannot contain a colon, semi-colon, single quote, double quote, or space.
Note
For more information on the allowable characters, see "Naming Guidelines."
User Password
Password for the new user.
Passwords are unlimited in length and are case sensitive. You can use any character except for the single quote or double quote.
Confirm Password
Email address of the user (optional).
CLI Access
User's level of access to the WLSE CLI: None, Level 0, or Level 15. Users with privilege level 15 can use all commands, and users with privilege level 0 can use a small subset of commands.1
Roles
One or more roles for the user. Roles determine the user's access to tabs and subtabs in the Web interface.
•
•
•
1 For information on CLI commands, see "Command Line Interface (CLI) Commands."
Step 3
Step 4
Step 5
Related Topics
Modify Users
Note
Procedure
To modify a user:
Step 1
Note
Step 2
Table 16-14 Modifying Users
User Name
User's name. Usernames can be up to 32 characters in length and are case-sensitive. Usernames must begin with a character and cannot begin with a number.
Usernames cannot contain a colon, semi-colon, single quote, double quote, or space.
Note
For information on the allowable characters, see "Naming Guidelines."
User Password
New password for user.
Passwords are unlimited in length and are case sensitive. You can use any character except for the single quote or double quote.
Confirm Password
Enter or change the user's email address.
CLI Access
User's access to the WLSE CLI: None, Level 0, or Level 15.
By default, Level 15 is selected for the System Administrator role, and None is selected for others.
Users with privilege level 15 can use all commands, and users with privilege level 0 can use a subset.
For information on commands that are available for each privilege level, see "Command Line Interface (CLI) Commands."
Roles
The user's roles. Roles determine the user's access to tabs and subtabs in the Web interface.
•
•
•
Step 3
Related Topics
Delete Users
Use the following procedure to delete users.
Caution
Note
Procedure
Step 1
Step 2
Modifying Your Profile
Use the My Profile tab to:
•
•
•
Changing Your Password
The user password is set when the user is created. Use the following procedure to change your password.
Note
Procedure
Step 1
Step 2
Step 3
Related Topics
Changing Your Email Address
The email address is set initially when a user is created. To change your email address, use the following procedure.
Note
Procedure
Step 1
Step 2
Step 3
Related Topics
Changing the Default Tab and Subtab
By default, an overview that provides information about all the main tabs is displayed when you log in. When you select a tab, an overview of the subtabs is displayed.
Use the following procedure to select a tab as your home page and select default subtabs for each main tab.
Note
Procedure
Step 1
Step 2
•
•
Step 3
•
•
Step 4
Creating Links
You can link to other systems and display their desktops in the right pane or in a separate window. For example, you could link to a CiscoWorks server, to Cisco Secure ACS, or to another WLSE.
The special link called ACS Failed Login Report generates a report about failed logins on an ACS server.
This section contains the following topics:
•
•
•
Note
Creating a Link to Another System
Note
Procedure
Step 1
Step 2
a.
b.
c.
Step 3
a.
b.
Step 4
Do not delete the ACS Failed Login Report link. If you accidentally delete it and want to recreate it, see Replacing a Deleted Link.
Step 5
Configuring the ACS Failed Login Report Link
This section contains the following topics:
•
•
Configuring the Link
Note
The link must be configured before you display a report.
Procedure
Step 1
Step 2
Step 3
Step 4
Step 5
Related Topics
Running the ACS Failed Login Report
Replacing a Deleted Link
If the link has been deleted, use the following procedure to create it again.
Procedure
Step 1
Step 2
Step 3
Step 4
Step 5
Related Topics
Running the ACS Failed Login Report
Running the ACS Failed Login Report
The ACS failed login report shows failed logins on a specified Cisco Access Control Server (ACS).
Note
To run an ACS failed login report:
Procedure
Step 1
•
•
Step 2
