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:
Create an account on VEXXHOST with 2 different tenants.
If Registering the VEXXHOST into A&AI using ESR UI, change the password length to less than 20 characters.
On Tenant1 manually create OAM network, unprotected_private networks with different subnets than on Tenant2.
On Tenant2, create an OAM network using the VEXXHOST cloud Horizon dashboard.
Add security rules to allow ingress ICMP, SSH &all the required ports along with IPV6 from both the tenants.
Edit the base_vfw.env and base_vpkg.env VNF descriptor files to configure them correctly based on the respective Tenants.
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:
SDC designer role: Create vendor license model
SDC designer/tester role: Onboard and test VNFs (or vendor software product i.e. VSP)
SDC designer role: Design network service
SDC tester role: Test network service
SDC governor role: Approve network service
SDC ops role: Distribute network service
VID: Instantiate network service
VID: Add VNFs to network service
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
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.