In this section:
When an SBC SWe cluster is operating in OAM configuration mode, the OAM node saves a record of specific configuration changes on the EMS. The EMS increments the revision number after you explicitly save and activate a set of configuration changes. From the EMS, you can review the list of the changes within a revision.You also have the option to revert the cluster configuration back to a prior revision level.
Click the Configuration History tab. A list of the stored configuration revisions opens. Each revision is identified by a revision number and a timestamp when the configuration was created.
Click the View Changes icon adjacent to a revision to open a pop-up window that lists the specific configuration transactions within the selected revision.
Click OK to close the Transaction Log window.
Reverting the SBC cluster to a prior configuration revision requires the OAM node and all SBC nodes to reboot which is service impacting.
CLI configuration changes made on the OAM node must be both committed and save-activated (by issuing the save-activate command: request system admin <system name> saveAndActivate
) before the configuration changes are applied to managed SBC VMs. Prior to save-activating pending changes you can use CLI commands to review changes or discard changes. You also have the option to revert back to a prior configuration level using the CLI.
In certain scenarios, a managed node is unable to apply changes due to unexpected configuration conflicts or network error conditions. Such situations trigger a sonusSbxManagedNodeUnableToReceiveConfigUpdates alarm and set the activeRevision
number for the node to “-1.” When a node is in a “-1” state, some operations may be prevented until the situation resolves. Recovery requires a reboot of the impacted node. However, a reboot can be service impacting, proceed with caution.
You can commit one or more configuration changes on an OAM node before you issue the saveAndActivate
command that completes the process of fully activating the committed changes. Committed configuration changes that are not save-activated are referred to as a "candidate" configuration.
If you start a CLI session and the OAM node holds a candidate configuration (committed changes that have not been save-activated), a warning banner indicates this condition so you can determine whether or not you want to save-activate the changes. An example of this warning banner is shown below:
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+ WARNING: There are currently commits that have not been save-activated on OAM node. +
+ Note that as part of ongoing system management, some commits are done +
+ automatically by the system. +
+ To view the candidate commit change-list, execute: +
+ 'request system admin <SYSTEM NAME> viewConfigurationChanges' +
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
The CLI
command's request
viewConfigurationChanges
parameter outputs a list of pending, committed CLI changes. The viewConfigurationChanges
parameter supports an optional revision
parameter. If you do not provide a revision number, the command lists the candidate configuration changes. When you specify a revision number, the output shows the configuration changes associated with the specified revision.
The command syntax is shown below.
> request system admin <SYSTEM NAME> viewConfigurationChanges revision <revision number>
ViewConfigurationChanges
can list up to 800 lines of screen output. Should the output be greater than 800 lines, you can save the ViewConfigurationChanges
output to a file and use SFTP to transfer the file to a remote server. Use the |
save <filename>
command extension to save the screen output to a specified file. The following example saves the screen output to a file named ConfigChanges.txt
.
> request system admin vsbcSystem viewConfigurationChanges revision 5 | save ConfigChanges.txt
The ConfigChanges.txt
file is placed in the user’s SFTP directory: /home/sftproot/<UserGroup>/<UserName>/
For example, for a user “TestOperator” who is a member of the operator user group, the saved file is placed in the location: /home/sftproot/Operator/testOperator/
You can use SFTP from a remote server to pull the output file, or you can use the SBC’s SbcSftp utility to use SFTP to transfer the file from the SBC. Refer to SbcSftp - Secure File Transfers with Automated ACL Creation and Deletion for information on using SbcSftp.
When CLI change output is lengthy, another option is to use the show utils
transactionLog
utility to list the pending list of committed changes. The transactionLog
output does not have an output limit. The transactionLog
utility also supports an optional revision
parameter. If you do not provide a revision number the command lists the candidate configuration changes. When you specify a revision number, the output shows the configuration changes associated with the specified revision. The command syntax is shown below.
> show utils transactionLog revision <revision number>
Access to configuration related to lawful intercept (LI) is restricted to authorized users. Therefore the output of both viewConfigurationChanges
and the transactionLog
utility is filtered accordingly. LI-related changes are not present in the output shown to users that lack LI privileges. Similarly, users with only LI privileges can see only LI-related configuration changes.
If you determine that you have committed configuration changes that you do not want to save-activate, use the request
command's discardCandidateConfiguration
parameter to discard the pending changes. This command restarts the OAM nodes, but does not impact the managed nodes.
The command syntax is shown below.
> request system admin <SYSTEM NAME> discardCandidateConfiguration
The CLI
command's request
restoreRevision
parameter reverts the configuration on managed SBC nodes to a specified prior configuration revision stored on the OAM node. Similar to when a revert is triggered from the EMS, restoring a prior configuration requires the OAM node and managed SBC nodes to restart.
Note that if the specified revision 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 command syntax is shown below.
> request system admin <SYSTEM NAME> restoreRevision revision <revision number>