In the last blog we talked about how to use a public OpenStack cloud such as VEXXHOST as the NFVI/VIM layer for the ONAP vFW blueprint along with a containerized version of ONAP orchestrated by Kubernetes.

As we discussed, in reality, the traffic source and the vFW VNF are unlikely to be in the same cloud.  In this blog, we will briefly discuss how the vFW blueprint can span two different VEXXHOST tenants. This is not quite the same as two different cloud regions, but it is a pretty close simulation.

The two VNFs will be placed as follows:

• vFW_PG (packet generator) on VEXXHOST Tenant1  
• vFW_SINC (compound VNF that consists of the vFW VNF and a sink VNF to receive packets) on VEXXHOST Tenant2

Since ONAP infrastructure is taken care of, here are the steps to connect ONAP to VEXXHOST. Please follow the steps from “Orchestrating Network Services Across Multiple OpenStack Regions Using ONAP” blog, to register both tenants as 2 regions in ONAP. Next:

1. Create an account on VEXXHOST with 2 different tenants.  
2. If Registering the VEXXHOST into A&AI using ESR UI, change the password length to less than 20 characters.  
3. On Tenant1 manually create OAM network, unprotected_private  networks with different subnets than on Tenant2.  
4. On Tenant2, create an OAM network using the VEXXHOST cloud Horizon dashboard.  
5. Add security rules to allow ingress ICMP, SSH &all the required ports along with IPV6 from both the tenants.  
6. Edit the base_vfw.env and base_vpkg.env VNF descriptor files to configure them correctly based on the respective Tenants.  
7. Copy the above parameters into a text editor to use for subsequent A&AI registration, SDN-C preload, and APP-C⇔vFW_PG VNF netconf connection.

Now follow the steps from the vFW wiki that involve:

1. SDC designer role: Create vendor license model  
2. SDC designer/tester role: Onboard and test VNFs (or vendor software product i.e. VSP)  
3. SDC designer role: Design network service  
4. SDC tester role: Test network service  
5. SDC governor role: Approve network service  
6. SDC ops role: Distribute network service  
7. VID: Instantiate network service  
8. VID: Add VNFs to network service  
9. SDN-C preload: Configure runtime parameters (for us design-time & run-time parameters are the same); preload vFW SINC on Tenant2 and vFW PG on Tenant1  
10. VID: Add VFs to network service — this step orchestrates networks and VNFs onto OpenStack

Upon completion of these steps, you should be able to go to the VEXXHOST Horizon GUI and see the VNFs coming up. Give them ~15 minutes to boot and another ~15 minutes to be fully configured. See below screenshots:

Did you try this out? How did it go? We look forward to your feedback. In the meantime if you are looking for ONAP training, professional services or development distros (basically an easy way to try out ONAP < 1 hour), please contact us.

‍

Useful links: ONAP Wiki, vFWCL Wiki, Orchestrating Network Services Across Multiple OpenStack Regions Using ONAP

‍

The Open Network Automation Platform (ONAP) is a Linux Foundation project that provides a way to design network services, manage their lifecycle and perform service assurance using real-time policy driven closed-loop automation (i.e. no human beings are involved, policies directly drive lifecycle management operations).

ONAP can be used to automate just about any SDN or NFV service, but to make things a bit convenient, the ONAP community has created ready-to-use blueprints/demos: virtual firewall (vFW), residential virtual customer premise equipment (vCPE) and voice over LTE (VoLTE). The vFW is the simplest of the three and can be tried out by those new to ONAP in just a couple of days. However, to try out vFW you will require two sets of infrastructure. First you need OpenStack or Kubernetes to run ONAP and then OpenStack to manage the underlying NFV infrastructure (NFVI) layer for the vFW network service. Unfortunately the combined stack is too heavy to run on a laptop. So you have two options to try out vFW. If you have a lab at your beck-and-call, read no further, go to the above wiki link and try out the vFW blueprint in your lab. However, if you are like most mortals and don’t have ready access to idling servers, we have a solution for you.

Here is what we recommend:

