Cisco Service Control Product Upgrade Guide

Table Of Contents

Cisco Service Control Guide to Upgrading to SCA BB 3.5.0

Overview

Upgrading from Version 3.0.x or 3.1.x to Version 3.5.0

Supported Working Configurations

Rollback Procedure

Upgrading the SCA BB

Upgrading SCA BB

How to Install the Console

How to Upgrade the SCA BB Service Configuration Utility

Upgrading the Subscriber Manager

Contents of the Distribution Files

Upgrading the Subscriber Manager

Data Duplication Procedure

Automatic Upgrade of Subscribers with VLAN Mappings

Automatic Upgrade of RADIUS Listener

Configuring the Required Memory Settings

How to Upgrade a Standalone Setup

Upgrading from a Standalone Setup to a Cluster Setup

Upgrading Cluster Setups

How to Downgrade the Subscriber Manager

Upgrading the Collection Manager

How to Upgrade the Collection Manager to Version 3.5.0

Verifying that the Server is Operational

Upgrading the SCE Platform Software

Before You Start

How to Upgrade the SCE Platform Software

Upgrading Cascaded SCE Platforms

Upgrade Procedure Limitations

SCE Platform

SCA BB Clients and Service Configuration

Subscriber Manager

Quota Manager

Collection Manager

Configuration

Obtaining Documentation and Submitting a Service Request

Cisco Service Control Solution Guide

Cisco Service Control Guide to Upgrading to SCA BB 3.5.0

---

Revised: January, 2009, OL-18873-01

1 Overview

Upgrading from Version 3.0.x or 3.1.x to Version 3.5.0

This guide describes the process to upgrade the Cisco Service Control solution from Version 3.0.x or 3.1.x to Version 3.5.0. It describes the upgrade process for each of the four components: Service Control Application for Broadband (SCA BB), Service Control Engine (SCE), Subscriber Manager (SM), and Collection Manager (CM).

The procedure describes a scenario where the Service Control deployment is required to continue functioning throughout the upgrade procedure with SCE platforms running SCA BB 3.0 and SCE platforms running SCA BB 3.1 are operating concurrently (using the same CM and SM servers).

This procedure is meant to minimize service downtime (for however long the upgrade process takes), bound to several limitations, as described in the preceding sections.

---

Note This is a high level description of the procedure. The specific details are found in the following chapters.

---

---

Step 1 Upgrade SCA BB:

a. Install the 3.5.0 console.

b. (Optional) Install the SCA BB Service Configuration Utility version 3.5.0, servconf, in an empty directory

Step 2 Upgrade the SM (or SM cluster) according to the procedure described in Upgrading the Subscriber Manager.

a. Run the SM upgrade script.

The SM does not update an SCE that is identified as standby even if it is configured as 'standalone' in the SM.

---

Note Only after the SM is configured correctly can you update the SCEs.

---

Step 3 Deploy a new CM running 3.5.0. See Upgrading the Collection Manager.

•In the case of deployment of an additional CM and database for the transition phase ( two CM databases in total, regardless of whether or not the configuration is bundled), collection will work for all SCE platforms (both the older version and 3.5.0). Regarding non-bundled databases, there may be several ways to implement this; it is recommended to consult a DB specialist if you are using a non-bundled database.

•Each CM collects RDRs from a single version, to a distinct database (either bundled or non-bundled) and CSV repository.

Step 4 Upgrade the SCE platform software using the SCE Software Upgrade Wizard.

•Make sure the upgraded SCE platform RDRs are directed to the CM running version 3.5.0. Service downtime (from a collection perspective) depends on the CM configuration that you have implemented (single or dual during the upgrade).

At this stage, the entire solution is upgraded and fully operational.

Step 5 Remove the second CM running the former version (if one was used) once the upgrade of all SCE platforms is complete.

---

Supported Working Configurations

The SCA BB release 3.5.0 supports a combination of component versions:

•SCOS 3.5.0.

•Application - SCA BB 3.5.0 (PQI for installation on SCE platform).

•SCMS-SM 3.5.0 (if an SM is required for the deployment).

•SCMS-CM 3.5.0 (if a CM is required for the deployment).

Note that this document covers the upgrade of a system that includes an SM and a CM. In cases where one or both of these components are not required, the corresponding sections can be ignored.

Rollback Procedure

