Pre-upgrade steps:
At least seven days prior to starting the upgrade, accomplish the following tasks.
1. Verify existing software version of SBC
Refer to
2. Check Product Release Interoperabilities
If other Ribbon Core elements are integrated with the SBC, ensure they are running a version compatible with the target SBC load according to
3. Verify Bulletins and Warnings (WBAs)
Examine all Warnings/Bulletins/Announcements listed in the "Associated Ribbon Announcements" section for the target release
to verify they are applicable to the upgrade path in the Ribbon support portal. Log on to the to view WBA details.Besides Warnings/Bulletins/Announcements listed in Release Notes, log on to the Ribbon Support Portal and verify all Warnings/Bulletins applicable to the upgrade path.
4. Review Release Notes (RNs)
Review RNs for SBC configuration requirements to implement prior to the upgrade.
Some examples are SWe HW configuration requirements and memory requirements for SBC 51xx and 52xx systems, depending on target release and username requirements.
5. Prepare Software
Review the target RN "Required Software and Firmware Versions" for the required firmware and application software files required for the upgrade.
Transfer SBC application software to the SBC. Refer to the section
.After transferred, please change file permission of the downloaded files to 'rwxrwxrwx' by running this command as user root:
chmod 777 /opt/sonus/external/sbc-V*
Follow
steps to confirm the downloaded files include the correct checksum, or validate md5sum directly on the SBC servers after the software is transfered.
6. Verify call arrival rate and maximum number of active calls during upgrade
Call arrival rate limits are enforced during upgrade.
Verify the system call arrival rate (systemCongestionCallArrivalRate) using the following CLI command. The maximum call rate allowed for Live Software Upgrade (LSWU) differs between various SBC platforms.
For more information, refer to
Example:admin@WFDSBC01a> show status system systemCongestionStatus systemCongestionStatus entry {
systemCongestionMCLevel 0;
systemCongestionCPULevel 0;
systemCongestionMemLevel 0;
systemCongestionCallRateLevel 0;
systemCongestionMCDuration 67397;
systemCongestionCallArrivalRate 355;
systemCongestionCallAcceptRate 100;
systemCongestionCallAcceptCount 0;
systemCongestionCallEqArrivalRate 355;
systemCongestionRegArrivalRate 0;
systemCongestionIRTTLevel 0;
}
7. Check alarms
Ensure that no Critical/Major alarms are present prior to the upgrade, unless they are confirmed as non-impacting.
To check alarms via EMA:
Login to EMA on the active server, and navigate to: Monitoring -> Dashboard -> Alarms -> Current alarms.
For earlier versions of EMA (4.x):
Login to EMA on the active server, and navigate to: Troubleshoot -> Alarms -> Current.
To check alarms via CLI:% show table alarms currentStatus
8. Check disk space requirements
For upgrades to 05.xx.xx:
Refer to Hard disk usage requirements for upgrading to V05.xx.xx
For upgrades to 06.xx.xx or higher releases:
Maximum of 70% used and at least 3G free space on '/' partition
Maximum of 80% used and at least 7G free space on '/home' partition
Maximum of 70% used and at least 7G free space on '/dev/drbd0' partition (active node only)
9. Check disk speed requirements
This step is applicable ONLY for hardware SBCs.
To check for disk speed, run hdparm -t --direct rootDisk.
Example:
[root@example.org ~]# hdparm -t --direct /dev/sda /dev/sda: Timing O_DIRECT disk reads: 584 MB in 3.01 seconds = 193.85 MB/sec [root@example.org ~]#
To obtain the root disk, perform the following command as root:
cat /proc/partitions 2> /dev/null | awk '$2 == 0 { print $NF }' | grep -Ev "dm-0|sr0|drbd0|fd0"
The rootDisk partition is /dev/ followed by the output of the command above.
SSD minimum speed is 100 MB/s. The upgrade will abort and fail if SSD speed falls below this threshold.
10. Verify the SBC platform is running in redundant mode (for HA systems)
Use the "show table system serverStatus" CLI command, and confirm "MGMT REDUNDANCY ROLE" shows active/standby:
Example (shortened for brevity):
admin@LABNBS2A> show table system serverStatus
MGMT
PLATFORM APPLICATION REDUNDANCY APPLICATION UP LAST RESTART
NAME HW TYPE SERIAL NUM PART NUM VERSION VERSION ROLE UP TIME TIME REASON SYNC STATUS
------------------------------------------------------------------------------------------------------------------------------------------------------
LABNBS2A SBC 5200 2038100494 821-00430 V06.02.03R000 V06.02.03R000 active 21 Days 21:59:38 21 Days 21:50:18 systemRestart syncCompleted
LABNBS2B SBC 5200 4031110016 821-00430 V06.02.03R000 V06.02.03R000 standby 10 Days 00:14:02 10 Days 00:12:00 systemRestart syncCompleted
11. Verify the sync status
Use the "show table system syncStatus" CLI command.
Example for HA systems:
admin@LABNBS2A> show table system syncStatus SYNC MODULE STATUS --------------------------------------- Policy Data syncCompleted Disk Mirroring syncCompleted Configuration Data syncCompleted Call/Registration Data syncCompleted
Example for Standalone systems:
admin@LABSTD> show table system syncStatus SYNC MODULE STATUS ------------------------------------- Policy Data unprotected Disk Mirroring unprotected Configuration Data unprotected Call/Registration Data unprotected
12. Verify that at least one management port is in admnEnabledPortUp state on each server
Use the show table system ethernetPort mgmtPortStatus CLI command:
Example:
admin@LABNBS2A> show table system ethernetPort mgmtPortStatus
PORT IF RX TX RX TX RX TX
CE NAME NAME INDEX MAC ADDRESS LINK STATE PACKETS PACKETS ERRORS ERRORS DROPPED DROPPED
-------------------------------------------------------------------------------------------------------------------
LABNBS2A mgt0 1 0:10:6b:2e:e7:91 admnEnabledPortUp 27189224 2115956 0 0 0 0
LABNBS2A mgt1 2 0:10:6b:2e:e7:92 admnEnabledPortUp 7474875 45345 0 0 0 0
LABNBS2B mgt0 3 0:10:6b:2:ee:76 admnEnabledPortUp 34677 354 0 0 0 0
LABNBS2B mgt1 4 0:10:6b:2:ee:77 admnEnabledPortUp 35362 425 0 0 0 0
13. Verify if the system and the databases are in sync with each other
The steps to accomplish this check are included in .
14. System uptime check
14.1 For SBC SWe
Check how many days the SBCs are up ('UP TIME') using the following CLI command.
Example (shortened for brevity):
admin@SWE1> show table system serverStatus
MGMT
PART PLATFORM APPLICATION REDUNDANCY APPLICATION UP
NAME HW TYPE SERIAL NUM NUM VERSION VERSION ROLE UP TIME TIME
--------------------------------------------------------------------------------------------------------------------------------------------
SWE1 Sonus SBC SWe 15AF4D56-2731-4822-F9AA-BBCCDD62C816 - V06.01.00R001 V06.01.00R001 active 9 Days 00:14:03 9 Days 00:11:56
SWE2 Sonus SBC SWe 4F874D56-1403-209B-E224-1D84F5C99A7C - V06.01.00R001 V06.01.00R001 standby 9 Days 00:11:09 9 Days 00:07:01
If SBCs are up for more than 200 days, reboot the servers prior to upgrade. Reboot the standby SBC first. Then once the SBCs are back in sync again, switchover the SBC application and reboot the newly standby SBC.
14.2 For SBC5XX0/SBC7000
Check how many days the BMC is up using 'uptime' command on BMC ssh session.
If the BMC is up for more than 90 days, reboot the BMC prior to the upgrade according to the steps below, depending on the BMC version.
14.2.1. SSH to the SBC associated to the standby BMC as root user and ensure is standby:
sbxstatus | grep 'Service running'
** Service running [standby] **
14.2.2. Stop the server on standby SBC, as root user:
sbxstop
14.2.3. Power off the server via BMC GUI:
Remote Control -> Server Power Control -> Power Off Server - Orderly Shutdown -> Perform Action
14.2.4. Ensure after Orderly Shutdown, server is showing 'Host is currently off' on BMC:
BMC Remote Control -> Server Power Control ("Power Control" in 2.x BMC versions) window
14.2.5. ssh to the BMC and verify that the SBC is powered off by running the following command.
For BMC versions 2.x and higher, you must enable ssh access in BMC GUI > Configuration > Network ("BMC Network" in 2.x BMC versions):
ipmitool -H127.0.0.1 -Uroot -Psuperuser power status
The output of the above command should read "Chassis Power is off".
If your BMC ssh root password is not default, change the '-P' parameter value in the above command, accordingly.
14.2.6. Reboot the BMC:
For BMC versions 2.x, reboot the BMC via the GUI: Maintenance -> Reboot BMC.
For other BMC versions, run "reboot" command on the BMC ssh session.
14.2.7. The BMC will come back after 2 min and the system will boot back to standby mode.
Ensure the following:
- Access to the BMC GUI and remote console is successful (prompt is available)
- SBC is back at standby.
- SBCs are in sync (show table system syncStatus via CLI)
14.2.8. Switchover the SBC application and repeat steps 14B.1 - 14B.7 to the newly standby SBC / BMC.
15. Verify System Name and hostname
System name and hostnames (ceName/peerCeName for HA) can only contain alphanumeric or dash characters, must begin with a letter and cannot end in a dash.
Obtain the System name from the sbx.conf file: /opt/sonus/conf/sbx.conf file.
For earlier releases, the file location is: /opt/sonus/sbx.conf
Example (shortened for brevity):
[root@LABNBS2A ~]# cat /opt/sonus/conf/sbx.conf # SBX startup configuration. # # Copyright (c) 2010 Sonus Networks, Inc. # All rights reserved. # # Configuration generated by sbxInit.sh: # Thu Oct 31 15:59:03 CET 2019 role=1 # 1=Active, 2=Standby systemName=LABNBS2 ceName=LABNBS2A peerCeName=LABNBS2B
16. Confirm no USB or mounted devices are present on the SBC prior to the upgrade to avoid upgrade issues
Overview
Content Tools