• vFW network service NFVI: Use an OpenStack public cloud. In this  blog, we will show you how we used VEXXHOST, a Canadian OpenStack public cloud service, as NFVI. Depending on where you are located, you can also look for other options. Just make sure the OpenStack cloud version is Ocata or Pike.  
• ONAP: We recommend the ONAP Operations Manager (OOM) installer that uses a containerized version of ONAP orchestrated using Kubernetes. This approach results in a significantly lower footprint than an OpenStack virtual machine based deployment of ONAP. OOM can deploy ONAP on just one VM that can be on the same public cloud as the vFW network service (i.e. VEXXHOST in this case) or a different one. In fact, if you want a hassle free approach, use the Aarna.ml ONAP development distro that brings up all of ONAP on one Google Cloud Platform VM in less than 1 hour.

Before we show you how to use VEXXHOST, a quick background on the vFW blueprint. Below is the blueprint (also called demo) architecture:

The vFW network service consists of 3 VNFs that are packaged as two:

• vFW_PG (packet generator)  
• vFW_SINC (compound VNF that consists of the vFW VNF and a sink VNF to receive packets that go through the vFW and display it on a GUI)

Assuming ONAP infrastructure is taken care of, here are the steps to connect ONAP to VEXXHOST:

1. Create an account on VEXXHOST  
2. If Registering the VEXXHOST into A&AI using ESR UI, make sure to change the default VEXXHOST account password so that it is less than 20 characters  
3. Please follow the steps from “Orchestrating Network Services Across Multiple OpenStack Regions Using ONAP” blog, to register VEXXHOST tenant as a SINGLE region in ONAP  
4. Create an OAM network (example CIDR 10.10.10.0/24, GW 10.10.10.1, DHCP Range 10.10.10.2 to 10.10.10.254) using the VEXXHOST cloud Horizon dashboard  
5. Add security rules to allow ingress ICMP, SSH & all the required ports along with IPv6  
6. Edit the base_vfw.env and base_vpkg.env VNF descriptor files to configure them correctly  
7. Copy the above parameters into a text editor to use for subsequent A&AI registration, SDN-C preload, and APP-C⇔vFW_PG VNF netconf connection

Now follow the steps from the vFW wiki that involve:

1. SDC designer role: Create vendor license model  
2. SDC designer/tester role: Onboard and test VNFs (or vendor software product i.e. VSP)  
3. SDC designer role: Design network service  
4. SDC tester role: Test network service  
5. SDC governor role: Approve network service  
6. SDC ops role: Distribute network service  
7. VID: Instantiate network service  
8. VID: Add VNFs to network service  
9. SDN-C preload: Configure runtime parameters (for us design-time & run-time parameters are the same)  
10. VID: Add VFs to network service — this step orchestrates networks and VNFs onto OpenStack

Upon completion of these steps, you should be able to go to the VEXXHOST Horizon GUI and see the VNFs coming up. Give them ~15 minutes to boot and another ~15 minutes for them to be fully configured. See below screenshots:

‍

‍

‍

‍

Did you try this out? How did it go? We look forward to your feedback. In a realistic scenario, vFW_PG and vFW_SINC are unlikely to be in the same cloud. So, in the next blog we will show you how to use two different VEXXHOST tenants to simulate two regions and then how you can spread the vFW service across those two tenants/regions.

In the meantime if you are looking for ONAP training, professional services or development distros (basically an easy way to try out ONAP < 1 hour), please contact us.

See Also: ONAP Wiki, vFWCL Wiki, Orchestrating Network Services Across Multiple OpenStack Regions Using ONAP blog

‍

On May-21, Amar Kapadia & I conducted a webinar on the topic of “Debugging OOM Failures”.

• Webinar video recording  
• Webinar slide deck

We started off by giving some context. Our objective was to develop a lightweight, repeatable lab environment for ONAP training on Google Cloud. We also plan to offer this image to developers that need a sandbox environment. To accomplish this, we used ONAP Amsterdam along with OPNFV Euphrates. ONAP was installed using OOM that uses Kubernetes and Helm. All of this software was installed on one VM on the Google cloud.

For most users, issues that pop up once in a while are OK. However, for us, the deployment process needed to be consistent and repeatable. For this reason, we had to debug every intermittent failure and develop a single-click workaround script.

The webinar next talked about the 7 issues we faced, how we debugged them and what the workarounds were. The issues faced were as follows. Other than failure#7, the other failures were all intermittent:

1. AAI containers failed to transition to Running state  
2. SDC UI is not getting loaded  
3. SDC Service Distribution Error  
4. VID Service Deployment Error  
5. VID ADD VNF Error  
6. SDNC User creation failed  
7. Robot init_robot failed with missing attributes