A software rollback might be required in cases where the upgrade process has failed, or has impaired the service. A software rollback requires a downgrade to the previous release to mitigate the damage to the network.

Generally, no automatic downgrade scripts are available for the solution components. To enable downgrade, the older configuration should be backed up before upgrading. To downgrade, a clean installation of the older release is required for each component.

---

Note When downgrading the SCE, you must first uninstall the SCA BB PQI using the PQI uninstall file command. The new PQI file is needed to run this command.

---

2 Upgrading the SCA BB

This chapter details the upgrade procedure for upgrading from a functional SCA BB 3.0.x or 3.1.x deployment to SCA BB 3.5.0.

Upgrading SCA BB

Upgrading SCA BB consists of two steps:

1. Installing the 3.5.0 console. (It is not necessary to uninstall the previous version.)

2. (Optional) Installing the 3.5.0 service ocnfiguration utility.

How to Install the Console

---

Step 1 Navigate to the Console installation file, sca-bb-console-3.5.0.exe, and double-click it.

This opens a standard installation wizard. Follow the standard procedure to install the console.

---

How to Upgrade the SCA BB Service Configuration Utility

---

Step 1 From the SCA BB installation package, extract the file scas_bb_util.tgz, and copy it to a Windows, Solaris, or Linux workstation.

Step 2 Unpack the file to a new folder.

The SCA BB Service Configuration Utility (servconf), the SCA BB Real-Time Monitoring Configuration Utility (rtmcmd) (and associated real-time monitoring report templates), and the SCA BB Signature Configuration Utility (sigconf) are located under the bin folder.

---

3 Upgrading the Subscriber Manager

This chapter describes how to upgrade the Cisco Service Control Management Suite Subscriber Manager (SCMS SM).

Contents of the Distribution Files

The SCMS SM components are supplied in three distribution files:

•SM for Solaris

•SM for Linux

•Login Event Generators (LEGs)

Each distribution file is supplied as a tar file, which is compressed by gzip and has an extension of .tar.gz. For details see the Cisco Service Control Management Suite Subscriber Manager User Guide, the Installing and Upgrading chapter.

Upgrading the Subscriber Manager

The Subscriber Manager supports several types of upgrade procedures, according to the SM version that was previously installed and the requirement (or lack of requirement) for fail-over in the new installation.

There are three types of upgrade procedure:

•How to Upgrade a Standalone Setup

•Upgrading from a Standalone Setup to a Cluster Setup

•Upgrading Cluster Setups

Data Duplication Procedure

The data duplication procedure enables the user to duplicate or copy the entire database from one machine to the other, and then keep the databases synchronized by running the replication agent at the end. Some of the upgrade procedures use this procedure.

For details of the procedure, see the Database Duplication Recovery section in the Cisco Service Control Management Suite Subscriber Manager User Guide.

Automatic Upgrade of Subscribers with VLAN Mappings

VLAN mappings related to VPN rather than to a subscriber. During the upgrade procedure, the SM automatically creates a VPN with the VLAN-ID of the subscriber and associates a subscriber with the full range IP mapping in the new VPN.

For example, subscriber 'sub1' with VLAN-ID=15 will result in the creation of VPN 15 with VLAN-ID=15 and subscriber 'sub1' with the mapping 0.0.0.0/0@VLAN-ID.

Automatic Upgrade of RADIUS Listener

During the upgrade procedure, the SM modifies the RADIUS sections in the configuration file according to the following rules:

•The radius_attribute and radius_attribute_type properties are moved to a new section.

•A new field property is added to replace the radius_attribute and radius_attribute_type properties.

•The strip_type=remove_suffix property is replaced with field_manipulation.<field name>=(.*)<strip_character >.*.

•The strip_type=remove_prefix property is replaced with field_manipulation.<field name>=.*<strip_character >(.*).

•The use_default property and default value are replaced with mapping_table.^$=<default>.

•The radius_attribute_vendor_id and radius_sub_attribute properties are replaced with the format radius_attribute

Configuring the Required Memory Settings

To prepare the SM for the upgrade, configure the system kernel configuration file on the SM.

TimesTen requires that certain changes be made in the operating system kernel configuration file:

•For Solaris, modify file /etc/system.

•For Linux, modify file /etc/sysctl.conf.

These changes increase the shared memory and semaphore resources on the Solaris machine from their defaults. For additional information regarding these changes, refer to the TimesTen documentation.

---

