A Cost Effective Way to Try the ONAP vFW Blueprint

The Open Network Automation Platform (ONAP) is a Linux Foundation project that provides a way to design network services, manage their life-cycle and perform service assurance using real-time policy driven closed-loop automation (i.e. no humans involved, policies directly drive life-cycle 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:

  1. 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.
  2. 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 Network 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:

  1. vFW_PG (packet generator)
  2. 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 (yes needed)
  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:

SINC GUI

 

We look forward to your feedback. Did you try this out? How did it go?

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 Cloud Services – ONAP, OpenStack, Kubernetes, Cloud Native Application, DevSecOps and Infrastructure Modernization please contact us.

References:

ONAP Wiki
vFWCL Wiki
Orchestrating Network Services Across Multiple OpenStack Regions Using ONAP

Contributor: Subba Rao Kodavalla

By Biarca