If you are curious to learn more, check out the slide deck or video links above. Additionally if you have ONAP training, PoC needs, or simply feel like trying out the VM image on GCP, feel free to contact us. We have a whole portfolio of training, services and product offerings.

I was fortunate enough to present ONAP & OPNFV training courses at the Open Source Networking User Group Bay Area Meetup on May-18, 2018. Please see the slide deck that I presented at the meetup. I was able to walk through the 4 courses available (½ day ONAP, ½ day OPNFV, full day ONAP, full day OPNFV) that are delivered online (through Linux Foundation) and in-person (through Aarna.ml). If you have any questions around training, please feel free to contact us.

In the previous installment of this two part blog series, we looked at why NFV clouds are likely to be highly distributed and why the management and orchestration software stack needs to support these numerous clouds. ONAP is one such network automation software stack. We saw the first three steps of what it takes to register multiple OpenStack cloud regions in

ONAP for the vFW use-case (other use cases might need slight tweaking).

Let’s pick up where we left off and look at the remaining steps 4-7:

Step 4: Associate Cloud Region object(s) with a subscriber's service subscription

With this association, this cloud region will be populated into the dropdown list of available regions for deploying VNF/VF-Modules from VID.

Example script to associate the cloud region  "CloudOwner/Region1x" with subscriber "Demonstration2" that subscribes to service "vFWCL":

curl -X PUT \  https://:8443/aai/v11/business/customers/customer/Demonstration2/service-subscriptions/service-subscription/vFWCL/relationship-list/relationship \

-H 'accept: application/json' \

-H 'authorization: Basic QUFJOkFBSQ==' \

-H 'cache-control: no-cache' \

-H 'content-type: application/json' \

-H 'postman-token: 4e6e55b9-4d84-6429-67c4-8c96144d1c52' \

-H 'real-time: true' \

-H 'x-fromappid: jimmy-postman' \

-H 'x-transactionid: 9999' \

-d ' {

  "related-to": "tenant",

  "related-link": "/aai/v11/cloud-infrastructure/cloud-regions/cloud-region/CloudOwner/Region1x/tenants/tenant/",

  "relationship-data": [

      {

          "relationship-key": "cloud-region.cloud-owner",

          "relationship-value": "CloudOwner"

      },

      {

          "relationship-key": "cloud-region.cloud-region-id",

          "relationship-value": ""

      },

      {

          "relationship-key": "tenant.tenant-id",

          "relationship-value": ""

      }

  ],

  "related-to-property": [

      {

          "property-key": "tenant.tenant-name",

          "property-value": ""

      }

  ]

}’

Step 5: Add Availability Zones to AAI

‍

Now we need to add an availability zone to the region we created in step 3.

Example script to add OpenStack availability zone name, e.g ‘nova’ to Region1x:

curl -X PUT \

https://:8443/aai/v11/cloud-infrastructure/cloud-regions/cloud-region/CloudOwner/Region1x/availability-zones/availability-zone/ \

-H 'accept: application/json' \

-H 'authorization: Basic QUFJOkFBSQ==' \

-H 'cache-control: no-cache' \

-H 'content-type: application/json' \

-H 'postman-token: 4e6e55b9-4d84-6429-67c4-8c96144d1c52' \

-H 'real-time: true' \

-H 'x-fromappid: AAI' \

-H 'x-transactionid: 9999' \

-d '{

  "availability-zone-name": "",

  "hypervisor-type": "",

  "operational-status": "Active"

}'

Step 6:  Register VIM/Cloud instance with SO

‍

SO does not utilize the cloud region representation from A&AI. It stores information of the VIM/Cloud instances inside the container (in the case of OOM) as a configuration file. To add a VIM/Cloud instance to SO, log into the SO service container and then update the configuration file "/etc/mso/config.d/cloud_config.json" as needed.

Example steps to add VIM/cloud instance info to SO:

# Procedure for mso_pass(encrypted)

# Go to the below directory on the kubernetes server

//onap/mso/mso

# Then run:

$ MSO_ENCRYPTION_KEY=$(cat encryption.key)

$ echo -n "your password in cleartext" | openssl aes-128-ecb -e -K MSO_ENCRYPTION_KEY -nosalt | xxd -c 256 –p

# Need to take the output and put it against the mso_pass

# value in the json file below. Template for adding a new cloud

# site and the associate identity service