Note It is recommended that you review the /etc/system or the /etc/sysctl.conf file before running the tt-sysconf.sh script, because the script overwrites the current file settings with the values listed in the "To make the required changes manually" procedure. If you want to keep some or all of the current file settings, edit the system configuration file and perform the changes manually.

---

You can make the changes automatically or manually.

•To make the required changes automatically, run the tt-sysconf.sh script.

The root user must invoke this script file, without arguments, as follows:

# tt-sysconf.sh 

•To make the required changes manually:

---

Note Editing the configuration file manually is required when you require support for more than 100,000 subscribers in the SM. Your system's sizing requirements only affect the shared memory size. To determine the correct configuration values for your system, see Table 4-6 through Table 4-9 in the "Installation and Upgrading" chapter of the Cisco Service Control Management Suite Subscriber Manager User Guide.

---

–For Solaris, make the required changes manually by adding the following lines to the /etc/system file and configuring the shared memory size:

*---- Begin settings for TimesTen 
set semsys:seminfo_semmni = 20 
set semsys:seminfo_semmsl = 100 
set semsys:seminfo_semmns = 2000 
set semsys:seminfo_semmnu = 2000 
set shmsys:shminfo_shmmax = 0x20000000 
*---- End of settings for TimesTen

–For Linux, make the required changes manually by adding the following lines to the /etc/sysctl.conf file and configuring the shared memory size:

*---- Begin settings for TimesTen 
kernel.shmmax = 536870912 
kernel.sem = 250 32000 100 100 
*---- End of settings for TimesTen

How to Upgrade a Standalone Setup

This upgrade procedure requires service down-time.

---

Note For the upgrade procedure from a standalone setup to a cluster setup, see Upgrading from a Standalone Setup to a Cluster Setup.

---

---

Step 1 Extract the distribution files.

Before you can upgrade the SM, you must first load and extract the distribution files on the installed machine or in a directory that is mounted to the installed machine.

a. Download the distribution files from the Cisco web site.

b. Use FTP to load the distribution files to the SM.

c. Unzip the files using the gunzip command.

gunzip SM_dist_<version>_B<build number>.tar.gz 

d. Extract the tar the file using the tar command.

tar -xvf SM_dist_<version>_B<build number>.tar 

Step 2 Edit the install-def-cfg file.

Edit the install-def.cfg configuration file and set the PermSize and TempSize parameters according to the recommendations described in Appendix A. For further information, see Configuring the Required Memory Settings.

Step 3 Run the upgrade-sm.sh script.

To upgrade from non-cluster setups, the Subscriber Manager distribution provides an upgrade script that implements an upgrade from previous versions. The upgrade procedure script preserves the subscriber database and the entire SM configuration, including network elements, domains, and application-specific components.

---

Note For Solaris: Previous versions of the SM on Solaris used a 32-bit or 64-bit Java Virtual Machine (JVM) and database. The SM is currently installed with a 64-bit JVM and database. There is no choice as to whether to upgrade to 64-bit.

---

---

Note For Linux: The Linux platform is used only with a 32-bit JVM and database.

---

---

Note It is not possible to run the script if the /etc/motd file exists. The file should be moved or removed prior to running the upgrade-sm.sh script.

---

a. From your workstation shell prompt, run the upgrade-sm.sh script.

# upgrade-sm.sh

Step 4 Add a user for PRPC authentication.

If upgrading from a version of the SM prior to 3.0.5, it is necessary to add a user for PRPC authentication because SCA BB requires a username and password when connecting to the SM.

To add a user for PRPC authentication, use the p3rpc CLU. For example:

>p3rpc --set-user --username=username --password=password 

Step 5 Configure the SCE platforms.

If using a cascade SCE setup, configure the cascade SCE pair in the p3sm.cfg file as described in the SCE.XXX section of Appendix A in the Cisco Service Control Management Suite Subscriber Manager User Guide.

---

Upgrading from a Standalone Setup to a Cluster Setup

This section describes the basic procedure for upgrading from a standalone setup to a cluster setup. This upgrade procedure requires service down-time.

---

Note This procedure attempts to minimize the SM downtime as much as possible. Therefore, if subscriber service is not an issue, use instead the procedure for installing a new machine and upgrading a new machine.

---

In the following procedure, SM-A is the original SM machine and SM-B is the new SM machine being added for redundancy.

---

Step 1 Install the VCS on both machines.

