Reviewing Configuration Changes and Reverting Configuration - OAM Mode

In this section:

Managing Configuration Changes Using RAMP

When an SBC SWe cluster is operating in OAM configuration mode, the OAM node saves a record of specific configuration changes on the RAMP. RAMP increments the revision number after you explicitly save and activate a set of configuration changes. From RAMP, 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.

Logon to RAMP and navigate to DEVICE MANAGEMENT > Devices to manage the devices.

The page RAMPDOC2406:Manage Clusters was not found -- Please check/update the page name used in the MultiExcerpt-Include macro

Refer to the RAMP documentation Manage Clusters for details.

Managing Configuration Changes Using the CLI

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.

Caution

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.

Managing Non-Activated Configuration Changes

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' +

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Viewing the Candidate Configuration or Changes for a Specific Revision

The CLI request command's 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.

Transaction Log Utility

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>

Lawful Intercept Change Filtering

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.

Discarding Non-Activated 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

Restoring a Prior Configuration

The CLI request command's 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 RAMP, 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.