In this section:
When an SBC SWe cluster is operating in Direct Single configuration mode, the active SBC node saves configuration revisions on RAMP. 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.
From RAMP, 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.
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.
Click the Configurations tab.
Prior to executing a configuration restore on the RAMP, 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.
Click the Configuration History tab. A list of the stored configuration revisions opens.
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.
The CLI
command's request
restoreRevision
parameter reverts the configuration on managed SBC nodes to a specified prior configuration revision. Similar to when a revert is triggered from RAMP, 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.
> request system admin <SYSTEM NAME> restoreRevision revision <revision number>
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.
show table system serverAdmin
show table system serverStatus
request system admin <SYSTEM NAME> switchover
show table system
commands to confirm that the primary node has the active redundancy role.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.
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.