Skip to main content
search

ONAP vFW Blueprint Across Two Regions

By June 12, 2018July 27th, 2018Blog

This post originally appeared on Arana Networks. Republished with permission.

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:

vFW Network Topology on Tenant2

vFW Network Topology on Tenant1

VNF SINC Stack Orchestrated on OpenStack Tenant2

VNF PG Stack Orchestrated on OpenStack Tenant1

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

Close Menu