$ sudo docker exec -it  bash

root@mso:/# vi /etc/mso/config.d/mso_config.json

"mso-po-adapter-config":

  {

    "identity_services":

    [

      {

        "dcp_clli1x": "DEFAULT_KEYSTONE_Region1x",

        "identity_url": ">/v2.0",

        "mso_id": "",

        "mso_pass": "",

        "admin_tenant": "service",

        "member_role": "admin",

        "tenant_metadata": "true",

        "identity_server_type": "KEYSTONE",

        "identity_authentication_type": "USERNAME_PASSWORD"

      },

"cloud_sites":

    [

      {

        "id": "Region1x",

        "aic_version": "2.5",

        "lcp_clli": "Region1x",

        "region_id": "",

        "identity_service_id": "DEFAULT_KEYSTONE_Region1x"

      },

# Save the changes and Restart MSO container

# Check the new config

http://:8080/networks/rest/cloud/showConfig # Note output below should match parameters used in the CURL Commands

# Sample output:

Cloud Sites:

CloudSite: id=Region11, regionId=RegionOne, identityServiceId=DEFAULT_KEYSTONE_Region11, aic_version=2.5, clli=Region11

CloudSite: id=Region12, regionId=RegionOne, identityServiceId=DEFAULT_KEYSTONE_Region12, aic_version=2.5, clli=Region12

Cloud Identity Services:

Cloud Identity Service: id=DEFAULT_KEYSTONE_Region11, identityUrl=, adminTenant=service, memberRole=admin, tenantMetadata=true, identityServerType=KEYSTONE, identityAuthenticationType=USERNAME_PASSWORD

Cloud Identity Service: id=DEFAULT_KEYSTONE_Regopm12, identityUrl=https://auth.vexxhost.net/v2.0, msoId=, adminTenant=service, memberRole=admin, tenantMetadata=true, identityServerType=KEYSTONE, identityAuthenticationType=USERNAME_PASSWORD

Step 7: Change Robot service to operate with the VIM/Cloud instance

‍

When using OOM, by default the Robot service supports the pre-populated cloud region where the cloud-owner is "CloudOwner" and cloud-region-id is specified via the parameters "openstack_region" during the deployment of the ONAP instance through OOM configuration files. This cloud region information can be updated in the file "/share/config/vm_properties.py" inside the robot container. Appropriate relationships between Cloud Regions and Services need to be setup in the same file for Robot Service Tests to pass.


Note:  Robot framework does not rely on Multi-VIM/ESR.

If you have done all 7 steps correctly, Robot tests should pass and both regions should appear in the VID GUI.

If you liked (or disliked) this blog, we’d love to hear from you. Please let us know. Also if you are looking for ONAP training, professional services or development distros (basically an easy way to try out ONAP on Google Cloud in <1 hour), please contact us. Professional services include ONAP deployment, network service design/deployment, VNF onboarding, custom training etc.

References:

ONAP Wiki

vFWCL Wiki

‍

NFV clouds are going to be distributed by their very nature. VNFs and applications will be distributed as per the below figure: horizontally across edge (access), regional datacenter (core) and hyperscale datacenters (could be public clouds) or vertically across multiple regional or hyperscale datacenters.

The Linux Foundation Open Network Automation Platform (ONAP) project is a management and orchestration software stack that automates network/SDN service deployment, lifecycle management and service assurance. For the above-mentioned reasons, ONAP is designed to support multiple cloud regions from the ground up.

In this two-part blog, we will walk you through the exact steps to register multiple cloud regions with ONAP for the virtual firewall (vFW) use-case that primarily utilizes SDC, SO, A&AI, VID and APP-C projects (other use cases will be similar but might require slightly different instructions). Try it out and let us know how it goes.

Prerequisites

1. ONAP Installation (Amsterdam release)  
2. OpenStack regions spread across different physical locations  
3. Valid Subscriber already created under ONAP (e.g Demonstration2)

If you do not have the above, and still want to try this out, here are some alternatives:

ONAP Region Registration Steps

There are 3 locations where VIM/cloud instance information is stored: A&AI, SO & Robot. The following 7 steps outline the steps and provide sample API calls.

Step 1: Create Complex object(s) in AAI

‍

A complex object in A&AI represent the physical location of a VIM/Cloud instance. Create a complex object for each OpenStack Region that needs to be configured under ONAP


Example script to do create complex object named clli1x:

# Main items to be changed are highlighted, but most of the below

# information should be customized for your region

curl -X PUT \ https://:8443/aai/v11/cloud-infrastructure/complexes/complex/clli1x \

-H ‘X-TransactionId: 9999’ \

-H ‘X-FromAppId: jimmy-postman’ \

-H ‘Real-Time: true’ \

-H ‘Authorization: Basic QUFJOkFBSQ==’ \

-H ‘Content-Type: application/json’ \

-H ‘Accept: application/json’ \

-H ‘Cache-Control: no-cache’ \

-H ‘Postman-Token: 734b5a2e-2a89-1cd3-596d-d69904bcda0a’ \

 -d   ‘{

          "physical-location-id": "clli1x",

          "data-center-code": "example-data-center-code-val-6667",

          "complex-name": "clli1x",

          "identity-url": "example-identity-url-val-28399",

          "physical-location-type": "example-physical-location-type-val-28399",

          "street1": "example-street1-val-28399",

          "street2": "example-street2-val-28399",

          "city": "example-city-val-28399",

          "state": "example-state-val-28399",

          "postal-code": "example-postal-code-val-28399",

          "country": "example-country-val-28399",

          "region": "example-region-val-28399",

          "latitude": "example-latitude-val-28399",

          "longitude": "example-longitude-val-28399",

          "elevation": "example-elevation-val-28399",

          "lata": "example-lata-val-28399"

      }’

‍

Step 2: Create Cloud Region object(s) in A&AI

‍

The VIM/Cloud instance is represented as a cloud region object in A&AI and ESR. This representation will be used by VID, APP-C, VFC, DCAE, MultiVIM, etc. Create a cloud region object for each OpenStack Region.

Example script to create cloud region object for the same cloud region:

curl -X PUT \

'https://:8443/aai/v11/cloud-infrastructure/cloud-regions/cloud-region/CloudOwner/Region1x \

-H 'accept: application/json' \

-H 'authorization: Basic QUFJOkFBSQ==' \

-H 'cache-control: no-cache' \

-H 'content-type: application/json' \

-H 'postman-token: f7c57ec5-ac01-7672-2014-d8dfad883cea' \

-H 'real-time: true' \

-H 'x-fromappid: jimmy-postman' \

-H 'x-transactionid: 9999' \

-d ‘{

  "cloud-owner": "CloudOwner",

  "cloud-region-id": "Region1x",

  "cloud-type": "openstack",

  "owner-defined-type": "t1",

  "cloud-region-version": "",

  "cloud-zone": "",

  "complex-name": "clli1x",

  "identity-url": "/v3>",

  "sriov-automation": false,

  "cloud-extra-info": "",

  "tenants": {

      "tenant": [

          {

              "tenant-id": "",

              "tenant-name": ""

          }

      ]

  },

  "esr-system-info-list":

  {    

      "esr-system-info":

      [

          {

              "esr-system-info-id": "",

              "service-url": "/v3>",

              "user-name": "",

              "password": "",

              "system-type": "VIM",

              "ssl-cacert": "",

              "ssl-insecure": true,

              "cloud-domain": "Default",

              "default-tenant": ""

          }

      ]

  }

}’

‍

Step 3: Associate each Cloud Region object with corresponding Complex Object

‍

This needs to be setup for each cloud region with the corresponding complex object.

Example script to create the association:

curl -X PUT \ https://:8443/aai/v11/cloud-infrastructure/cloud-regions/cloud-region/CloudOwner/Region1x/relationship-list/relationship \

-H 'accept: application/json' \

-H 'authorization: Basic QUFJOkFBSQ==' \

-H 'cache-control: no-cache' \

-H 'content-type: application/json' \

-H 'postman-token: e68fd260-5cac-0570-9b48-c69c512b034f' \

-H 'real-time: true' \

-H 'x-fromappid: jimmy-postman' \

-H 'x-transactionid: 9999' \

-d '{

  "related-to": "complex",

  "related-link": "/aai/v11/cloud-infrastructure/complexes/complex/clli1x",

  "relationship-data": [{

          "relationship-key": "complex.physical-location-id",

          "relationship-value": "clli1x"

  }]

}’

We will cover the remaining 4 steps in the next and final installment of this blog series.

In the meantime if you are looking for ONAP training, professional services or development distros (basically an easy way to try out ONAP < 1 hour), please contact us.

‍