Cisco Cisco Packet Data Gateway (PDG) Ratgeber Für Administratoren
Software Management Operations
Upgrading the Operating System Software ▀
Cisco ASR 5000 System Administration Guide ▄
131
Downgrading from Release 15.0 to 14.0
Release 14 and Release 15 chassis IDs use different encryption formats. Release 15 will recognize a Release 14 chassis
ID and consider it as valid. Upgrading from 14.x to 15.0 will not require changing the chassis ID or configuration file.
ID and consider it as valid. Upgrading from 14.x to 15.0 will not require changing the chassis ID or configuration file.
However, if the chassis key is reset in Release 15 through the setup wizard or chassis-key CLI command, a new chassis
ID will be generated in Release 15 format (44 instead of 16 characters). Release14 builds will not recognize the 44-
character chassis ID. If the chassis is subsequently downgraded to Release 14, a new 16-character chassis ID will be
generated. To accommodate the old key format, you must save the configuration file in pre-v12.2 format before the
downgrade. If you attempt to load a v15 configuration file on the downgraded chassis, StarOS will not be able to
decrypt the password/secrets stored in the configuration file.
ID will be generated in Release 15 format (44 instead of 16 characters). Release14 builds will not recognize the 44-
character chassis ID. If the chassis is subsequently downgraded to Release 14, a new 16-character chassis ID will be
generated. To accommodate the old key format, you must save the configuration file in pre-v12.2 format before the
downgrade. If you attempt to load a v15 configuration file on the downgraded chassis, StarOS will not be able to
decrypt the password/secrets stored in the configuration file.
Software Upgrade Methods
Occasional software upgrades are required to add features and/or functionality, and to correct any previous defects.
There are two software upgrade methods used to add features, functionality, and correct known software defects. They
are:
There are two software upgrade methods used to add features, functionality, and correct known software defects. They
are:
A brief overview accompanies each upgrade procedure.
On-Line Software Upgrade
This method is used to perform a software upgrade of the entire operating system.
Important:
This method is not supported for the SGSN or for PDIF. Refer to the appropriate Administration
Guide for upgrade information.
This method allows active sessions to be maintained until they are either self-terminated (subscriber ends session) or
meet the optionally defined upgrade limit values.
meet the optionally defined upgrade limit values.
This method upgrades all standby packet processing cards simultaneously, then upgrades any active cards
simultaneously.
simultaneously.
No new sessions will be accepted by the system during an on-line software upgrade. For PDSN and GGSN: All new
session requests are blocked from entering the system through the use of an overload policy. Failure to configure this
policy to redirect calls elsewhere can result in a significant service outage.
session requests are blocked from entering the system through the use of an overload policy. Failure to configure this
policy to redirect calls elsewhere can result in a significant service outage.
Caution:
To minimize the risk of service outages, the on-line software upgrade should be performed during a
planned maintenance window.
An on-line software upgrade is performed in five stages, where each stage is limited to performing only specific
functions until the system is prepared to move to the next stage. Each stage is explained below.
functions until the system is prepared to move to the next stage. Each stage is explained below.