New and Changed Features
The following sections describe the new and changed features in Software Version 5.3.5x:
– Standard Image Files
– No Payload Encryption Image Files
Software Version 5.3.5x Filenames
This section describes the Cisco WAAS Software Version 5.3.5x software image files for use on Cisco WAAS appliances and modules and contains the following topics:
Standard Image Files
Cisco WAAS Software Version 5.3.5x includes the following standard primary software image files for use on Cisco WAAS appliances and modules:
- waas-universal-5.3.5. x -k9.bin—Universal software image that includes Central Manager, Application Accelerator, and AppNav Controller functionality. You can use this type of software file to upgrade a device operating in any device mode.
- waas-accelerator-5.3.5. x -k9.bin—Application Accelerator software image that includes Application Accelerator and AppNav Controller functionality only. You can use this type of software file to upgrade only an Application Accelerator or AppNav Controller device. This software image file is significantly smaller than the Universal image. Kdump analysis functionality is not included in the Accelerator-only image.
- waas-sre-installer-5.3.5. x -k9.zip—SM-SRE install .zip file that includes all the files necessary to install Cisco WAAS on the SM-SRE module.
- ISR-WAAS-5.3.5.x.<build #>.ova - ISR WAAS Release 5.3 files- 2500 Conns
The following additional files are also included:
- waas-rescue-cdrom-5.3.5. x -k9.iso—Cisco WAAS software recovery CD image.
- waas-x86_64-5.3.5. x -k9.sysimg—Flash memory recovery image for 64-bit platforms (WAVE-274/294/474/574/594/694/7541/7571/8541 and WAE-674/7341/7371 devices).
- waas-5.3.5. x -k9.sysimg—Flash memory recovery image for 32-bit platforms (all other devices).
- waas-kdump-5.3.5. x -k9.bin—Kdump analysis component that you can install and use with the Application Accelerator software image. The Kdump analysis component is intended for troubleshooting specific issues and should be installed following the instructions provided by Cisco TAC.
- waas-alarm-error-books-5.3.5. x .zip—Contains the alarm and error message documentation.
- virtio-drivers.iso—Virtual blade paravirtualized network drivers for Windows. (Available at the Cisco Wide Area Application Services (WAAS) Software > Tools directory on Cisco.com.)
No Payload Encryption Image Files
Cisco WAAS Software Version 5.3.5x includes No Payload Encryption (NPE) primary software image files that have the disk encryption feature disabled. These images are suitable for use in countries where disk encryption is not permitted. NPE primary software image files include the following:
- waas-universal-5.3.5. x -npe-k9.bin—Universal NPE software image that includes Central Manager, Application Accelerator, and AppNav Controller functionality. You can use this type of software file to upgrade a device operating in any device mode.
- waas-accelerator-5.3.5. x -npe-k9.bin—Application Accelerator NPE software image that includes Application Accelerator and AppNav Controller functionality only. You can use this type of software file to upgrade only an Application Accelerator or AppNav Controller device. This software image file is significantly smaller than the Universal image. Kdump analysis functionality is not included in the Accelerator-only image.
- waas-sre-installer-5.3.5. x -npe-k9.zip—SM-SRE install .zip file that includes all the NPE files necessary to install Cisco WAAS on the SM-SRE module.
- Cisco-WAAS-vCM-100N-npe.ova - VCM Release 5.3.5.x NPE-100 Nodes
- Cisco-WAAS-vCM-2000N-npe.ova - VCM Release 5.3.5.x NPE files -2000 Nodes
- Cisco-WAAS-vWAAS-200-npe.ova - VWAAS Release 5.3.5.x NPE files-200 Conns
- Cisco-WAAS-vWAAS-750-npe.ova - VWAAS Release 5.3.5.x NPE files -750 Conns
- Cisco-WAAS-vWAAS-1300-npe.ova - VWAAS Release 5.3.5.x NPE files-1300 Conns
- Cisco-WAAS-vWAAS-2500-npe.ova - VWAAS Release 5.3.5.x NPE files-2500 Conns
- Cisco-WAAS-vWAAS-6000-npe.ova - VWAAS Release 5.3.5.x NPE files - 6000 Conns
- Cisco-WAAS-vWAAS-12000-npe.ova - VWAAS Release 5.3.5.x NPE files-12000 Conns
- Cisco-WAAS-vWAAS-50000-npe.ova - VWAAS Release 5.3.5.x NPE files- 50000 Conns
- ISR-WAAS-5.3.5.x.<build #>-npe.ova - ISR WAAS Release 5.3.5.x NPE files- 2500 Conns
The following additional files are also included:
- waas-rescue-cdrom-5.3.5. x -npe-k9.iso—Cisco WAAS NPE software recovery CD image.
- waas-x86_64-5.3.5. x -npe-k9.sysimg—Flash memory NPE recovery image for 64-bit platforms (WAVE-274/294/474/574/594/694/7541/7571/8541 and WAE-674/7341/7371 devices).
- waas-5.3.5. x -npe-k9.sysimg—Flash memory NPE recovery image for 32-bit platforms (all other devices).
- waas-kdump-5.3.5. x -npe-k9.bin—NPE Kdump analysis component that you can install and use with the Application Accelerator software image. The Kdump analysis component is intended for troubleshooting specific issues and should be installed following the instructions provided by Cisco TAC.
- waas-alarm-error-books-5.3.5. x -npe.zip—Contains the NPE alarm and error message documentation.
- virtio-drivers.iso—Virtual blade paravirtualized network drivers for Windows. (Available at the Cisco Wide Area Application Services (WAAS) Software > Tools directory on Cisco.com.)
Cisco WAAS Appliance System Firmware Update
On Cisco Wide Area Application Engine (WAE) and Cisco Wide Area Application Virtualization Engine (WAVE) appliances, we recommend that you update the following three types of system firmware to the latest version to best support new Cisco WAAS features:
- BIOS on the WAVE-294/594/694/7541/7571/8541 models—For details, see the “BIOS Update” section. The latest BIOS is required for AppNav operation.
- BMC firmware on the WAVE-294/594/694/7541/7571/8541 models—For details, see the “BMC Firmware Update” section. The latest Baseboard Management Controller (BMC) firmware is required for Intelligent Platform Management Interface (IPMI) over LAN feature.
- RAID controller firmware on the WAE-674/7341/7371 and WAVE-7541/7571/8541—For details, see the “RAID Controller Firmware Update” section. The latest Redundant Array of Independent Disks (RAID) controller firmware is recommended to avoid some rarely encountered RAID controller issues.
The latest BIOS is required for AppNav operation with a Cisco AppNav Controller Interface Module in WAVE-594/694/7541/7571/8541 models. WAVE-294 models may also need a BIOS update, though they do not support AppNav.
WAVE-594/694/7541/7571/8541 appliances shipped from the factory with Cisco WAAS Version 5.0.1 or later have the correct BIOS installed. WAVE-294 appliances shipped from the factory with Cisco WAAS Version 5.1.1 or later have the correct BIOS installed.
If you are updating a device that was shipped with an earlier version of Cisco WAAS software, you should update the BIOS, unless it was updated previously. WAVE-594/694 models require BIOS version 18A, WAVE-7541/7571/8541 models require BIOS version 11A, and WAVE-294 models require BIOS version 18A.
If you install a Cisco AppNav Controller Interface Module in a device that requires a BIOS update, the bios_support_seiom major alarm is raised, “I/O module may not get the best I/O performance with the installed version of the system BIOS firmware.”
To determine if a device has the correct BIOS version, use the show hardware command. The following example displays the BIOS version installed on the device, which is the last three digits of the version value:
Vendor :American Megatrends Inc.
Version :A31C117A <<<<< version 17A
If a BIOS firmware update is needed, you can download it from cisco.com at the Cisco Wide Area Application Service (WAAS) Firmware download page ( registered customers only). The firmware binary image for WAVE-294/594/694/7541/7571/8541 appliances is named waas-bios-installer-18a-18a-11a-k9.bin.
You can use the following command to update the BIOS from the image file that is available through FTP on your network:
copy ftp install ip-address remotefiledir waas-bios-installer-18a-18a-11a-k9.bin
Use the appropriate BIOS installer file for your appliance model.
The complete update process can take several minutes and the device may appear unresponsive but do not interrupt the process or power cycle the device. After the update is complete, you must reload the device.
After the device reboots, you can verify the firmware version by using the show hardware command.
BMC Firmware Update
IPMI over LAN requires that you install a specific BMC firmware version on the device. The minimum supported BMC firmware versions are as follows:
Cisco WAAS appliances shipped from the factory with Cisco WAAS Version 4.4.5 or later have the correct firmware installed. If you are updating a device that was shipped with an earlier version of Cisco WAAS software, you must update the BMC firmware, unless it was updated previously.
To determine if you are running the correct firmware version, use the show bmc info command. The following example displays the latest BMC firmware version installed on the device (49a here):
Firmware Revision : 0.49 <<<<< version 49
Manufacturer Name : Unknown (0x168B)
Product ID : 160 (0x00a0)
Product Name : Unknown (0xA0)
Provides Device SDRs : no
Additional Device Support :
If a BMC firmware update is needed, you can download it from cisco.com at the Cisco Wide Area Application Service (WAAS) Firmware download page ( registered customers only). For example, if the firmware binary image is named waas-bmc-installer-48a-48a-27a-k9.bin, you can use the following command to update the firmware from the image file that is available through FTP on your network:
copy ftp install ip-address remotefiledir waas-bmc-installer-48a-48a-27a-k9.bin
The update process automatically checks the health status of the BMC firmware. If the system detects that the BMC firmware is corrupted, BMC is recovered during the BMC firmware update procedure. The complete update process can take several minutes. If the device appears unresponsive, do not interrupt the process or power cycle the device. After the update is complete, you must reload the device.
After the device reboots, you can verify the firmware version by using the show bmc info command.
BMC recovery and BMC firmware update restores the factory defaults on the BMC and all the current IPMI over LAN configurations are erased.
If the BMC firmware gets corrupted, a critical alarm is raised.
RAID Controller Firmware Update
We recommend that you upgrade to the latest RAID controller firmware for your hardware platform, which can be found on cisco.com at the Cisco Wide Area Application Service (WAAS) Firmware download page ( registered customers only). The firmware differs depending on your hardware platform:
- WAVE-7541/7571/8541—Update to the 12.12.0 (0060) RAID Controller Firmware (or later version).
The firmware binary image is named waas-raid-fw-installer-12.12.0-0060-k9.bin. Instructions on how to apply the firmware update are posted on cisco.com together with the firmware in the file named M2_0060_FIRMWARE.pdf, which you can see when you mouse over the firmware file.
- WAE-674/7341/7371—Update to the 5.2-0 (17002) RAID Controller Firmware (or later version). You can check your current RAID controller firmware version with the show disk tech-support EXEC command. The Firmware field displays the firmware version.
The firmware binary image is named L4_ xxxxx _FIRMWARE.bin. Instructions on how to apply the firmware update are posted on cisco.com together with the firmware in the file named L4_ xxxxx _FIRMWARE.pdf, which you can see when you mouse over the firmware file.
Under rare circumstances, the RAID controller firmware used in the WAE-674, WAE-7341, and WAE-7371 appliances can cause the disk storage subsystem to go offline and the affected devices to stop optimizing connections. The symptoms are as follows:
- Syslog output contains several instances of the following message:
“WAAS-SYS-3-900000: sd 0:0:0:0: rejecting I/O to offline device.”
- A sysreport and running-config file cannot be generated and copied to /local/local1.
Both these symptoms are an indication of the file system becoming read-only during traffic flow.
- An increasing number of pending connections appear in the output of the show statistics tfo command, which indicates that new connections cannot be optimized. You can use this command to proactively check the functionality of the system.
The solution is to upgrade to the 5.2-0 (17002) RAID Controller Firmware (or later version).
Using SSL Accelerated Services
After you have enabled and configured SSL acceleration on your WAAS system, you must define at least one service to be accelerated on the SSL path. To configure SSL accelerated services, follow these steps:
Step 1 From the WAAS Central Manager menu, choose Devices > device-name ( or Device Groups > device-group-name ).
Step 2 Choose Configure > Acceleration > SSL Accelerated Services .
Step 3 Click Create to define a new accelerated service. A maximum of 512 accelerated services are allowed. The Basic SSL Accelerated Services Configuration window appears.
Step 4 Type a name for the service in the Service Name field.
Step 5 To enable this accelerated service, check the In service check box.
Step 6 To enable client version rollback check, check the Client version rollback check checkbox.
Enabling the client version rollback check does not allow connections with an incorrect client version to be optimized.
Step 7 To enable protocol chaining, check the Enable protocol chaining check box.
Enabling protocol chaining allows other protocols to be optimized over SSL.
Step 8 To match subject alternative names, enable the Match Server Name Indication checkbox. For more information, see the “Configuring SSL Acceleration for SaaS Applications” section.
Step 9 (Optional) Type a description of the service in the Description field.
Step 10 From the Server drop-down list, choose IP Address, Hostname, or Domain as the SSL service endpoint type. Type the server IP address, hostname, or domain of the accelerated server. Use the keyword Any to specify any server IP address. A maximum of 32 IP addresses, 32 hostnames, and 32 domains are allowed.
Note Hostname and domain server address types are supported only when using WAAS Software Version 4.2.x or later. Server IP address keyword Any is supported only when using WAAS Software Version 4.2.x or later.
Step 11 Type the port associated with the service to be accelerated. Click Add to add each address. If you specify a server hostname, the Central Manager resolves the hostname to the IP address and adds it to the Server IP/Ports table. Refer to “Configuring SSL Acceleration for SaaS Applications” section to configure ports for SaaS applications.
Step 12 Click Delete to remove an IP address from the list.
Step 13 Choose a certificate and key pair method from Certificate and Private Key.
- Click Generate Self-signed Certificate Key to have the WAAS devices use a self-signed certificate/key pair for SSL.
- Click Import Existing Certificate Key to upload or paste an existing certificate/key pair.
Note In case of SaaS applications, the certificate should have the Subject Alternative Name (SAN) information.
- Click Export Certificate Key to export the current certificate/key pair.
- Click Generate Certificate Signing Request to renew or replace the existing certificate/key pair. The certificate signing request (CSR) is used by the Certificate Authority to generate a new certificate.
The file that you import or export must be in either a PKCS12 format or a PEM format.
For service certificate and private key configuration steps, see the “Configuring a Service Certificate and Private Key” section in the Cisco Wide Area Application Services Configuration Guide.
Note If you change the certificate or key for an existing SSL accelerated service, you must uncheck the In service check box and click Submit to disable the service, then wait 5 minutes and check the In service check box and click Submit to reenable the service. Alternatively, at the WAE, you can use the no inservice SSL accelerated service configuration command, wait a few seconds, and then use the inservice command. If you are changing the certificate or key for multiple SSL accelerated services, you can restart all accelerated services by disabling and then reenabling the SSL accelerator.
Step 14 Click the Advanced tab to configure SSL parameters for the service. The Advanced SSL Accelerated Services Configuration window appears.
Step 15 (Optional) In the SSL version field, choose the type of SSL protocol to use, or choose Inherited to use the SSL protocol configured in global SSL settings. Choose SSL3 for the SSL version 3 protocol, choose TLS1 for the Transport Layer Security version 1 protocol, or choose All to use both SSL3 and TLS1 SSL protocols.
Step 16 (Optional) In the Cipher List field, choose a list of cipher suites to be used for SSL acceleration between the WAE device peers, or choose Inherited to use the cipher list configured in SSL global settings. For more information, see the section in Working with XCipher Lists section in the WAAS Configuration Guide.
Step 17 (Optional) To set the Online Certificate Status Protocol (OCSP) parameters for certificate revocation, follow these steps:
a. To enable verification of client certificate check, check the Verify client certificate check box.
b. Check the Disable revocation check for this service check box to disable OCSP client certificate revocation checking.
c. To enable verification of server certificate check, check the Verify server certificate check box.
d. Check the Disable revocation check for this service check box to disable OCSP server certificate revocation checking.
Note If the server and client devices are using self-signed certificates and certificate verification is enabled, WAAS devices will not be able to accelerate SSL traffic.
Step 18 Click Submit when you have finished configuring the SSL accelerated service.
Configuring SSL Acceleration for SaaS Applications
SaaS applications are typically served from multiple SSL server farms, with multiple hosts spanning across several data centers. For SSL services hosted in the enterprise data center, the IT administrator knows and controls the SSL server IP and can provide it to the data center WAAS. But for a SSL service that is hosted at a third-party SaaS provider in the cloud, the SSL server IP address is not controlled by the IT administrator because the cloud provider uses multiple Content Delivery Networks and data centers. Even for a single SaaS service there might be multiple server IP addresses that can change dynamically. This leads to inadvertent errors due to namespace/certificate mismatch for SaaS applications.
To avoid these errors and to ensure that these applications are optimized, follow the steps to configure the SSL accelerated services for SaaS applications:
Step 1 Create a SSL accelerated service for a SaaS application using steps 1 through 8 outlined in “Using SSL Accelerated Services” section.
Step 2 To match subject alternative names, enable the Match Server Name Indication checkbox. Alternately, use the match sni command on the core WAAS device.
If enabled, the SSL accelerator parses the initial SSL connection setup message for the destination hostname(in the SSL protocol extension called Server Name Indication) and uses that to match it with the Subject Alternate Names (SAN)s list in the SSL certificate on the WAAS device.
Note This setting is recommended for optimizing cloud-based SaaS applications to avoid namespace/certificate mismatch errors that are caused due to the changing nature of the SaaS server domains and IP addresses.
Note Most modern browsers provide Server Name Indication (SNI) support. Ensure that you use a browser that supports SNI.
Note The Match Server Name Indication option is available only on devices running WAAS 5.3.5 or later.
Step 3 Use the keyword Any to specify the server IP address of the accelerated server.
Step 4 Direct all SSL traffic for SAAS applications to port 443.
The above configuration overrides any wildcard configuration.
Note If your have configured port 443 for traffic other than SaaS applications, you would need to review and reconfigure it appropriately.
Step 5 Click Import Existing Certificate Key to upload or paste a certificate/key pair. The certificate should be specifically used for the SaaS accelerated service and should contain the Subject Alternate Names for the server domains that need to be optimized. Identify the server domains that need to be added for optimizing SaaS applications by following the steps outlined in Determining Server Domains Used by SaaS Applications.
Note You need to create a new certificate with the missing server domain names derived from the list at regular intervals to ensure that the connections are optimized.
Step 6 Click Submit to complete configuring the SSL accelerated service for the SaaS application.
Determining Server Domains Used by SaaS Applications
When you enable the Match Server Name Indication checkbox, you can log into the core WAAS device and use the show crypto ssl services accelerated-service <service name> command to view the list of the server domain names that did not match the existing SSL certificate and hence were not optimized. If you wish to optimize any of these server domain names, select and add them to your certificate following the steps below.
This list contains a maximum of 128 server names.
Step 1 Identify the relevant servers to be added. Use the show crypto ssl services accelerated-service <service name> to see additional details regarding the count and last seen information of the server name.
If you need additional information to view ip address and hostnames, use the debug accelerator ssl sni command to enable sni debugs.
Step 2 Log in to the Microsoft Management Console (MMC), OpenSSL or any other available customer tool to create a new Certificate Signing Request (CSR) with the relevant server domain names of the SaaS applications in the subject alternative names extension of the certificate. Refer to the highlighted area in the example certificate below.
Note When you add the SAN to the certificate, domain names need to be separated by a comma. Note that a list of hostnames on a domain can be secured with a single certificate. For example, a.b.c.com and c.b.com can be added as *.b.c.com. However, for a new hostname on another domain, you will need to make a new entry. For example, for b.c.com you will need to add it as b.c.com or *.c.com. Additionally, you can also secure host names on different base domains in the same certificate, for example a.b.com and a.b.net.
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=US, ST=California, L=San Jose, O=Cisco
Not Before: Jul 31 06:49:56 2013 GMT
Not After : Aug 30 06:49:56 2013 GMT
Subject: C=US, ST=California, L=San Jose, O=Cisco
Public Key Algorithm: rsaEncryption
Exponent: 65537 (0x10001)
X509v3 Basic Constraints:
Digital Signature, Non Repudiation, Key Encipherment
X509v3 Subject Alternative Name:
DNS:*.office365.com, DNS:outlook.com, DNS:*.aadcdn.microsoftonline-p.com, DNS:*.aspnetcdn.com, DNS:*.client.hip.live.com, DNS:*.hip.live.com, DNS:*.linkedinlabs.com, DNS:*.live.com, DNS:*.microsoft.com, DNS:*.microsoftonline-p.com, DNS:*.microsoftonline-p.net, DNS:*.microsoftonline.com, DNS:*.microsoftonlineimages.com, DNS:*.microsoftonlinesupport.net, DNS:*.msecnd.net, DNS:*.msocdn.com, DNS:*.office.net, DNS:*.office365.com, DNS:*.officeapps.live.com, DNS:*.officecdn.microsoft.com, DNS:*.onmicrosoft.com, DNS:*.outlook.com, DNS:*.res.outlook.com, DNS:*.sharepoint.com, DNS:*.sharepointonline.com, DNS:*.telemetry.microsoft.com, DNS:*.testexchangeconnectivity.com, DNS:*.vo.msecnd.net, DNS:*.webtrends.com
Signature Algorithm: sha1WithRSAEncryption
Step 3 Submit the certificate to the Enterprise CA.
Step 4 Import the signed certificate from the Enterprise CA to the Trusted Root Certification Authorities store. The Enterprise root CA should be present in browser as trusted root CA.
Step 5 Uncheck the In service checkbox and click Submit to disable the accelerated service. Upload the new certificate and re enable the service.
Updated SSL: Acceleration Bypass Reason
The SSL Acceleration Bypass Reason pie chart in the SSL Acceleration Report in WAAS Central Manager has been updated to display a server name indication mismatch.
Upgrading and Interoperability
This section contains the following topics:
Interoperability and Support
Table 1 lists the hardware, client, and web browser support for Cisco WAAS Software Version 5.3.5x.
Table 1 Hardware, CIFS Client, Web Browser Support
The Cisco WAAS software operates on these hardware platforms: WAE-674, WAE-7341, WAE-7371, WAVE-274, WAVE-474, WAVE-574, WAVE-294, WAVE-594, WAVE-694, WAVE-7541, WAVE-7571, WAVE-8541 appliance, or an SM-SRE-700, SM-SRE-710, SM-SRE-900, or SM-SRE-910 network module that is installed in specific Cisco routers. Additionally, Cisco 880 Series, 890 Series, and ISR G2 routers running Cisco WAAS Express are supported on the branch side (Cisco WAAS Version 4.2.1 or later is required on the data center side). vWAAS is supported in a Kernel Virtual Machine (KVM) on the Cisco 4451-X Integrated Services Router and on a UCS E-Series module installed in a Cisco ISR G2 or Cisco 4451-X Integrated Services Router, and on other supported VMware virtual machines (for details, see the Cisco Wide Area Application Services vWAAS Installation and Configuration Guide ).
You must deploy the Cisco WAAS Central Manager on a dedicated device.
Note Cisco WAAS, Release 5.3 is the final version that will support the WAE-674, WAE-7341, WAE-7371, WAVE-274, WAVE-474, and WAVE-574 platforms.
CIFS client support
The Cisco WAAS software running on a branch WAE interoperates with these Common Internet File System (CIFS) clients: Windows 98/NT 4.0/2000/XP/Vista/7 and Windows Server 2003/2008 R2.
Web browser support
The Cisco WAAS Central Manager GUI requires Internet Explorer version 8 or 9 (only 8 on Windows XP), Firefox version 4 or later, Chrome version 10 or later, or Safari version 5.x (only on Apple OS X) and the Adobe Flash Player browser plug-in. The WAE Device Manager GUI requires Internet Explorer version 5.5 or later.
Note When using Internet Explorer, ensure that the Tools > Internet Options > Advanced tab > Do not save encrypted pages to disk check box (under Security) is checked. If this box is unchecked, some charts do not display (CIFS device level charts and version 4.x scheduled reports that have completed). Additionally, we recommend that you clear the browser cache and restart the browser if CIFS device level charts are not visible.
Cisco WAAS Version Interoperability
Consider the following guidelines when operating a Cisco WAAS network that mixes Software Version 5.3.5x devices with devices running earlier software versions:
- Cisco WAAS Version 5.3.5x is not supported running in a mixed version Cisco WAAS network where any Cisco WAAS device is running a software version earlier than 4.3.1. If you have any Cisco WAAS devices running a version earlier than 4.3.1, you must first upgrade them to version 4.3.1 (or a later version) before you install Version 5.3.5x. Do not upgrade any device to a version later than the existing Central Manager version. After all devices and the Central Manager are running version 4.3.1 or later, you can begin the upgrade to Version 5.3.5x on the Central Manager. Directly upgrading a device from Version 4.0, 4.1, or 4.2 to 5.3.5x is not supported.
- In a mixed version Cisco WAAS network, the Central Manager must be running the highest version of the Cisco WAAS software.
Consider the following guidelines when deploying the Cisco AppNav solution:
- If you are connecting an AppNav Controller (ANC) to a Catalyst 6500 series switch and you have configured the ANC to use the Web Cache Communication Protocol (WCCP) with the L2 redirect method, do not deploy the ANC on the same subnet as the client computers. This configuration can cause packet loss due to a limitation of the Catalyst 6500 series switch.
- All Cisco WAAS nodes in an AppNav deployment must be running Cisco WAAS version 5.0 or later.
- Cisco WAAS Express devices cannot operate as Cisco WAAS nodes in an AppNav deployment.
- A software version of AppNav, called AppNav-XE, is available on Cisco routers that run Cisco IOS XE Release 3.8 and later but it is not interoperable with Cisco AppNav Controller Interface Modules in the same AppNav Controller group. AppNav-XE can redirect traffic to Cisco WAAS devices for optimization.
Cisco WAAS Express Interoperability
Consider the following guideline when using Cisco WAAS Express devices in your Cisco WAAS network:
- When using a Cisco WAAS device running version 5.x and a Cisco WAAS Express peer device running Cisco IOS Release 15.2(2)T or earlier, connections originating from the Cisco WAAS device and sent to the Cisco WAAS Express peer are passed through instead of being optimized. We recommend upgrading to Cisco WAAS Express in Cisco IOS Release 15.2(3)T or later to take advantage of the latest enhancements
Note To avoid connection resets, Cisco recommends that you do not use HTTP Application Optimizer (AO) between Cisco WAAS and Cisco WAAS Express unless you are running Cisco IOS Release 15.3(1)T or later.
Central Managers running Version 5.3.5x can manage WAEs running Software Versions 4.2.1 and later. However, we recommend that all WAEs in a given WCCP service group be running the same version.
Note All WAEs in a WCCP service group must have the same mask.
To upgrade the WAEs in your WCCP service group, follow these steps:
Step 1 You must disable WCCP redirection on the Cisco IOS router first. To remove the global WCCP configuration, use the following no ip wccp global configuration commands:
Router(config)# no ip wccp 61
Router(config)# no ip wccp 62
Step 2 Perform the Cisco WAAS software upgrade on all WAEs using the Cisco WAAS Central Manager GUI.
Step 3 Verify that all WAEs have been upgraded in the Devices pane of the Central Manager GUI. Choose Devices to view the software version of each WAE.
Step 4 If mask assignment is used for WCCP, ensure that all WAEs in the service group are using the same WCCP mask value.
Step 5 Reenable WCCP redirection on the Cisco IOS routers. To enable WCCP redirection, use the ip wccp global configuration commands:
Router(config)# ip wccp 61
Router(config)# ip wccp 62
Cisco WAAS Version 5.1 and later do not support Windows domain login authentication using the NTLM protocol. Therefore, upgrading from a Cisco WAAS Version earlier than 5.1 with the device configured with Windows domain login authentication using the NTLM protocol is blocked. You must change the Windows domain authentication configuration to use the Kerberos protocol before proceeding with the upgrade.
Follow these steps to change from NTLM to Kerberos Windows domain login authentication:
Step 1 Unconfigure Windows domain login authentication. You can do this from the Central manager in the Configure > Security > AAA > Authentication Methods window.
Step 2 Change the Windows domain configuration setting to use the Kerberos protocol. You can do this from Central manager in the Configure > Security > Windows Domain > Domain Settings window. For more information, see the section “Configuring Windows Domain Server Authentication Settings” in the “Configuring Administrative Login Authentication, Authorization, and Accounting” chapter of the Cisco Wide Area Application Services Configuration Guide .
Step 3 Perform the Windows domain join again from the Central manager in the Configure > Security > Windows Domain > Domain Settings window.
Step 4 Configure Windows domain login authentication from the Central manager in the Configure > Security > AAA > Authentication Methods window.
Step 5 Upgrade your device.
Note If you are upgrading the Central Manager itself from the GUI and the Windows domain login authentication on the Central Manager is configured to use the NTLM protocol, the upgrade fails with the following error logged in the device log:
Error code107: The software update failed due to unknown reason. Please contact Cisco TAC.
To view the device log for the Central Manager, choose the Central Manager device and then choose Admin > Logs > Device Logs. If you see this error, follow the steps above to change the Central Manager device Windows domain login authentication from NTLM to Kerberos.
If you upgrade the Central Manager itself from the CLI and the upgrade fails due to NTLM being configured, you will get an appropriate error message. Once the Central Manager is upgraded to Version 5.1, it can detect and display the reason for any upgrade failures for other devices.
Note Cisco WAAS Version 5.1 and later do not support the Kerberos protocol running with a nonstandard port (other than port 88). Upgrading from a Cisco WAAS Version earlier than 5.1 with the device configured with the Kerberos protocol on a nonstandard port is blocked. You must change the Kerberos server on your network to listen on port 88 and change the Kerberos configuration on the device to use port 88. You can do this from the Central manager in the Configure > Security > Windows Domain > Domain Settings window.
If you are trying to upgrade your device from the CLI and the upgrade fails due to NTLM configuration, then the kerberos_validation.sh script is installed on your device. This script can be used to verify that your network supports the Kerberos protocol before changing from NTLM to Kerberos. This script is not available if you are using the Central Manager to upgrade the device.
To run the script, follow these steps:
Step 1 (Optional) Run the Kerberos validation script command with the -help option to display the usage:
CM# script execute kerberos validation.sh -help
This script does basic validation of Kerberos operation, when device is using NTLM protocol for windows-domain login authentication.
It can be used as a pre-validation before migrating from NTLM to Kerberos authentication method.
1. Active Directory reachability test
2. LDAP server and KDC server availability test
3. KDC service functionality test
For this test to succeed device must have to join the domain before this test, if not have joined already.
4. Test for time offset between AD and Device (should be < 300s)
kerberos_validation.sh [windows-domain name]
For example if Device has joined cisco.com then you need to enter: kerberos_validation.sh cisco.com
Step 2 Run the Kerberos validation script to verify that your network supports the Kerberos protocol before migrating from NTLM to Kerberos:
CM# script execute kerberos validation.sh windows_domain_name
WARNING: For windows authentication operation in 5.1.1, Device will use service on following ports.
Please make sure they are not blocked for outbound traffic.
53 UDP/TCP, 88 UDP/TCP, 123 UDP, 135 TCP, 137 UDP, 139 TCP, 389 UDP/TCP, 445 TCP,
Performing following tests on this device.
Test 1: Active Directory reachability test
Test 2: LDAP server and KDC server availability test
Test 3: KDC service functionality test
For this test to succeed device must have to join the domain before this test, if not have joined already.
Test 4: Test for time offset between AD and Device (should be < 300s)
Tests are in progress. It may take some time, please wait...
Test 1: Active Directory reachability test : PASSED
Test 2: LDAP server and KDC server availability test : PASSED
Test 3: KDC service functionality test : PASSED
Test 4: Test for time offset between AD and Device (should be < 300s) : PASSED
Validation completed successfully!
Step 3 Change the device Windows domain login authentication from NTLM to Kerberos and upgrade your device, as described in the first procedure in this section.
Microsoft Windows XP Support
Microsoft ended support for Microsoft Windows XP on April 8, 2014. Microsoft has advised customers to upgrade to a newer Microsoft Windows operating system prior to that date.
Cisco strongly encourages upgrading to the latest Microsoft Windows operating systems. For customers who have not upgraded to the latest Microsoft Windows OS, Cisco will continue to support Microsoft Windows XP with their Cisco WAAS deployments and customers may continue to obtain support from Cisco TAC for those Cisco WAAS deployments for six months after Microsoft’s end-of-support date (Oct. 8, 2014).
Upgrading from a Release Version to Version 5.3.5x
This section contains the following topics:
For additional upgrade information and detailed procedures, refer to the Cisco Wide Area Application Services Upgrade Guide .
Requirements and Guidelines
When you upgrade to Version 5.3.5x, observe the following guidelines and requirements:
- Upgrading to Version 5.3.5x is supported only from Versions 4.3.x, 4.4.x, 4.5.x, 5.0.x, 5.1.x, and 5.2.x. If you want to upgrade a Cisco WAAS device running an earlier version, first upgrade to one of these supported versions and then upgrade to the current 5.3.5x version.
- Upgrading to Version 5.1.1 or later is not supported on the following platforms: WAE-511, WAE-512, WAE-611, WAE-612, WAE-7326, NME-WAE-302, NME-WAE-502, and NME-WAE-522. Cisco WAAS Version 5.1 or later does not operate on these appliances. Upgrading a device group is not allowed if the group contains any of the unsupported devices. If you have a Central Manager running on one of these unsupported platforms, you can migrate it to a supported platform by following the procedure in the “Migrating a Central Manager from an Unsupported Platform” section.
- To take advantage of new features and bug fixes, we recommend that you upgrade your entire deployment to the latest version.
- If you operate a network with devices that have different software versions, the Central Manager must be the highest version and no Cisco WAAS device should be running a version earlier than Version 4.2.1.
- Upgrade the Central Manager devices first, and then upgrade the WAE devices. If you have a standby Central Manager, upgrade it first, before upgrading the primary Central Manager. After upgrading, restart any active browser connections to the Central Manager.
- After upgrading a Central Manager, you must clear your browser cache, close the browser, and restart the browser before reconnecting to the Central Manager.
- Before upgrading a Cisco WAAS Central Manager, make a database backup by using the cms database backup EXEC command. Use the copy disk ftp EXEC command to move the backup file to an external system. In case of any problem during the upgrade, you can restore the database backup that you made before upgrading by using the cms database restore backup-file EXEC command, where backup-file is the one created by the backup command.
- After upgrading application accelerator WAEs, verify that the proper licenses are installed by using the show license EXEC command. The Transport license is enabled by default. If any of the application accelerators were enabled on the device before the upgrade, you should enable the Enterprise license. Configure any additional licenses (Video and Virtual-Blade) as needed by using the license add EXEC command. For more information on licenses, see the “Managing Software Licenses” section in the Cisco Wide Area Application Services Configuration Guide .
- After upgrading application accelerator WAEs, verify that the proper application accelerators, policies, and class maps are configured. For more information on configuring accelerators, policies, and class maps, see the “Configuring Application Acceleration” chapter in the Cisco Wide Area Application Services Configuration Guide .
- If you have two Central Managers that have secure store enabled and you have switched primary and standby roles between the two Central Managers, before upgrading the Central Managers to version 5.3.5x, you must reenter all passwords in the primary Central Manager GUI. The passwords that need to be reentered include user passwords and CIFS file server passwords. If you do not reenter the passwords, after upgrading to version 5.3.5x, the Central Manager fails to send configuration updates to WAEs and the standby Central Manager until after the passwords are reentered.
- If you use the setup utility for basic configuration after upgrading to version 5.3.5x, WCCP router list 7 is used. Because the setup utility is designed for use on new installations, any existing configuration for WCCP router list 7 is replaced with the new configuration.
- In Cisco WAAS Versions before 4.4.5, you were able to configure more memory for virtual blades on a 294-4G platform than was supported for virtual blades. To maintain stability, after upgrading from a Version earlier than 4.4.5, all memory allocated to virtual blades on the 294-4G platform is limited to 1 GB. This change affects any existing 294-4G virtual blade configurations.
- Cisco WAAS Version 5.x no longer supports device group configuration of the following features: static bypass lists, vPath interception, and WCCP. When you are upgrading to Version 5.x from a previous version, any device group configurations of these features are copied to the individual devices and the device group settings are removed. WCCP settings can be copied between devices.
- When upgrading from a Cisco WAAS Version earlier than 5.0, you must rename classifier names that contain a period (.) to remove the period. Classifiers with a period in their name are deleted on an upgrade. Replace periods in classifiers with a hyphen (-) or underscore (_) to prevent deletion.
- When upgrading from a Cisco WAAS Version earlier than 5.0, pending reports are carried forward. Charts in reports are retained if they are still available; if they are no longer available, they are migrated to new charts. Any duplicated charts (as a result of migration) in a report are removed and all ICA application accelerator reports are removed because they are all new in Version 5.0. Custom reports are migrated to new custom reports in a similar way. Completed reports from before the upgrade are shown in the Completed Reports list and maintain their original format.
- When upgrading from a Cisco WAAS Version earlier than 5.0, classifiers and policies are migrated to new Version 5.x class maps and policy rules. The same functionality is maintained, though the class map and policy framework are different.
- When upgrading a Central Manager from a Cisco WAAS Version earlier than 5.0, the Cisco Wide Area File Services (WAFS) application definition is migrated to a new CIFS application, except if a CIFS application already exists, the application name change is not done. If you upgrade a WAE device that is not registered to a Central Manager, the WAFS application is not renamed. Any Cisco WAAS device that is still using the WAFS application in a policy rule after an upgrade to Version 5.x raises the following alarm: “WAFS application is configured for optimization. Consider changing the application name to CIFS.” To clear the alarm, you can manually change the policy rule to use the CIFS application or restore default policies.
- The ICA application accelerator in Cisco WAAS Version 5.1.1 and later is incompatible with previous releases. During optimization, if the WAE on one side is running a version earlier than 5.1.1 and the WAE on the other side is running Version 5.1.1 or later, all flows being handled by the ICA application accelerator are optimized with transport flow optimization (TFO) only. Both peer WAEs that are participating in the optimization process must be running Cisco WAAS Version 5.1.1 or later to benefit from ICA acceleration features.
- When upgrading to Cisco WAAS Version 5.1 or later, any previous ICA class maps (Citrix-ICA and Citrix-CGP) are combined into a single class map named citrix that is monitored. In addition to matching traffic on ports 1494 and 2598, it includes a new condition that matches a dynamic port associated with the citrix protocol to support MSI streams. The enhanced ICA features (WAN secure, MSI support, and DSCP for QoS) are disabled by default.
The ICA charts in Cisco WAAS Version 5.0 and later are also different from those used in Version 4.5. If you are viewing the data from a Version 4.5 Cisco WAAS device, the charts appear empty due to the different data that the device is collecting. The ICA data for Version 4.5 Cisco WAAS devices are available in the system level TCP Summary Report by selecting the Remote-Desktop application.
- Cisco WAAS Version 5.1 and later do not support NTLM Windows domain authentication or use of a nonstandard port (other than port 88) for Kerberos authentication. Upgrading from a Cisco WAAS Version earlier than 5.1 is blocked if either of these configurations are detected. You must change these configurations and ensure that your domain controller is configured for Kerberos authentication before proceeding with the upgrade. A script is provided to verify that your network supports Kerberos protocol before migrating from NTLM. For more information, see the “NTLM Interoperability” section. If no application is using the unsupported configurations on the device, then remove the unsupported configurations to upgrade.
- Cisco WAAS Version 5.2 and later restrict the characters used in usernames to letters, numbers, period, hyphen, underscore, and @ sign, and a username must start with a letter or number. Any username not meeting these guidelines is prevented from logging in. Prior to upgrading the Central Manager to Version 5.2 or later, we recommend that you change any such usernames to valid usernames to allow login. For local users, you can do this through the Central Manager Admin > AAA > Users page. For remotely authenticated users, you must change the usernames on the remote authentication server.
Note Prior to upgrading the Central Manager to Version 5.2 or later, we strongly encourage you to change any usernames that use restricted characters; however if you must maintain existing usernames unchanged, please contact Cisco TAC.
- When you upgrade from Cisco WAAS Version 4.x, you must reconfigure the custom EPM policy for a device or device group. You must first restore the default policy setting by selecting the Restore default Optimization Policies link for the device group in the Modifying Device Group window and then reconfigure your custom policy rules for the device.
- Cisco WAAS Version 5.3 and later restricts the use of characters in the name and description field to alphanumeric characters, periods (.), hyphens (-), underscores (), and blank spaces when you create custom reports. When you upgrade from Cisco WAAS Version 4.x and you have custom reports that have special characters in the name or description field, Cisco WAAS automatically removes the special characters from the report name and description, and logs the modification in the central manager system (CMS) logs.
Migrating a Central Manager from an Unsupported Platform
If you have a Cisco WAAS Central Manager that is running on a hardware platform that is unsupported in Version 5.1 and later (such as a WAE-511/512/611/612/7326 or NME-WAE module), you are not allowed to upgrade the device to Version 5.1 or later. You must migrate the Central Manager to a supported platform by following the procedure in this section, which preserves all of the Central Manager configuration and database information.
Follow these steps to migrate a primary Central Manager to a new Cisco WAAS device:
Step 1 From the primary Central Manager CLI, create a database backup by using the cms database backup EXEC command. Move the backup file to a separate device by using the copy disk ftp command.
Creating database backup file backup/cms-db-06-28-2012-15-08_184.108.40.206.15.dump
Backup file backup/cms-db-06-28-2012-15-08_220.127.116.11.15 is ready.
Please use `copy' commands to move the backup file to a remote host.
CM# copy disk ftp 10.11.5.5 / cm-backup.dump cms-db-06-28-2012-15-08_18.104.22.168.15.dump
Step 2 Display and write down the IP address and netmask of the Central Manager.
CM# show running-config interface
primary-interface GigabitEthernet 1/0
interface GigabitEthernet 1/0
ip address 10.10.10.25 255.255.255.0
interface GigabitEthernet 2/0
Step 3 Shut down all the interfaces on the primary Central Manager.
CM(config)# interface GigabitEthernet 1/0 shutdown
Step 4 Replace the existing Central Manager device with a new hardware platform that can support Cisco WAAS Version 5.1. Ensure that the new Central Manager device is running the same software version as the old Central Manager.
Step 5 Configure the new Central Manager with the same IP address and netmask as the old Central Manager. You can do this in the setup utility or by using the interface global configuration command.
newCM(config)# interface GigabitEthernet 1/0 ip address 10.10.10.25 255.255.255.0
Step 6 Copy the backup file created in Step 1 from the FTP server to the new Central Manager.
newCM# copy ftp disk 10.11.5.5 / cm-backup.dump cms-db-06-28-2012-15-08_22.214.171.124.15.dump
Step 7 Restore the database backup on the new Central Manager by using the cms database restore command. Use option 1 to restore all CLI configurations.
newCM# cms database restore backup/cms-db-06-28-2012-15-08_126.96.36.199.15.dump
Backup database version is from an earlier version than the current software version. Restored data will be automatically upgraded when cms services are enabled.
Restoring the backed up data. Secure-Store will be re-initialized.
Successfully migrated key store
***** WARNING : If Central Manager device is reloaded, you must reopen Secure Store with the correct passphrase. Otherwise Disk encryption, CIFS preposition, SSL, AAA and other secure store dependent features may not operate properly on WAE(s).*****
Successfully restored secure-store. Secure-store is initialized and opened.
Overwrite current key manager configuration/state with one in backup (yes|no) [no]?yes
Restoring CLI running configuration to the state when the backup was made. Choose type of restoration.
1. Fully restore all CLI configurations.
2. Partially restore CLI configurations, omitting network configuration settings.
3. Do not restore any CLI configurations from the backup.
Please enter your choice :  1
Please enable the cms process using the command 'cms enable' to complete the cms database restore procedure.
Database files and node identity information successfully restored from file `cms-db-06-28-2012-15-08_188.8.131.52.15.dump'
Step 8 Enable the CMS service.
newCM(config)# cms enable
Step 9 Verify that the Central Manager GUI is accessible and all Cisco WAAS devices are shown in an online state in the Devices window.
Step 10 (Optional) If you have a standby Central Manager that is running on unsupported hardware and is registered to the primary Central Manager, deregister the standby Central Manager.
standbyCM# cms deregister
Step 11 Upgrade the primary Central Manager to Cisco WAAS Version 5.1.x or later. You can use the Central Manager Software Update window or the copy ftp install command.
Step 12 Verify that the Central Manager GUI is accessible and all Cisco WAAS devices are shown in an online state in the Devices window.
Step 13 (Optional) Register a new standby Central Manager that is running Cisco WAAS Version 5.1.x or later.
newstandbyCM(config)# device mode central-manager
Wait for the device to reload, change the Central Manager role to standby, and register the standby Central Manager to the primary Central Manager.
newstandbyCM(config)# central-manager role standby
newstandbyCM(config)# central-manager address 10.10.10.25
newstandbyCM(config)# cms enable
Ensuring a Successful RAID Pair Rebuild
RAID pairs rebuild on the next reboot after you use the restore factory-default command, replace or add a hard disk drive, delete disk partitions, or reinstall Cisco WAAS from the booted recovery CD-ROM.
You must ensure that all RAID pairs are done rebuilding before you reboot your WAE device. If you reboot while the device is rebuilding, you risk corrupting the file system.
To view the status of the drives and check if the RAID pairs are in “NORMAL OPERATION” or in “REBUILDING” status, use the show disk details command in EXEC mode. When you see that RAID is rebuilding, you must let it complete that rebuild process. This rebuild process may take several hours.
If you do not wait for the RAID pairs to complete the rebuild process before you reboot the device, you may see the following symptoms that could indicate a problem:
- The device is offline in the Central Manager GUI.
- CMS cannot be loaded.
- Error messages say that the file system is read-only.
- The syslog contains errors such as “Aborting journal on device md2,” “Journal commit I/O error,” “Journal has aborted,” or “ext3_readdir: bad entry in directory.”
- Other unusual behaviors occur that are related to disk operations or the inability to perform them.
If you encounter any of these symptoms, reboot the WAE device and wait until the RAID rebuild finishes normally.