Step 2 Install SM-B.

To install SM-B, follow the procedure described in the Cisco Service Control Product Installation Guide, the "Installing the Subscriber Manager" section.

Step 3 Upgrade SM-A.

To upgrade SM-A, follow the procedure described in How to Upgrade a Standalone Setup.

---

Note From this step until the upgrade procedure is completed, there is no SM to handle subscribers.

---

Step 4 Replicate the SM configuration from SM-A to SM-B (copy all the configuration files from ~pcube/sm/server/root/config folder).

Copy the p3sm.cfg configuration file manually from SM-A to SM-B and load the configuration file using the following CLU command:

p3sm --load-config 

Step 5 Duplicate the subscriber database.

The data duplication procedure is described in Data Duplication Procedure.

Configure the replication scheme for the data store replication to the redundant machine.

---

Note This CLU must run on both machines, and as user pcube.

---

>p3db --set-rep-scheme 

Step 6 Create a cluster.

a. Configure both SM-A and SM-B to support a cluster.

On each machine, open the p3sm.cfg configuration file in any standard text editor and in the [SM High Availability Setup] section, set topology=cluster.

Then load the updated configuration file using the following CLU command:

p3sm --load-config

b. Make SM-B standby.

Use the CLU command p3cluster --standby.

c. Ensure that SM-A is active.

Use the CLU command p3cluster --active.

d. Configure the VCS.

e. Run the VCS on the setup.

Step 7 Configure the LEG applications to send logins to the cluster virtual IP.

---

Upgrading Cluster Setups

This section describes the basic procedure for upgrading from a cluster setup to a cluster setup.

---

Note This procedure does not have a service down time.

---

The upgrade procedure when upgrading from a cluster setup involves three high level steps:

1. Perform the upgrade procedure on the standby machine.

2. Perform a manual failover on the SM that was upgraded.

3. Perform the upgrade procedure on the SM that became standby after performing the failover.

---

Step 1 Configure the system kernel configuration file on both machines.

Before starting the upgrade procedure, it is necessary to configure the system kernel configuration file on both machines.

a. Configure the system kernel configuration file on the standby SM.

The configuration procedure is described in Configuring the Required Memory Settings.

b. Reboot the standby SM.

c. Manually trigger a failover using the Veritas cluster manager and wait until the standby SM becomes active and the active SM becomes standby.

Run the following VCS CLU command from /opt/VRTSvcs/bin:

# hagrp -switch service group name to System

d. Repeat steps a and b on the new standby SM.

Step 2 Extract the distribution files.

Before you can upgrade the SM, you must first load and extract the distribution files on the installed machine or in a directory that is mounted to the installed machine.

a. Download the distribution files from the Cisco web site.

b. Use FTP to load the distribution files to the SM.

c. Unzip the files using the gunzip command.

gunzip SM_dist_<version>_B<build number>.tar.gz

d. Extract the tar file using the tar command.

tar -xvf SM_dist_<version>_B<build number>.tar

Step 3 Stop VCS monitoring.

a. Log in as the root user.

b. Stop the VCS monitoring of the SM.

Use the following VCS CLU command from /opt/VRTSvcs/bin to stop VCS monitoring:

#./hastop -local

Step 4 Edit the install-def.cfg file.

Edit the install-def-cfg configuration file and set the PermSize and TempSize parameters according to the recommendations described in Configuring the Required Memory Settings. For further information see the Cisco Service Control Product Installation Guide, the "Installing the Subscriber Manager" section.

Step 5 Pause database replication

---

Note Perform the following commands only when upgrading the first SM machine.

---

a. On the Active machine, change directory to the location where you extracted the distribution files.

b. Run the p3db --rep-pause CLU from the scripts directory.

