|
|
Table Of Contents
Upgrade Objectives and Limitations
Supported Working Configurations
SCA BB Clients and Service Configuration
Upgrade Objectives and Limitations
This module compares the objectives of the upgrade procedure with the limitations that can be expected for each component throughout this process.
•
Supported Working Configurations
•
Upgrade Objectives
Generally, upgrade procedures aim for the following objectives for the entire solution:
•
•
•
•
•
•
•
•
Some of these objectives are achieved through maintaining interface compatibility; for example, CSV files, RDRs, DB schemes, and CLI retain compatibility. Programmable interfaces retain binary compatibility or interface compatibility (for static C linking).
Not all requirements are met on each perspective of the solution. Limitations with respect to these objectives are mentioned in the following sections and in the relevant component manuals.
Supported Working Configurations
The SCA BB 3.1 solution supports a combination of component versions:
•
•
•
•
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.
SCE Platform
Upgrade Procedure Limitations
•
•
•
Link Downtime Due to LIC Re-Burning
When upgrading from 3.0.0 only: 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.
•
•
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.1 system components (SCE platform, CM, SM).
Upgrade Procedure Limitations
•
•
•
•
SCA BB Console Interoperability
Version 3.1 of the Network Navigator cannot apply service configurations to version 3.0 SCE platforms. Nevertheless, the Network Navigator 3.1 can upgrade the SCE to 3.1, and then service configurations can be applied.
Service Configuration Upgrade
Older Service Configuration files need to be adapted to SCA BB 3.1 prior to applying them to the upgraded system. This can be done in one of two ways:
•
•
User Defined Signatures
If you created a DSS in the Signature Editor and want to install a protocol pack, you need to merge the DSS with the signatures in the protocol pack by performing the following general steps:
•
•
•
Reporter and DB Interoperability
The Reporter and Reporter Templates of 3.1 can be used to create reports from a 3.0 database provided that the same reports existed in 3.0. However, reports that are new in 3.1 cannot be created when connecting to a 3.0 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
•
Upgrade Procedure Limitations
In non-High Availability Subscriber Manager setups, the SM upgrade procedure causes downtime for subscriber provisioning and subscriber status awareness (LEG communication).
LEG Configuration
The configuration of the SM LEGs is lost during the upgrade. Follow the upgrade procedure of the SM LEGs in the relevant reference guide.
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
•
Upgrade Procedure Limitations
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 from 3.0.5 or 3.0.6 to 3.1, 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.
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
Posted: Thu Aug 23 16:28:46 PDT 2007
All contents are Copyright © 1992--2007 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.
