In this section:
Caution
No system configuration changes should be made during an upgrade. If such a change is made, this change is not included in the new software release; therefore, the system may not behave as expected.
Warning
Upgrading from more than 2 previous major releases is not supported. For example, the minimum requirement to upgrade to DSC 21.0 is DSC 18.0.
Preparation Tasks
Before you start the software upgrade, it is assumed that you have completed the following tasks:
| Task | Procedure |
|---|---|
Familiar with using the Ribbon DSC Platform Menu-based user interface (Menu UI). | |
It is recommended that you upgrade the software when the traffic levels are low to avoid the risk of triggering network congestion on the active system. | |
| If you have to reset the system date and time, it is recommended that you perform this task during the maintenance window. | DSC - SP2000 Platform Manager User Guide |
Have sufficient permissions to log onto the system as root user. | |
Request the new software load from the Global Support Portal. The information to obtain the software upgrade package is provided with the release notes. Note
The application software is referred to in this document as DSC SWe - vSP2000 software. DSC SWe - vSP2000 refers to both the DSC SWe Platforms and the vSP2000 Platform. | |
Plan the maintenance window. Plan for sufficient time to complete the upgrade. The upgrade depends on the number of VMs on the hardware platform. Each VM upgrade requires about 10 minutes. | |
Ensure that the network is provisioned as required. | Network Provisioning |
Verify the system status and health. Performing this task ensures that possible problems occurring during the software upgrade are not caused by a pre-existing condition. Verify that all system VMs are functioning as expected prior to starting. | Collect Common System Status Information |
Execute a complete system backup and stored the backed up files on another server or a USB key that is accessible. It is recommended to make backup copies of system files, including the /shared/stats and /shared/log files, prior to starting the upgrade. Forward the backup files to a safe and secure remote server for later retrieval, if needed. In the event an upgrade fails, the system may not be recoverable without restoring the system backup files. | For more information about system backups, refer to the appropriate sections in the DSC - SP2000 Platform Manager User Guide. |
Verify that the PCE configuration is ready for a software upgrade. Note: This step is only applicable if you have PCE licensed on your system. | Verifying the PCE Configuration |
Network Provisioning
It is assumed that your system and the Routing IP Network are properly provisioned with no single point of failure before starting the upgrade (see the following table)
System Requirements Prior to a Software Upgrade
| Item | Description |
|---|---|
Ribbon DSC SWe - vSP2000 Mated Pair Configuration | The network comprises a pair of VMs on a hardware platform in a mated pair configuration. This configuration enables one VM to process traffic (active system) while the other VM is being upgraded (standby system). |
| Routesets1 | Routesets within the active system must specify the routes that are unaffected by the outage during the software upgrade. |
| Linksets1 | There are enough links to manage the traffic load from a specific node to each VM in the mated pair configuration. Locations that have linksets to a single VM may experience an outage. |
| Load Levels | Traffic should be diverted to one VM in the mated pair configuration during the software upgrade. It is assumed that your system is capable of handling the increased traffic on this VM. To make sure that your system is capable of managing the increased traffic on the active system, monitor the following:
|
1 The DSC Platform supports SS7 and Diameter traffic.
Plan the Maintenance Window
It is assumed that you have standard procedures for system maintenance and that the person performing the software upgrade is qualified to perform this procedure. The following should be considered while planning a maintenance window:
- network activities that are taking place during the software upgrade
- soak time before beginning a new network change
- service usage irregularities such as phone-in contests
- availability of operations staff
- availability of vendor’s support staff
- availability of support staff in network operations centers (NOCs) that are connected to your system
- seasonal issues such as Christmas brown-out periods of network changes
- NOC expert staff vacation schedules
Customer Support provides emergency support to customers who have a support agreement. However, it is recommended that you notify this group about one week prior to planning a maintenance window for a software upgrade. For information, refer to Customer Support.
It is recommended that the NOC tests its maintenance window procedures prior to the software upgrade. Such a test is rebooting the system with the existing software and hardware. This process allows the NOC staff to test the maintenance window procedures and isolate any existing problems prior to the software upgrade. To perform this test in its entirety, notifications may have to be sent to the locations that are affected by the maintenance window.
If you have off-site systems for spare hardware purposes, you should consider upgrading these systems as disaster recovery, lab, and training sites. If such a system is available, the training for software upgrade and rollback should take place on this system. Make sure to note the required time for each process.
Example Maintenance Procedure
The following is an example of a software upgrade document:
DSC SWe on VMware Software Upgrade
CLLI: wesott234top
Maintenance Window Times:
- Start: 30 November 2013 23:00 EST
- Late Stop: 1 December 2013 03:00 EST
- Expected Stop: 1 December 2013 00:30 EST
Expected stop refers to the time when a software upgrade that is executed without any problems should be completed. Late stop refers to the time when an aborted upgrade with software rollback to the previous software version is completed.
Example Schedule for a Software Upgrade
The following table provides an example schedule for a software upgrade.
| Item | Expected Completion |
|---|---|
| Approval of the maintenance window for software upgrade plan | November 15 |
| Notification to connected NOCs1 | November 23 |
| Notification to various departments affected by this event (Billing, Marketing, and so on) | November 23 |
| Dry-runs in lab | Week of November 23 |
| Backup system | November 30, 22:00 |
| Review system status | November 30, 22:15 |
| Call NOCs and connected networks2 | November 30, 23:45 |
| Perform software upgrade according to Ribbon instructions | 00:00 |
Bring up SS7 links on standby Ribbon DSC Platform in the mated pair configuration | 00:15 |
| Call NOCs and connected networks | 00:30 |
| Review system status and test service | 01:00 |
| Backup systems |
1 Providing the NOCs and connected networks one week in advance to the software upgrade gives them an opportunity to advise you of any activities they may have that could hinder the software upgrade.
2 It is recommended that you contact the NOCs and connected networks prior to bringing down the SS7 links. Performing this task generates alarms
Collect Common System Status Information
Verify the system status and health before a software upgrade. Performing this task ensures that possible problems occurring during the software upgrade are not caused by a pre-existing condition. It is recommended that you verify the following:
- all SS7 links are up
- all routesets are up and are active
- all VNodes are active
- ptisyslog and ptidbglog contain no irregular messages
- Earlang monitoring on all links
- GTT configuration
- PCE configuration
- MTP L4 connections
- SCCP connections (if using TCAP)
Note
Make sure to note any irregularities while verifying the information in the preceding list.
To assist you in collecting the system status and health information, some forms are provided for recording the results (refer to Status Verification Before Upgrade or Service Pack Installation)
System Backup
Before and after any major system operation, it is good practice to perform a complete system backup. For security, the recommended procedure is to forward the backed up files to a remote server for retrieval. Typically, these backup files are not required during the upgrade process, but are needed in case of problems that may occur during the upgrade process, or if you decide to abort the software upgrade.
Note
The system OS and configuration files may change between software upgrades.
To ensure that there is enough disk space to perform a complete system backup, remove all existing backup files from each system that is to be upgraded before you perform a complete system backup.
For more information about system backups, refer to the SP2000 Backup and Restore.
Overview
Content Tools