c. Run the p3db --rep-status CLU from the scripts directory and verify that replication is in `pause' state.

d. Return to the Standby machine.

Step 6 Run the cluster-upgrade.sh script.

To upgrade from cluster setup to cluster setup, the SM provides an upgrade script to perform an upgrade from previous versions. The upgrade script preserves the subscriber database and the entire SM configuration, including network elements, domains, and application-specific components.

---

Note For Solaris: Previous versions of the SM on Solaris used a 32-bit or 64-bit Java Virtual Machine (JVM) and database. From SM version 3.0.3, the SM is installed with a 64-bit JVM and database. There is no choice as to whether to upgrade to 64-bit.

---

---

Note For Linux: The Linux platform is used only with a 32-bit JVM and database.

---

a. From the standby machine shell prompt, run the cluster-upgrade.sh script.

# cluster-upgrade.sh [command-options]

The following table lists the command options.

Table 1 Options for cluster-upgrade.sh 

Options	Description
-h	Shows this message.
-1	Use this option when activating the script on the first machine.
-2	Use this option when activating the script on the second machine.

Do not start the SM after running cluster-upgrade.sh.

Step 7 Wait until the cluster-upgrade.sh script finishes.

Step 8 Continue database replication.

a. On the Active machine, change directory to the location where you extracted the distribution files.

b. Run the p3db --rep-continue CLU from the scripts directory.

c. Run the p3db --rep-status CLU from the scripts directory and verify that replication is in the `start' state.

d. Return to the Standby workstation.

---

Note Run this command only when upgrading the first machine and only if Step 5 was performed.

---

Step 9 Verify that changed data has been replicated.

Wait until all the data that was changed while the upgrade script was running has been replicated:

•On the active SM add a dummy subscriber using the p3subs CLU:

>p3subs --add -s dummySub

---

Note When upgrading the second SM add a subscriber with a name other than dummySub since it was added during the upgrade of the first SM due to the replication.

---

•On the standby SM run the verify-subscriber.sh script to verify the subscriber was replicated:

#./verify-subscriber.sh dummySub

---

Note The verify-subscriber.sh script should be run as the root user.

---

Step 10 Restart VCS monitoring.

Run the following VCS CLU command from /opt/VRTSvcs/bin:

#./hastart 

VCS monitoring will start the SM process automatically in the Initialization state.

Use the p3cluster CLU in order to set the SM to standby state:

>p3cluster --standby 

---

Note The SM boot time after the upgrade will be longer than usual due to the extra time taken to initialize the database indexes.

---

Step 11 Manually trigger a failover using the Veritas cluster manager and wait until the standby SM becomes active and the active SM becomes standby.

Run the following VCS CLU command from /opt/VRTSvcs/bin:

# hagrp -switch service group name -to System 

For further information about the hagrp CLU refer to your Veritas Cluster Server documentation.

After performing the manual failover, the standby SM on which you perform the upgrade procedure becomes the active SM. The previous active SM becomes the new standby SM.

Step 12 Repeat the upgrade procedure on the standby SM.

To upgrade the second SM, repeat the procedure from Extract the distribution files. to Restart VCS monitoring.

---

Note When upgrading the second SM, do not perform Step 5 "Pause database replication" or Step 8 "Continue database replication".

---

Step 13 Upgrade the database replication protocol version.

---

Note You must perform the following commands as the admin user and you must perform them on both machines to upgrade the database replication protocol version.
You must perform this operation after both SMs are upgraded.

---

a. Stop the VCS monitoring of the standby SM.

Use the following VCS CLU command from /opt/VRTSvcs/bin:

#./hastop -local

b. Upgrade replication protocol.

On the standby SM run the following CLU:

p3db --upgrade-rep-protocol

c. Restart VCS monitoring.

Run the following VCS CLU command from /opt/VRTSvcs/bin:

#./hastart

VCS monitoring starts the SM process automatically in the Initialization state.

d. Use the p3cluster CLU to set the SM to standby state:

>p3cluster --standby

e. Manually trigger a failover using the Veritas cluster manager and wait until the standby SM becomes active and the active SM becomes standby.

Run the following VCS CLU command from /opt/VRTSvcs/bin:

# hagrp -switch service group name -to System

For further information about the hagrp CLU refer to your Veritas Cluster Server documentation.

f. Repeat the upgrade procedure on the standby SM.

Step 14 Add a user for PRPC authentication.

If upgrading from a version of the SM prior to 3.0.5, it is necessary to add a user for PRPC authentication because SCA BB requires a username and password when connecting to the SM.

To add a user for PRPC authentication, use the p3rpc CLU. For example:

>p3rpc --set-user --username=username --password=password --remote=OTHER_SM_IP[:port] 

Step 15 Configure the SCE platforms

If using a cascade SCE setup, configure the cascade SCE pair in the p3sm.cfg file as described in the SCE.XXX section of Appendix A in the Cisco Service Control Management Suite Subscriber Manager User Guide.

Step 16 Remove the dummy subscribers

