Managing Configuration Changes Using the EMS

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.

  1. Log onto the EMS.
  2. Click Network > Cluster Management. The Cluster Management / Manage VNFs window opens listing the SBC clusters on the EMS.
  3. Click the radio button adjacent to the name of the cluster. The Details tab for the selected cluster opens by default. 
  4. 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.

    Cluster Configuration History

  5. 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. 

    Configuration Transaction Log

  6. Click OK to close the Transaction Log window.

  7. 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 OAM node downloads the selected configuration revision, creates a new revision to replace the current configuration, and reboots. The OAM node sends the new configuration revision and a command to reboot to all SBC nodes in the cluster. The OAM node saves the restored configuration revision back to the EMS and increments the revision number.  
    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.
Caution

Reverting the SBC cluster to a prior configuration revision requires the OAM node and all SBC nodes to reboot which is service impacting.

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