1. Virtual Network Functions Manager Installation and User Guide
  2. Install and Configure VNFM

5 Install and Configure VNFM

Perform the following procedure to install and configure VNFM.

Prerequisite
  • Download and install pip.
  1. Get one Linux Box which has already installed OpenStack client. If not, first install Python and PIP, then install the OpenStack client in Linux Box to interact with OpenStack through CLI.

    Steps to install the OpenStack client.

    1. Log in as a root user and execute the yum install python-devel command.
    2. Install OpenStack client by executing the pip install python-OpenStackclient command.

    3. The above command skips importing heatclient plugin, install this plugin by executing:

      pip install python-heatclient
  2. Identify an OpenStack instance.

    Note:

    The identified OpenStack instance must meet the VNFM OpenStack Prerequisites.

    1. Download the OpenStack api credential file from OpenStack.
    2. Download the OpenStack RC file.
      1. Log in to OpenStack GUI.
      2. Go to API Access section tab.
      3. Click on Download OpenStack RC File and download (Identity API v3) file.
    3. Source the downloaded OpenStack API RC file in Linux BOX where OpenStack client is installed by executing: source openrc.sh

      When prompted for the password, provide OpenStack controller password.

  3. Download the HEAT templates for VNFM installation.

    Note:

    Download the latest VNFM HEAT templates to your local disk from Oracle Help Center (OHC).
  4. Upload the image file to OpenStack:
    1. From the OpenStack GUI, navigate to Projects, and then Compute-Image.
    2. Click Create Image.
    3. In the Create Image dialog box, select the suggested options for the following fields:
      1. In the Image Source field, select Image File.
      2. In the Image File field, select the VNFM 5.4.4 VM image. The VNFM Image can be obtained from Oracle Software Delivery Cloud (OSDC) Portal.

        Image name:

        VNFM_5.4.4.0.0_54.11.0.qcow2
      3. The Minimum Disk and Minimum RAM fields can be left blank.
    4. The VNFM flavors must be provided with the appropriate values. For information about flavors, refer to the DSR Cloud Benchmarking Guide.
  5. Create the VNFM Volume using:
    1. The OpenStack CLI.
      1. Create the VNFM volume to use as a part of the OpenStack. The VNFM supports a volume with the following specifications:

        Volume size = 8 GB

        Availability-zone = nova

        For example: OpenStack volume create --size 8 --availability-zone nova <Name of the volume>

        The above command displays the ID assigned to the newly created volume.

    2. The OpenStack GUI:
      1. Navigate to Project > Volumes - Volumes
      2. Click Create Volume.
      3. In the Create Volume dialog box, perform as suggested for the following fields:
      4. In the Size (GiB) field, give 8 as its size.
      5. In the Availability Zone field, give nova as its value.

      6. Get the ID of the volume created above and update the dsrVnfmVolumeId parameter in the dsrVnfmParams.yaml file.

        Note:

        • To change the images and flavors of VNFCs, configure the respective parameters in: /opt/vnfm/config/8.6/VmInfo.xml
        • To change the default properties, configure the respective parameters in: /opt/vnfm/config/VnfmProperties.xml
  6. Modify the input parameters:
    1. Edit the HEAT template file dsrVnfmParams.yaml

      Note:

      • The input parameters are given as key/value pairs. Modify only the values (the part to the right side of the colon).
      • The formatting is an important factor in YAML file. Do not remove any leading spaces or add any lines to the file.
      • While creating IPv4 setup of Vnfm (Vnfm network is IPv4), use DNS and NTP of IPv4 and while creating IPv6 setup of Vnfm (Vnfm Network is IPv6), use DNS and NTP of IPv6.
    2. Edit the values as per the guidelines provided in the following table:

      Table 5-1 Parameters and Definitions for VNFM Installation

      Parameter Value
      dsrVnfmVmName Enter a name for the VM. Alphanumeric characters and "_" are allowed.
      dsrVnfmImage Enter the name of the image uploaded in the previous step.
      dsrVnfmFlavor Enter the name of a flavor that is loaded onto OpenStack.
      vnfmNetwork

      Enter the name and subnet of a network that external clients can use to communicate with the VNFM. (The user can also give an IP along with the network in case of fixed IP deployment) (IPv6 or IPv4)

      Format for Dynamic IP deployment: 
      "vnfmNetwork": { "network" : "<Network Name>", "subnet" : "<Subnet Name>" }
      Format for Fixed IP deployment: 
      "vnfmNetwork": { "network" : "<Network Name>", "fixed_ip" : "<ip>" }
      vimNetwork

      Enter the name and subnet of a network that VNFM uses to route VIM traffic. (IPv4 or IPv6)

      Format for Dynamic IP deployment:
      "vimNetwork": { "network" : "<Network Name>", "subnet" : "<Subnet Name>" }
      Format for Fixed IP deployment:
      "vimNetwork": { "network" : "<Network Name>", "fixed_ip" : "<ip>" }
      ntpServer

      Enter the IP address of an NTP server with which the VNFM synchronizes the time. The OpenStack controller hosts an NTP server so the IP address of the OpenStack controller is usually a good value.

      Note: VNFM can support any of these NTP resources: IPv4, IPv6, or both IPv4 and IPv6 NTP entries.

      dnsServer Enter the IP address of DNS server with which VNFM resolves the hostname. For an IPv4 setup, enter IPv4 DNS server IP and for an IPv6, use IPv6 DNS server IP.
      dsrVnfmAZ Enter the availability zone to place the VNFM. The "nova" is the default availability zone and is usually the right value.
      dsrVnfmVolumeId Enter the volume name to use as persistence storage for the VNFM.
      vimRouteAddress Enter the OpenStack network address/subnet mask. This is going to be use communication between VNFM and OpenStack (Vim) network. User can provide the list of route address separated by comma.
      snmpReceiverAddressPort (Optional) IP and Port of the SNMP Trap Receiver/ SNMP Manager. Default: 127.0.0.1/162,::1/162 (Not required for IPv6 brackets.)

      Note:

      • In case of fixed IP deployment for VNFM, the network name and IP must be given in the following syntax for vnfmNetwork or vimNetwork parameter in dsrVnfmParams.yaml file: vnfmNetwork: {"network":"ext-net","fixed_ip":"10.196.52.175"} vimNetwork: {"network":"ext-net2","fixed_ip":"10.196.52.176"}
      • In case of dynamic IP deployment for VNFM, the network name and subnet should be given in the following syntax for vnfmNetwork or vimNetwork parameter in dsrVnfmParams.yaml file: vnfmNetwork: {"network":"ext-net", "subnet": "ext-net-subnet"} vimNetwork: {"network":"ext-net2", "subnet": "ext-net2-subnet"}
      • User need to give mandatory OpenStack network address vimRouteAddress parameter in vnfm parameter.

        Syntax: vimRouteAddress: <OpenStack Network address>/<subnet mask>

        For example

        vimRouteAddress: 10.75.167.0/24

        In case of list of OpenStack cloud:

        vimRouteAddress: 10.75.167.0/24,10.75.185.0/24
      • If user needs to communicate with multiple OpenStack cloud using one vnfm then the user must provide multiple OpenStack network address while installing vnfm.

      User can also add other OpenStack cloud network after installing vnfm, by performing the steps provided in section Adding Route for a New VIM.

      User must provide optional SNMP Manager IP and Port as snmpReceiverAddressPort parameter in dsrVnfmParams.yaml file.

      Syntax: snmpReceiverAddressPort: IP/PORT,IP/PORT

      For example:

      In case of Dual SNMP Manager: snmpReceiverAddressPort: 10.75.189.151/8900,2606:b400:605:b813::5/7400

      In case of Single SNMP Manager: snmpReceiverAddressPort: 2606:b400:605:b813::5/7400

      ntpServer: Users must provide mandatory ntpServer details which can support up to 3 ntp resources at a time in the dsrVnfmParams.yaml file. Ex1: ntpServer: 10.250.32.10, Ex2: ntpServer: 2606:b400:605:b912:200:5eff:fe00:1f7, Ex3: ntpServer: 10.250.32.10,2606:b400:605:b912:200:5eff:fe00:1f7,10.250.32.56

    3. Once editing is done, save the file.
  7. Deploy the VNFM using the OpenStack CLI by executing:
    OpenStack stack create -t dsrVnfmVm.yaml -e dsrVnfmParams.yaml <stackName>
  8. To query the VNFM release details after VNFM deployment, run the following command: 
    $>[dsrvnfm@releasevnfmvm /]$ sudo ./install_vnfm.py --info