After successfully upgrading both SMs it is recommended to remove the dummy subscribers that were added in order to verify the replication during the upgrade.

On the new active SM run the following CLU:

>p3subs --remove -subscriber=first dummy subscriber name 

>p3subs --remove -subscriber=second dummy subscriber name 

---

How to Downgrade the Subscriber Manager

This section describes the procedure to downgrade the SM to a previous version.

---

Step 1 Perform the uninstall procedure described in the Cisco Service Control Management Suite Subscriber Manager User Guide, the Installing and Upgrading chapter, the "How to Uninstall the Subscriber Manager" section.

Step 2 Perform the installation procedure described in the Cisco Service Control Product Installation Guide, the "Installing the Subscriber Manager" section.

---

Note The upgrade-sm.sh and cluster-upgrade.sh upgrade scripts do not support SM downgrade.

---

---

4 Upgrading the Collection Manager

This chapter describes the procedures for upgrading the collection manager (CM).

When upgrading a complete system, it is recommended to install a second CM running the new version and then simply uninstall the CM running the previous version, thereby providing a seamless transition to the new version. In this case, no upgrade procedure is run on the CM.

To install the CM, see the Cisco Service Control Product Installation Guide, the "Installing the Collection Manager" section.

How to Upgrade the Collection Manager to Version 3.5.0

---

Step 1 Get the CM software as described in the Cisco Service Control Management Suite Collection Manager Quick Start Guide.

Step 2 Change directory to install-scripts under the distribution kit root.

Step 3 As the scmscm user, stop the CM server

$ ~scmscm/cm/bin/cm stop

Step 4 As the root user, run the install-cm.sh script

# ./install-cm.sh -o

Step 5 As the scmscm user, start the CM server

$ ~scmscm/cm/bin/cm start

---

Note If you upgrade from version 3.0.5 or 3.0.6, the PRPC users file is deleted. You must log in to the CM and redefine the PRPC users.

---

---

Verifying that the Server is Operational

To verify that the server is functioning correctly, use the alive.sh script:

~scmscm/setup/alive.sh

The script verifies that the following components are operational:

•Collection Manager

•Database (in the bundled database case)

•Report tables (in the bundled database case)

If any component is down, the script issues an error message.

---

Step 1 As the scmscm user, run the alive.sh script

---

Note It takes time for the components to initialize after a startup; after a restart, wait five minutes before running this script.

---

---

5 Upgrading the SCE Platform Software

This chapter describes the wizard that upgrades the SCE platform software.

The console SCE Software Upgrade Wizard performs a software upgrade on one or more SCE platforms. The wizard allows you to select the following:

•The SCE platforms to be upgraded.

•The firmware (pkg) version to upgrade to.

•The application (pqi) version to upgrade to.

•The service configuration (pqb) to apply.

•The protocol pack (spqi) to apply.

Before You Start

Before you begin the SCE platform upgrade, make sure you do the following:

•Gather the IP addresses of all SCE platforms to be upgraded. (Not necessary if they are all defined in the Network Navigator)

•Download the relevant pkg file, pqi file, and protocol pack to a local location or to a location accessible by FTP. If using an FTP site, make sure to have the complete FTP location and path for each file.

•Decide what service configuration will be used:

–Default service configuration: a default pqb file will be created and applied to each SCE platform.

–Current service configuration: the current service configuration will be retrieved before the upgrade and then re-applied after the upgrade is complete.

–Other: specify the desired pqb file to be applied.

How to Upgrade the SCE Platform Software

---

Step 1 In the Network Navigator of the console, select the SCE platforms to be upgraded. Right-click and from the menu, select SCE Software Upgrade Wizard.

The SCE Software Upgrade Wizard opens.

Step 2 In the SCE IP Addresses screen, verify that the IP addresses of all the SCE platforms to be upgraded appear. If any do not appear, type them in.

Step 3 In the SCE Usernames and Passwords screen, enter the username and password required to access the SCE platform. You may use the same username and password for all the platforms or enter a different username and password for each platform.

Step 4 The Connectivity Test screen shows the results of the attempts to connect to all the SCE platforms on the list. This step verifies that all SCE platforms can be connected to for upgrade.

Step 5 In the SCE Firmware (PKG) Installation screen, specify the location of the pkg file to be installed on all the selected SCE platforms.

Step 6 In the SCE Application Software (PQI) Installation screen, specify the location of the pqi file to be installed on all the selected SCE platforms.

