When an SBC SWe cluster is operating in Direct Single configuration mode, the active SBC node saves configuration revisions on
. A new revision number is defined after you explicitly save and activate a set of configuration changes. You have the option to restore the cluster configuration back to a prior revision level, when necessary.
Note |
---|
|
- Reverting the SBC SWe cluster to a prior configuration revision requires all SBC nodes to reboot, which is service-impacting.
- If the SBC needs to be restored to a prior configuration, make sure that the configuration includes server information for both the active and standby SBC (the configuration created after both the active and standby SBC were synchronized).
|
Restoring a Prior Configuration using RAMP
From
, you can review a list of stored revisions. Each revision is identified by a revision number and a timestamp when the configuration was created.
Restoring a prior configuration requires the SBC nodes to restart.
Note that if revision you specify to restore was created with a different software release, the nodes do not restart automatically. If you are migrating an older revision to a newer software version, you can restart manually to complete the restore process. If you are preparing to upgrade/downgrade, you can rebuild with the software that is at the same release level of the specified revision.Prerequisites
Before performing a restore operation, ensure that the SBC node that has the "primary" role also has its management redundancy role specified as “active.” If the primary node has the role of "standby," you must perform a switchover so that the primary node becomes active.
Restore Configuration Procedure
Prior to executing a configuration restore on the
, you must stop the SBC application on the standby node. After the restore operation is complete you must start the SBC application again on the standby node. Use the EMA GUI to stop and start the standby node.
- On the standby SBC node, log into the EMA.
- Navigate to the platform management controls: Administration > System Administration > Platform Management
The Platform and SBC Application Controls window opens. - Click Stop SBC Application at the top of the Status section.
- Log onto the .
- Click Network > Cluster Management. The Cluster Management / Manage VNFs window opens listing the SBC clusters on the .
- Click the radio button adjacent to the name of the cluster. The Details tab for the selected cluster opens by default.
Click the Configuration History tab. A list of the stored configuration revisions opens.
![](/download/attachments/372563846/DirectSingleHistory.png?version=1&modificationDate=1681498314687&api=v2)
- Click the Restore icon adjacent to a revision to revert the cluster to the configuration that was in place when the selected revision was saved and activated. The active node downloads the selected configuration revision and reboots.
After the active node completes rebooting and initializing, return to the Platform and SBC Application Controls window in the EMA of the standby node and click Start SBC Application.
Once the standby node restarts, the restore configuration procedure is complete.
Restoring a Prior Configuration using SBC Core CLI
The CLI request
command's restoreRevision
parameter reverts the configuration on managed SBC nodes to a specified prior configuration revision. Similar to when a revert is triggered from , restoring a prior configuration requires the SBC nodes to restart.
Note that if revision you specify to restore was created with a different software release, the nodes do not restart automatically. If you are migrating an older revision to a newer software version, you can restart manually to complete the restore process. If you are preparing to upgrade/downgrade, you can rebuild with the software that is at the same release level of the specified revision.
The basic command syntax is shown below.
Code Block |
---|
> request system admin <SYSTEM NAME> restoreRevision revision <revision number> |
Prerequisites
Before performing a restore operation, ensure that the SBC node that has the "primary" role also has its management redundancy role specified as “active.” If the primary node has the role of "standby," you must perform a switchover so that the primary node becomes active.
- Log into one of the nodes and execute the following command and check the output to identify which node has the "ROLE" of "primary."
show table system serverAdmin
- Execute the following command and check the output to determine the "MGMT REDUNDANCY ROLE" of the primary node:
show table system serverStatus
- Continue with the restore procedure if the redundancy role of the primary node is "active." Otherwise, execute the following command to switch the redundancy roles of the nodes:
request system admin <SYSTEM NAME> switchover
Repeat the show table system
commands to confirm that the primary node has the active redundancy role.
Restore Configuration Procedure
Prior to executing the restore
command on the active node, you must stop the SBC application on the standby node. After the restore operation is complete you must start the SBC application again on the standby node. Use the EMA GUI to stop and start the standby node.
- On the standby SBC node, log into the EMA.
- Navigate to the platform management controls: Administration > System Administration > Platform Management
The Platform and SBC Application Controls window opens. - Click Stop SBC Application at the top of the Status section.
- From the CLI of the active node, execute the restore command:
request system admin <SYSTEM NAME> restoreRevision revision <revision number>
where <revision number>
identifies the number of the revision you want to restore. The active node reboots as part of the restore process.
After the active node completes rebooting and initializing,return to the Platform and SBC Application Controls window in the EMA of the standby node and click Start SBC Application.
Once the standby node restarts, the restore configuration procedure is complete.