[sudo] password for dsrvnfm
VNFM release information: 
Product Name : VNFM
Product Release : 5.4.4
DSR Supported Release(s) : 
8.6.0.5.0

Refer the following table while choosing the IP versions:

Table 5-2 IP Version Mapping

VNFM External IP Version (REST interface) Eth0 VNFM Vim IP Version (VIM interface) Eth1 OpenStack Controller VIM IP DSR IP/Other Traffic Route eth0 Route eth1 Dual Snmp Manager Support Notes
IPv6 IPv4 IPv4 IPv6/IPv4 Default Default Supported
  • Supported.
  • All the openstack traffic/packet goes through VIM IP (eth1).
  • IPv6 traffic other than VIM traffic goes through VNFM IP (eth0).
  • IPv4 traffic other than VIM traffic goes through VIM IP (eth1).
IPv4 IPv4 IPv4 IPv4 Default Limited to VIM Network Routes Supported
  • Supported.
  • Only IPv4 traffic is supported.
  • MMI calls to IPv6 VNFs fails. VNFs are instantiated and Cloud init might be complete, but other LCM operations fail.
  • So, DSR, SNMP, NTP, DNS, and any other servers communicating with VNFM must be on IPv4 networks.
IPv4 IPv6 IPv6 IPv6 /IPv4 Default Default Supported
  • All the openstack traffic/packet goes through VIM IP (eth1).
  • IPv4 traffic other than VIM traffic goes through VNFM IP (eth0).
  • IPv6 traffic other than VIM traffic goes through VIM IP (eth1).