Step 7 In the Protocol Pack (SPQI) Update screen, specify the location of the protocol pack to be installed on all the selected SCE platforms.

---

Note The version of the Protocol Pack you install during the upgrade must be greater or equal to that of the Protocol Pack you are upgrading from.

---

Step 8 In the Service Configuration (PQB) Update screen, select the service configuration to be applied to the SCE platforms:

•Current service configuration: the current service configuration will be retrieved before the software upgrade and then re-applied after the upgrade is complete.

•Default service configuration: a default pqb file will be created and applied to each SCE platform.

•Other: specify the desired pqb file to be applied.

Step 9 The next screen summarizes all the information. Verify that all the IP addresses and file locations are correct.

•Click Back to edit any information.

•Click Finish to begin the upgrade process as specified.

This system checks the following:

•The specified SCE platforms can be located by supplied IP addresses.

•If the PKG and/or PQI files are located at the remote FTP server, its availability will be verified.

•Supplied credentials are valid for all SCE platforms.

•Specified PKG, PQI and PP and PQB versions comply.

If the user requested that any of these components not be upgraded (selected Skip for any file), the version of those files will be retrieved from SCE platform for this verification. For instance, if user requested to skip PKG installation and install PQI version 3.5.0, version information about the currently installed PKG file will be retrieved. (If this is SCOS 3.1.5, an error will be reported.)

A list of all problems and errors is displayed when the verification process is complete.

The basic steps being performed during the upgrade are as follows (assuming all components are upgraded):

•Retrieve the current service configuration fro mthe SCE platform (only if the current service configuration is going to be re-installed after the upgrade).

•Uninstall the existing application software (PQI)

•Upgrade SCE platform firmware (PKG)

•Install application software (PQI)

•Apply service configuration (PQB)

•Install the protocol pack (SPQI)

The specified SCE platforms are upgraded simultaneously, with the upgrade process for each SCE platform running in separate thread.

Step 10 The system keeps you informed of the progress of the upgrade.

Click Run in Background to run the upgrade in the background.

The upgrade runs in the background as shown in the following figure.

---

Upgrading Cascaded SCE Platforms

In a high availability deployment a pair (or pairs) of SCE platforms are cabled in a cascaded setup, providing SCE platform redundancy. This type of a deployment requires the following steps whenupgrading.

---

Step 1 Select the standby SCE platform or platforms in the SCE Software Upgrade Wizard.

Step 2 When the upgrade is complete, force failure in all the active SCE platforms:

SCE> enable 10

<passworc>

SCE# config

SCE(config)#interface linecard 0

SCE(config if)# force failure-condition

This makes the updated SCE platforms the active ones, and they begin to give the new service.

Step 3 Run the SCE Software Upgrade Wizard again, this time selecting the remaining SCE platforms, which were originally the active platforms and now are the standby SCE platforms.

Make sure to specify the same upgrade files that you used in Step 1.

Since this includes a reboot, it is not necessary to undo the force failure command.

---

6 Upgrade Procedure Limitations

SCE Platform

Link Downtime Due to LIC Re-Burning

Link downtime is expected during SCE platform upgrade (the LIC chip firmware is reburned). The expected downtime depends on the system's auto-negotiation configuration, and can be up to one minute.

Misclassification of Flows Initiated Prior to Upgrade Completion

Flows that were initiated prior to upgrade completion can be misclassified. Gradual classification restoration is expected when SCE software upgrade is completed, or when a standby SCE becomes active. This reclassification is needed because the flow's previous classification decision is lost. This reclassification would usually be inaccurate because an accurate classification depends on analyzing the beginning of the flow. Therefore, the flow would usually be reclassified according to the corresponding Generic or Behavioral signature. This downtime ends when all these reclassified flows are closed.

Service Downtime

Service downtime is expected during SCE platform upgrade on non-High Availability setups and on High Availability setups.

•On non-High Availability setups, the SCE platform does not perform traffic classification, reporting, and control during the SCE platform upgrade. These capabilities are restored after upgrade completion (restoration is gradual, due to misclassification of traffic flows that were initiated prior to upgrade completion). See Misclassification of Flows Initiated Prior to Upgrade Completion for further information.

