In this section:

Related articles:

In the RAMP cluster configuration of an SBC SWe N:1 deployment, you must set the "Configuration Type" to "OAM" to enable using the OAM node model described in this topic. For more information on SBC SWe N:1 deployment requirements, refer to: 

Refer to Create SBC Clusters for more information on cluster configuration in the RAMP.


Note

When you deploy OAM as a 1:1 system, changes made on the Active node are replicated to the Standby for data redundancy. To ensure data consistency, if the OAM Standby is not available, changes are not permitted on the OAM Active.

If configuration changes are required on SBC nodes while the Standby is not available, you can make changes locally on the SBC nodes; however, these changes are temporary and get overwritten when, for example, the SBC reboots and re-syncs with the OAM node.

OAM Node Configuration Model

The OAM node configuration model incorporates a 1:1 HA pair of dedicated Operations, Administration, and Maintenance (OAM) nodes to configure and manage SBC nodes in N:1 deployments. In an N:1 deployment, multiple nodes (up to 4) are active at the same time and the active nodes are backed up by a single backup node. An OAM Node deployment must be instantiated with the SBC HA mode specified as "Nto1." The OAM nodes must be deployed in 'Nto1' mode with N=1.

Figure 1: SBC Clusters with OAM Nodes



The OAM node provides the northbound interface for the VNF, including SSH/CLI, NetConf, and RESTCONF interfaces. You use the OAM node interfaces to configure the cluster. The OAM node holds the active cluster configuration and is responsible for disseminating the cluster configuration to the SBC nodes within the cluster. Although the nodes register with the RAMP, the SBC nodes within the VNF get their configuration updates only from the OAM node.

OAM Node Configuration

When an SBC cluster is operating in OAM configuration mode, the active OAM node holds the active configuration for the cluster and disseminates changes to the SBC nodes in the cluster. To update the configuration of the cluster, you make changes on the active OAM node using either the CLI or the SBC Configuration Manager GUI. Once you save and activate your configuration changes, the OAM node notifies the SBC nodes within the cluster. The SBC nodes collect the configuration change list from the OAM node and apply the changes to their local configuration. The OAM node also saves the configuration revision to the configuration history stored on the RAMP.

As you make configuration changes, the OAM node maintains a record of any interim “commit” commands you issue in the CLI or save actions you request on individual pages in the SBC Configuration Manager GUI. However, it does not update the configuration database, notify the nodes to pick up changes, or save the configuration revision on the RAMP until you issue an explicit request to save and activate the change. In the CLI, issue a saveAndActivate command. In the GUI, click the Apply Saved Changes and Close button in the top bar of the SBC Configuration Manager window to save and activate your changes. Refer to Modifying SBC Cluster Configuration for details on using either the SBC Configuration Manager or the SBC CLI to configure the cluster.

Node-level Data and Configuration

In an SBC cluster deployment, most configuration settings are common across nodes and are part of the homogeneous configuration that the OAM node propagates to the nodes. However when necessary, you can perform actions or retrieve operational data from individual nodes. A limited number of configurations can also be set on an individual node. To facilitate these node-specific interactions, the SBC configuration model includes a “node” branch when a cluster is operating in OAM configuration mode. The node branch is accessible through either CLI or in the SBC Configuration Manager GUI. Refer to Node-level Data and Configuration for more information on working with the node branch in the configuration model.

Configuration History 

Within the RAMP Cluster Management GUI, you can use the cluster configuration history to review the set of configuration changes applied with each save and activate action. It also enables reverting the cluster configuration to a prior revision. Refer to Reviewing Configuration Changes and Reverting Configuration - OAM Mode.