IPv6 IPv6 IPv6 IPv6 Default Limited to VIM Network Routes Supported
  • Only IPv6 traffic is supported.
  • MMI calls to IPv4 VNFs fails. VNFs are instantiated and Cloud init is complete, but other LCM operations fail.
  • So, DSR, SNMP, NTP, DNS, and any other servers communicating with VNFM must be on IPv6 networks.
IPv6 IPv4 IPv6         Not Applicable.

The VIM IP version and the controller IP version are different. The communication never gets established.
IPv4 IPv4
IPv4 IPv6 IPv4        
IPv6 IPv6

Note:

  • VNFM External IP Version (REST interface) eth0- VNFM external IP interface to support the VNFM REST API.

  • VNFM Vim IP Version (VIM interface) eth1- VNFM IP is used to communicate with the VIM controller. VNFM eth1 IP and VIM controller IP should be in the same IP version. Both of them should be in either IPv4 or IPv6.

  • OpenStack Controller VIM IP- OpenStack controller VIM IP that creates the VNF through VNFM. Multiple OpenStack VIM controller IP can be provided during VNFM installation with VIM subnet.

  • DSR IP- DSR IP is the VNF IP. VNFM eth0 IP communicates with DSR XMI interface for DSR Cloud init LCM operation. So, DSR xmi IP and VNFM eth0 IP must have the same IP version, either IPv4 or IPv6.

5.1 Access VNFM Using the REST Interface

The VNFM is accessible using a REST interface. There is no provision to access the REST interface through CLI, or GUI, however it can be accessed through a Swagger specification provided for the REST interface. There are many other compatible interfaces that can be used with popular REST testing tools. Some of the most widely used tools that can be used with the REST testing tool are:

Swagger UI

With the Swagger UI, a GUI can be generated from the Swagger specification.