•On High Availability setups, service downtime is not expected (as the cascaded SCE platforms alternate on upgrade), except for gradual service buildup when switching SCE platforms due to misclassification of traffic flows that were initiated prior to upgrade completion. See Misclassification of Flows Initiated Prior to Upgrade Completion for further information.

Loss of Aggregated Unreported Data

During SCE platform upgrade subscriber quota and usage information maintained in the SCE platform that was not reported to a collection system is lost. Depending on the system data export frequency (configurable through periods between RDRs of all sorts), the amount of such information can be kept to a minimum.

This is true also for High Availability configurations.

Loss of Configuration

Any non-default assignments of RDR tags to categories are lost when upgrading; the default mapping is restored after the upgrade. If any non-default assignments were made, you should reconfigure them manually after the upgrade.

SCA BB Clients and Service Configuration

SCA BB Console, which incorporates the service configuration editor, SM GUI, and Reporter, is not backward compatible and can work only with the 3.5.0 system components (SCE platform, CM, SM).

SCA BB Console Interoperability

Version 3.5.0 of the Network Navigator cannot apply service configurations to previous versions of the SCE platforms. Nevertheless, the Network Navigator 3.5.0 can upgrade the SCE platform to 3.5.0, and then service configurations can be applied.

Reporter and DB Interoperability

The Reporter and Reporter Templates of 3.5.0 can be used to create reports from an earler-version database, provided that the same reports existed in the eariler version. However, reports that are new in 3.5.0 cannot be created when connecting to an earler-version database.

Running Two SCA BB Consoles or Reporters

Running two SCA BB Consoles or Reporters of different versions on the same machine is not supported and should be avoided.

Subscriber Manager

In non-High Availability Subscriber Manager setups, the SM upgrade procedure causes downtime for subscriber provisioning and subscriber status awareness (LEG communication).

Quota Manager

If the QM is not deployed as a cluster, service downtime is expected. This is the same service downtime that is expected during an SM upgrade.

Collection Manager

Upgrading the Collection Manager imposes downtime for the upgraded machine during the entire process. To avoid data collection downtime, an alternate Collection Manager can be used (for either bundled or unbundled configurations).

Sending RDRs to an alternate Collection Manager is supported by the SCE platform.

Configuration

When upgrading the CM to 3.5.0, the users configuration on the CM server (the PRPC users file, prpc.usr) is deleted. It is necessary to redefine the users after the upgrade is completed.

7 Obtaining Documentation and Submitting a Service Request

For information on obtaining documentation, submitting a service request, and gathering additional information, see the monthly What's New in Cisco Product Documentation, which also lists all new and revised Cisco technical documentation, at:

http://www.cisco.com/en/US/docs/general/whatsnew/whatsnew.html

Subscribe to the What's New in Cisco Product Documentation as a Really Simple Syndication (RSS) feed and set content to be delivered directly to your desktop using a reader application. The RSS feeds are a free service and Cisco currently supports RSS Version 2.0.

CCDE, CCENT, Cisco Eos, Cisco HealthPresence, the Cisco logo, Cisco Lumin, Cisco Nexus, Cisco StadiumVision, Cisco TelePresence, Cisco WebEx, DCE, and Welcome to the Human Network are trademarks; Changing the Way We Work, Live, Play, and Learn and Cisco Store are service marks; and Access Registrar, Aironet, AsyncOS, Bringing the Meeting To You, Catalyst, CCDA, CCDP, CCIE, CCIP, CCNA, CCNP, CCSP, CCVP, Cisco, the Cisco Certified Internetwork Expert logo, Cisco IOS, Cisco Press, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Cisco Unity, Collaboration Without Limitation, EtherFast, EtherSwitch, Event Center, Fast Step, Follow Me Browsing, FormShare, GigaDrive, HomeLink, Internet Quotient, IOS, iPhone, iQuick Study, IronPort, the IronPort logo, LightStream, Linksys, MediaTone, MeetingPlace, MeetingPlace Chime Sound, MGX, Networkers, Networking Academy, Network Registrar, PCNow, PIX, PowerPanels, ProConnect, ScriptShare, SenderBase, SMARTnet, Spectrum Expert, StackWise, The Fastest Way to Increase Your Internet Quotient, TransPath, WebEx, and the WebEx logo are registered trademarks of Cisco Systems, Inc. and/or its affiliates in the United States and certain other countries.

All other trademarks mentioned in this document or website are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (0812R)

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

© 2009 Cisco Systems, Inc. All rights reserved.