-
User Guide for the CiscoWorks WLSE and WLSE Express, 2.13
-
PDF of the User Guide
-
Index
-
Preface
-
Getting Started
-
Using the Deployment Wizard
-
Monitoring Faults
-
Managing Devices
-
Using IOS Templates
-
Using WLSM Templates
-
Using Deployment Wizard Templates
-
Managing Device Configurations
-
Managing Device Firmware
-
Using Reports
-
Configuring the WLAN Radio Environment
-
Managing Your WLAN Radio Environment
-
Managing the WLAN Radio Environment by Sites
-
Using the Intrusion Detection System
-
Managing a Voice Network
-
Managing the Appliance
-
Managing the Appliance via CLI
-
Using the AAA Server
-
Using CLI Commands
-
Naming Guidelines
-
Ports and Protocols Used by the WLSE
-
Glossary
-
Table Of Contents
Viewing Status of Installed Software
Installing the Software Upgrade
Viewing Software Update History
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
Viewing the Redundancy Event Log
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
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 sections:
•
Managing Firmware Version Support
Note
Note
Ports and Protocols
For information by the ports hosted by and used by the WLSE and the protocols used for network management functions, see "Ports and Protocols."
Overview of the Admin Tab
Table 16-1 describes the subtabs and options that are displayed under the Admin tab.
Table 16-1 Functions of the Admin Tab
Appliance
Manage WLSE system.
System
View and manage supported AP firmware versions.
AAA Administration (WLSE Express only)
Internal authentication and authorization server.
User Admin
Manage users and user roles.
My Profile
Set password, email address, and customize Web interface per user.
Links
Set up links to other systems (such as CiscoWorks servers) and run the ACS failed login report.
Managing the Appliance
Options under the Appliance subtab allow you to manage the WLSE system and use connectivity tools. When you select Admin > Appliance, the following options are displayed.
Note
Table 16-2 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 (WLSE Express only)
Export WLSE's configuration to a file.
Managing WLSE Master Configuration Files (WLSE Express Only)
Redundancy
Manage redundant WLSEs. Two WLSEs can be managed as a high-availability cluster.
Diagnostics
Diagnose WLSE:
•
•
•
Splash Screen
Add a message to users at login.
Time/NTP/Name/Web Timeout
Set system parameters:
•
•
•
Setting Time, Time Servers, Name Servers, and Web Session Timeout
Configure Mailroute
Specify a mail server for email forwarding.
TFTP Management (WLSE Express only)
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
•
Step 3
Note
Step 4
Step 5
Step 6
Related Topics
Viewing System Information via CLI
About Log Files
The WLSE maintains the following log files:
•
•
Table 16-3 General WLSE Log Files
AAA log files
(WLSE Express only)
Logs for the internal AAA server. The internal AAA server is available only on the WLSE Express. 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.
anisnmp.conf.log
Old SNMP community file, which is saved after you run the reset device-snmp command to reset the community string information on the WLSE. For more information, see reset device-snmp.
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.
Health.xml.tgz
Displays the health of the WLSE appliance.
httpd_mod_security_audit_log
Logs details of every request (including POST) detected by ModSecurity (an intrusion detection and prevention engine) as carrying a possible attack.
httpd_mod_security_audit_log
Debug log of ModSecurity.
install.log
Software package installation.
jobvm.log
Errors and other information on scheduled jobs.
login.log
Lists who is logged in, the IP address of the machine from which the user is logged in, and the time the user logged in.
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.
systemCheck.log
System checks performed.
tftp.log
Access points deployed by the Deployment Wizard (that is, 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, updateWLSE-2.13.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
The options under Admin > Appliance > Software are:
•
•
•
•
•
The topics in this section are:
•
•
•
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/public/sw-center/cw2000/crypto/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.13-K9.zip, the package is WLSE-2.13-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
To set up a Windows server as a remote repository, see the relevant Readme.txt file on Cisco.com at
http://www.cisco.com/public/sw-center/cw2000/crypto/wlan-sol-eng/.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
Caution
Note
Procedure
Step 1
If an error message appears instead, you must define the repository before proceeding (Admin > Appliance > Software > Define Repository). For more information, see Managing the Repository.
Step 2
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 3
Step 4
Step 5
Step 6
Step 7
If the Appliance Update window reappears, click the Cancel button to remove it.
Step 8
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
Information about the defined repository is displayed.
If an error message appears instead, you must define the repository before proceeding (Admin > Appliance Software > Define Repository). For more information see Managing the Repository.
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-4 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. Some of these logs are not listed until you have performed an update of WLSE software. For information on these logs, see Using WLSE Log Files.
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:
•
•
Note
Note
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.
You must create all user roles on the Local authentication module. The WLSE ships with 4 default roles that you can use. If you wan to create additional roles, you must define them locally. For more information about user roles, see Managing Roles.
To configure WLSE using ACS as a TACACS+/RADIUS authentication module, see Configuring the CiscoWorks Wireless LAN Solution Engine TACACS+/RADIUS Authentication Using Cisco Secure ACS oncisco.com: http://www.cisco.com/en/US/products/sw/cscowork/ps3915/products_installation_and_configuration_guides_list.html
Related Topics
•
Using an Authentication Module
You can use an existing RADIUS or TACACS+ authentication server to authenticate WLSE users by selecting and configuring the appropriate WLSE authentication module.
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.
In WLSE releases prior to release 2.13, if you used an alternative authentication service, all users had to be in the local database of users. That is, for each user of the WLSE, you had to have a local user account matching the name of the user on the external authentication server. However, starting with WLSE 2.13, if you assign roles on the alternative authentication service, you do not have to create local user accounts.
Depending on the type of authentication server you use, you assign roles on the remote server in different ways as shown in the following table.
To configure WLSE using ACS as a TACACS+/RADIUS authentication module, see Configuring the CiscoWorks Wireless LAN Solution Engine TACACS+/RADIUS Authentication Using Cisco Secure ACS oncisco.com: http://www.cisco.com/en/US/products/sw/cscowork/ps3915/products_installation_and_configuration_guides_list.html
Authentication is performed on the WLSE by enforcing the roles configured on the CiscoSecure ACS server, if you have configured it; otherwise, local user accounts are used. For information on adding users to the local database, see Managing GUI Users.
Note
Procedure
Step 1
Step 2
Step 3
Step 4
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 or SCP server.
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
If the message "Backup/restore is not configured" appears, you must specify the backup location. Select Admin > Appliance > Backup and Restore > Configure. For more information, see Specifying the Backup Location.
Step 2
Step 3
a.
–
–
–
b.
Step 4
Step 5
•
•
•
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
If the message "Backup/restore is not configured" appears, you must specify the backup location. Select Admin > Appliance > Backup and Restore > Configure. For more information, see Specifying the Backup Location.
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 more information 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.13 on Cisco.com.
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-6 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
Admin
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.13.
•
•
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.13 on Cisco.com at
http://www.cisco.com/en/US/products/ps6379/prod_installation_guides_list.html.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 Requirements for hardware and configuration prerequisites.
For details on how redundancy works, see About Redundancy.
You can use the redundancy options to:
•
•
•
Related Topics
•
•
•
•
•
Redundancy Requirements
Following are the hardware, software, and network requirements for WLSE redundancy:
•
•
•
–
–
•
•
•
When the WLSEs are operating as a redundant pair, the VIP address is always assigned to the active node. If there is a failover, the VIP address moves to the new active node. All accesses to the redundant pair are performed by using the VIP address, so after a failover occurs, the active node always responds when addressed by the VIP address. Users can always use the VIP address to connect to the active node.
•
•
•
Note
•
•
Note
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 enable or disable redundancy 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.
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 15 minutes, and the maximum is 5 hours. The frequency of checks made to ensure that each node is functioning is from 15 seconds and 5 minutes.
If the 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 and Troubleshooting
Redundancy troubleshooting messages are logged to the redundancy.log file. System checks are logged to the systemCheck.log file. You can access these logs from Admin > Appliance > Status.
All significant redundancy events since the WLSE was started are logged to the redundancy event log. You can access the event log from Admin > Appliance > Redundancy > Event Log.
To troubleshoot a node, log in using the real IP address, instead of 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-7. 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 whichever WLSE is to be designated as primary. After configuration, the primary node becomes the active node.
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 IP addresses, first turn redundancy off, then configure the node IP addresses.
Caution
Note
Procedure
Step 1
Step 2
Step 3
Step 4
Note
Step 5
Table 16-8 Redundancy Parameters
Redundancy Enabled
Enable or disable redundancy. When enable is selected, the other fields in the screen become active.
User ID
User ID. The user can be any user that has the Redundancy User ID attribute defined it its Role and has CLI privileges.
Password
User password on both the active and standby systems. The password must be identical on both systems.
HTTP Port
Port 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."
Notification Email
(Optional) Email address for notification of redundancy events. For information on notification, see Redundancy Email Messages. For information on configuring email in general, see Configuring the Mail Route.
IP addresses1
Virtual IP eth0
Virtual IP address for the eth0 Ethernet interface must always be entered in this field. Virtual IP addresses are static (non-DHCP).
Virtual IP eth1
If the WLSEs have two Ethernet interfaces, you should enter a different virtual IP address for eth1. However, the virtual IP address for eth1 is optional if redundancy functions will not be used via the eth1 interface.
This Node IP 2
Static (non-DHCP) IP address of the primary node. If both Ethernet interfaces are configured, you can select the address/interface you want to use for redundancy communication.
Other Node IP
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.3
1 For more information on IP addresses and virtual IP addresses, see Redundancy Requirements. Changing parameters such as Virtual IP addresses and HTTP port numbers could cause undesirable behavior when using other management applications.
2 To change a node's IP address, first turn off redundancy, then configure the IP address, then turn on redundancy.
3 These checks are logged in the systemCheck.log. To view this log, select Admin > Appliance > Status.
Step 6
Step 7
•
•
–
–
Related Topics
•
•
•
•
•
Checking Redundancy Settings
Note
Procedure
Step 1
Step 2
Step 3
Table 16-9 Redundancy Status 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.
User ID
User ID. The user can be any user that has the Redundancy User ID attribute defined it its Role and has CLI privileges.
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 eth1
Virtual IP address of Ethernet interface 1 (if in use).
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 (how often data is copied from the active node to the standby node). Default: 60 minutes. Range: 15 minutes to 5 hours.
Seconds between check of other node
How often to check to make sure both nodes are functioning. Default: 60 seconds. Range: from 15 seconds to 5 minutes.1
1 These checks are logged in the systemCheck.log. To view this log, select Admin > Appliance > Status.
Step 4
Related Topics
•
•
•
•
•
Viewing the Redundancy Event 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. You can either:
•
•
For more information on both methods, see the document Upgrading the CiscoWorks Wireless LAN Solution Engine, 2.13 on Cisco.com at http://www.cisco.com/univercd/cc/td/doc/product/rtrmgmt/cwparent/cw_1105/wlse/2_13/index.htm.
Replacing 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 (node) 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.
If a process has failed a message (in red) is displayed in the top right corner of the Web interface. For example: Following process failed: WirelessSvcManager.
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. A green up arrow shows that the process is running; a red down arrow shows that the process has failed.
Click on the arrow for more information about process status.
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:
TFTP
TFTP server.
WLSEIdleServer
Idle logout server for access to the CLI via Telnet or SSH.
WLSERepository
Local software repository server.
WirelessSvcMgr
Process that manages radio management tasks.
WLSEjobvm
Job virtual machine.
WLSEFaults
Fault manager.
WebServer
Web server.
Tomcat
Java servlet engine.
HaMibDaemon
HA MIB agent. Daemon process that listens to the redundancy switchover events and sends them to the SNMP agent.
ExcepReporter
Trap processes.
CDPbrdcast
CDP daemon that identifies Cisco devices to their immediate neighbors.
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/Web Timeout 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-10 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 and tests read/write SNMP strings. 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
Using the Telnet/SSH Tool
Note
Procedure
Step 1
Step 2
Step 3
Step 4
Note
Step 5
Managing Firmware Version Support
You can use the WLSE to view the versions currently supported by the WLSE.
Note
Procedure
To display firmware versions currently supported by the WLSE:
Step 1
Step 2
Step 3
Note
http://www.cisco.com/en/US/products/sw/cscowork/ps3915/products_device_support_tables_list.html
Managing GUI Users
The options displayed when you select Admin > User Admin allow you to manage user roles and logins:
•
•
Related Topics
•
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 grants access privileges to WLSE functions. The 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. 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.
The following privileges have special functions:
•
About XML API Privileges
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.
About Debug Tools Privileges
The Debug Tools privilege determines whether users can run the debug tools, which are not needed in normal customer environments. These tools are sometimes used in cases involving Cisco support personnel.
About Redundancy User Role Attributes
Any user that is used as the redundancy user much have the Redundancy attributes in their role. See Adding, Modifying, and Deleting Roles for more information about modifying user-defined 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 during initial setup of the WLSE. 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 Administrator 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.
Adding Users
Note
Procedure
Step 1
•
•
•
Step 2
Table 16-11 Adding Users
User Name
Name of the new user. Usernames can be up to 32 characters in length and are case-sensitive.
Most characters are allowed, except for the colon, comma, single quote, double quote, or space. For more information on the allowable characters, see "Naming Guidelines."
Note
User Password
Password for the new user.
Passwords are unlimited in length and are case-sensitive.
You can use most characters, except for the single quote or double quote. For more information on the allowable characters, see "Naming Guidelines."
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
Modifying Users
Note
Procedure
To modify a user:
Step 1
Note
Step 2
Table 16-12 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.
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, double quote, and dollar sign.
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
Deleting Users
Use the following procedure to delete users.
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 Access Control Server (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