Swagger specifications can be found post VNFM installation at, (https://<VNFM IP>:8443/docs/vnfm/).

Postman

Another popular tool for creating REST requests is the Postman tool. It is available as a standalone app and as a Chrome browser plug-in. You can import a Swagger specification to allow Postman to understand the VNFM REST API in detail, which allows it to assist you while creating requests and interpreting responses.

5.2 VNFM Redundancy

VNFM supports the Redundancy model. It works with two servers in Primary - Secondary states. Data in the external mounted volume is synchronized from Primary to Secondary VNFM.

VNFM can have two states and a transitory third state as follows:

  • Primary
  • Secondary
  • Transient

The Transient state occurs when a CHANGE VNFM STATE request fails due to network connectivity issues. In this case, the orchestrator must wait until the connectivity issue is resolved and re-triggers the CHANGE VNFM request.

Secondary VNFM can be created as any other regular VNF by using CREATE and INSTANTIATE VNF requests. It can be created only when the PRIMARY VNFM is a standalone VNFM.

State of VNFM can be queried using the QUERY VNFM STATE INFORMATION REST request.

VNFM state can be changed using the CHANGE VNFM STATE REST request.

Note:

When VNFM is in Secondary or Transient state, it accepts all GET requests and only the following POST requests: Login To VNFM and Change VNFM State.

5.3 Configurable Server Affinity Policy

Server Affinity Policy configuration is supported during the VNF Instantiation of DSR/SDS VNF's only. This policy can be configured on VNFc level.

Scaling uses the same affinity policy provided during VNF Instantiation and hence affinity policy option is not required during scaling. Default Server Group affinity policy is "anti-affinity".

Allowed Polices
  1. Anti Affinity: place instances on separate hosts.<Default>
  2. Affinity: places instances on the same host.
  3. Soft Anti Affinity: place instances on separate hosts if possible.
  4. Soft Affinity: place instances on the same host if possible.

5.4 VNFc Nomenclature

The following table contains information about VNFc Nomenclature.

VNF Instance Name (max 22 Characters) VNFc Type Nomenclature (max 5 characters) Server Name (VM Hostname) (max 30 Characters)
<User Input> DSR NOAM DNO <user-input>-DNO00
<User Input> DSR SOAM DSO <user-input>-DSO00
<User Input> DSR DAMP DMP <user-input>-DMP00
<User Input> DSR IPFE DIP <user-input>-DIP00
<User Input> STP MP STPMP <user-input>-STPMP00
<User Input> SBR (Session/Binding/Universal) SBR <user-input>-SBR00
<User Input> UDR UDR <user-input>-UDR00
<User Input> DSR DR NOAM DDRNO <user-input>-DDRNO00
<User Input> SDS NOAM SNO <user-input>-SNO00
<User Input> SDS QS SQS <user-input>-SQS00
<User Input> SDS SOAM SSO <user-input>-SSO00
<User Input> SDS DP SDP <user-input>-SDP00
<User Input> SDS DR NOAM SDRNO <user-input>-SDRNO00
<User Input> SDS DR QS SDRQS <user-input>-SDRQS00
<User Input> Prov Gateway PVGW <user-input>-PVGW00
<User Input> DB Management Server (APIGW) AGWMN <user-input>-AGWMN00
<User Input> DB Data Server (APIGW) AGWDN <user-input>-AGWDN00
<User Input> DB Sql Server (APIGW) AGWSN <user-input>-AGWSN00
<User Input> dsrApiGwAdmin AGWAD <user-input>-AGWAD00
<User Input> dsrApiGwApp AGWAP <user-input>-AGWAP00
<User Input> DsrIdihApp IDAPP <user-input>-IDAPP00
<User Input> DsrIdihMed IDMED <user-input>-IDMED00
<User Input> DsrIdihDb IDDB <user-input>-IDDB00
<User Input> atsMaster ATSMA <user-input>-ATSMA00
<User Input> atsCore ATSCO <user-input>-ATSCO00
<User Input> atsTools ATSTO <user-input>-ATSTO00

5.5 Supported VNFs by VNFM

The table below contains a list of all the VNFs supported by VNFM:

Table 5-3 Supported VNFs and VMs

Supported Dynamic IP VNFs Supported VNFCs Supported Dynamic IP VNF Supported Fixed IP VNF Supported Dual Stack IP VNF VNF Dependency Mixed Mode (XMI (Single/Dual), IMI(Single/Dual) and XSI-1, 2, 4(Single/Dual)) Mixed Mode XSI-1, 2, 4 (4XSI-1, 2, 3, 4) (Single/Dual)
DSR NOAM NOAM (Active/Standby) Yes Yes Yes Yes N/A
DSR DR NOAM DR NOAM (Active/Standby) Yes Yes Yes DSR NOAM Yes N/A
DSR Signaling SOAM (Active/Standby), DA-MP, STP-MP, IPFE, SBR, UDR Yes Yes Yes (Only for DIAMETER, DIAMETER+SBR flavor) DSR NOAM Yes* Yes*
APIGW DB Management Server, DB Data Server, DB Sql Server, Admin Server, Application Server(s) Yes Yes No No N/A
IDIH APP, MEDIATION, DB Server Yes Yes No DSR Signaling No N/A
SDS NOAM NAOM (Active/Standby) and Query Server Yes Yes Yes Yes N/A
SDS DR NOAM DR NAOM (Active/Standby) and Query Server Yes Yes Yes SDS NOAM Yes N/A
SDS Signaling SOAM (Active/Standby), DP Server Yes Yes Yes SDS NOAM Yes Yes
ATS Master MASTER Yes Yes No No No
ATS Core/Tools Core and Tools Yes Yes No ATS Master No No
PROV GW PROVGW Yes No No N/A
Yes* -
  • Single Subnet (either IPv4 or IPv6) - supported for all flavors.
  • Dual subnet and Single Dual Mixed subnet mode - only DIAMETER, DIAMETER+SBR flavor supported.

The following table provides a sample combination of DSR-SOAM (for Diameter Flavor) of XSI network interfaces:

Table 5-4 Sample Combination of DSR-SOAM (for Diameter Flavor)

VNF TYPE XSI-1 XSI-2 XSI-3 XSI-4
DSR Signaling (Diameter Flavor) Single Stack IPv4 or IPv6 Single Stack IPv4 or IPv6 Single Stack IPv4 or IPv6 Single Stack IPv4 or IPv6
Single Stack IPv4 or IPv6 Single Stack IPv4 or IPv6 Dual Stack IPv4 and IPv6 Dual Stack IPv4 and IPv6
Dual Stack IPv4 and IPv6 Dual Stack IPv4 and IPv6 Single Stack IPv4 or IPv6 Single Stack IPv4 or IPv6
Dual Stack IPv4 and IPv6 Dual Stack IPv4 and IPv6 Dual Stack IPv4 and IPv Dual Stack IPv4 and IPv6
The following table provides a sample combination of DSR-SOAM (for Diameter+SBR Flavor) of XSI, SBR network interfaces:

Table 5-5 Sample Combination of DSR-SOAM (for Diameter+SBR Flavor)

VNF TYPE XSI1 XSI2 SBR
DSR Signaling (Diameter+SBR Flavor) Single Stack IPv4 or IPv6 Single Stack IPv4 or IPv6 Single Stack IPv4 or IPv6
Single Stack IPv4 or IPv6 Dual Stack IPv4 and IPv6 Single Stack IPv4 or IPv6
Dual Stack IPv4 and IPv6 Dual Stack IPv4 and IPv6 Dual Stack IPv4 and IPv6
The following table provides a sample combination of SDS-SOAM:

Table 5-6 Sample Combination of SDS-SOAM

VNF TYPE XMI IMI
SDS Signaling Single Stack IPv4 or IPv6 Single Stack IPv4 or IPv6
Single Stack IPv4 and IPv6 Dual Stack IPv4 and IPv6
Dual Stack IPv4 and IPv6 Single Stack IPv4 or IPv6
Dual Stack IPv4 and IPv6 Dual Stack IPv4 and IPv6