In this section:
The Ribbon Virtual Network Function Manager (VNFM) is an ETSI standards-aligned virtualized application you can use to orchestrate and manage the lifecycle of SBC SWe deployments in an OpenStack cloud environment. VNFM provides an alternative to the use of Heat templates to deploy integrated SBC (I-SBC), media SBC (M-SBC), and signaling SBC (S-SBC) VM clusters.
VNFM processes a VNF Descriptor (VNFD) file to define the main properties and resources required to deploy a VNF. You "onboard" an SBC VNFD file into VNFM for your deployment type as part of a Cloud Service Archive (CSAR) package file. Sonus provides a script and VNFD template file you use to generate a CSAR package file for the type of SBC cluster you want to deploy. The VNFD file within the CSAR file cannot be edited; during orchestration, VNFM will prompt for allowed customizations such as the system name and associated EMS system details.
(SR-IOV only) - additional prerequisites and configuration steps required for SR-IOV deployment are preceded with this notation. If you are implementing SR-IOV interfaces, be sure to complete these steps.
Orchestration using VNFM does not support implementing a second management port for the SBC or the packet port redundancy feature.
Prior to using VNFM to instantiate SBC VNFs: make sure to:
Due to a current issue with RHEL 7.5, the following procedure must be run once on any compute hosts where SWe instances which require multi-queue virtio interfaces will be deployed. These steps enable such instances to spawn. The procedure confirms that the failure to spawn is due to the underlying RHEL 7.5 issue and then provides steps to work around this issue.
/var/log/audit
audit.log
file and confirm that the following denial is reported by SELinux:avc: denied { attach_queue }
audit2allow -a -M attach_queue
semodule -i attach_queue.pp
The CSAR file you created for your deployment must be onboarded on VNFM before you can orchestrate a new SBC cluster. Make sure the CSAR file is in a location accessible from VNFM.
Click Settings > VNF Onboarding. The VNF Onboarding window opens.
After the CSAR file is onboarded the SBC VNF can be deployed. Note that you must have previously created an OpenStack Glance image using the SBC application software .qcow2 file. Refer to Creating a Glance Image within the pre-instantiation requirements for OpenStack.
Click Deploy adjacent to the VNF you want to deploy. The VNF Deployment Wizard window opens with the VNF Config tab in view.
Select a tenant for the instance in the Tenant Name drop-down list.
This tab also includes a Reuse Pre-allocated IPs check box which enables using the VNFM pre-allocated floating IP feature. Refer to Deploying a VNF with Preallocated Floating IPs for more information and procedures.
Click the Network tab.
Click the Environment tab. The fields on this tab show user data required to instantiate the SBC as it is provided in the VNFD file. Editing values on this tab override the default values in the VNFD file allowing you to specify the values appropriate for your deployment.
Use the following table to edit the values in the VM Type section of the Environment tab, as necessary. Some values cannot be changed while other fields can be edited during orchestration, as noted in the table. Interface values (IF0 to IF3) can be edited, for example, if you need to specify VLAN IDs for your deployment. Take care to use the correct parameter names and maintain the syntax as shown. Refer to the Interface Definition Parameters Table for more information on the parameters that can be used to define the properties of an interface.
Field | Editable? | Description |
---|---|---|
System Name | yes | User-assigned name for the instance. You must enter a name. |
SBC Personality | no | Specifies an integrated (isbc), signaling (ssbc) or media (msbc) SBC deployment. |
The HA model selected in the VNFD file | no | Specifies an active_standby HA deployment or an N:1 HA deployment. |
Properties of IF0 | yes | Parameters associated with IF0. By default IF0 is configured as the management interface. |
Properties of IF1 | yes | Parameters associated with IF1. By default IF1 is configured as the HA interface. |
Properties of IF2 | yes | Parameters associated with IF2. By default IF2 is configured as the Pkt0 interface. (SR-IOV only) Edit the “PrefixVn:” and "VLANId:" values (shown below) to the appropriate values for your interface. Take care to only add the values and do not add additional characters or whitespace. |
Properties of IF3 | yes | Parameters associated with IF3. By default IF3 is configured as the Pkt1 interface. (SR-IOV only) Edit the “PrefixVn:” and "VLANId:" parameters (shown above) to the appropriate values for your interface. Take care to only add the values and do not add additional characters or whitespace. |
EMS Username | yes | Enter the username credentials to use when registering with the EMS. |
EMS Password | yes | Enter the password to use when registering with the EMS. |
EMS IP[0] | yes | Enter the IP address of the EMS-0 (primary) instance. |
EMS IP[1] | yes | Enter the IP address of the EMS-1 instance. |
EmsDownloadConfig | yes | Specifies whether the cluster downloads configuration from the EMS. By default this value is set to True. |
EmsPrivateNodeParameters | yes | Optionally specifies an EMS cluster ID. |
Depending on the version of VNFM you are using, the Cloud Config Init Data section of the Environment tab (shown below) might not be populated. If the section is empty, then the initial contents must be manually copied into it. The default data to copy is located in the file: Scripts/*sbc-7.2-cloud-initdata.cfg
. A copy of this file is located in the directory where the CSAR file was created and also within the contents of the CSAR package (after you unzip the CSAR). Open this text file, from either location, and copy its contents (including all leading spaces) into the Cloud Config Init Data section. This copy step is not required if the Cloud Config Init Data section is already populated.
In the Cloud Config Init Data section, replace the default public key with the public key of your own self-generated ssh key pair to be used for logging into SBC. The previous figure shows an SSH key for the "admin" user account. To generate the key, you can use the ssh-keygen
command and use the contents of the id_rsa.pub
file that it generates in your /home/<user>/.ssh
directory to replace the default. Refer to man ssh-keygen
for more information. You also have the option to enter passwords for the user accounts defined in this section. Take care to maintain the formatting of this section when you replace the default content. The data must be provided in a proper YAML format.
(SR-IOV and Provider Networks only) For each interface, enter the required IPv4 or IPv6 address. Or, if this configuration has been done for a previous orchestration, you will have the option to select the name of a previous instance whose IP address configuration you want to reuse from the Select from the previous Orchestrations list.
VNFM begins the process of orchestrating the SBC VNFs. VNFM opens the VNF Status window where you can watch the status progression as the VNFs are deployed. When the process is complete the VNF status changes to Ready.
If you are deploying an N:1 M-SBC, the newly orchestrated VNF remains in a “degraded” state until you configure a Load Balancing Service (LBS). An alarm saying that the VNF cannot connect to VNFM may be triggered. However, once LBS is configured the active and standby roles for the VMs are determined and the VNF registers successfully with VNFM. Configuring LBS is a part of the initial configuration of an M-SBC. Refer to Configuring M-SBC.
During orchestration VNFM creates basic security rules and a security group. These basic rules do not restrict access to and from the SBC nodes. If you have not already created the specific security rules required for your deployment, refer to the following page for the list of rules you should create: Creating Security Group Rules.
After orchestration the SBC nodes are created but have no associated configuration. Refer to Configuring SBC SWe on OpenStack using SBC Configuration Manager for procedures to configure the SBC.
If you completed the steps required for implementing SR-IOV interfaces and you used the example input data shown in the previous procedure, the following figure shows the IP address assignments that would be made for the packet interfaces during orchestration. This output appears for the VMs within an VNF when you click on a VNF name within the VNF Status page.