vFWCL instantiation, testing, and debuging
Pre-requisite
Setup the OOM Infrastructure; I've used OOM on Rancher in OpenStack
Running vFW demo - Close-loop
Video of onboarding
I had a hickup at the end, due to the fact I already had another vFW deployed, hence the ip it tried to assign was used. To fix this, I remove the existing stack.
Video of instantiation
I had a a hickup for the vFW_PG due to the fact I pre-loaded on the wrong instance. After realizing, all went well.
Let's start by running the init goal (assuming K8S namespace, where ONAP has been installed is "onap")
cd oom/kubernetes/robot $ ./demo-k8s.sh onap init
Result:
Login into the VNC. Password is password
<kubernetes-vm-ip>:30211
Open the browser and navigate to the ONAP Portal
Login using the Designer user. cs0008/demo123456!
http://portal.api.simpledemo.onap.org:8989/ONAPPORTAL/login.htm
- Virtual Licence Model creation
- Open SDC application, click on the OnBoard tab.
- click Create new VLM (Licence Model)
- Use onap as Vendor Name, and enter a description
- click save
- click Licence Key Group and Add Licence KeyGroup, then fill in the required fields
- click Entitlements Pools and Add Entitlement Pool, then fill in the required fields
- click Feature Groups and Add Feature Group, then fill in the required fields. Also, under the Entitlement Pools tab, drag the created entitlement pool to the left. Same for the License Key Groups
- click Licence Agreements and Add Licence Agreement, then fill in the required fields. Under the tab Features Groups, drag the feature group created previously.
- then check-in and submit
- go back to OnBoard page
- click Create new VLM (Licence Model)
- Open SDC application, click on the OnBoard tab.
- Vendor Software Product onboarding and testing
- click Create a new VSP
- First we create the vFW sinc; give it a name, i.e. vFW_SINC. Select the Vendor (onap) and the Category (Firewall) and give it a description.
- Click on the warning, and add a licence model
- Get the zip package: vfw-sinc.zip
- Click on overview, and import the zip
- Click Proceed to validation then check-in then submit
- click Create a new VSP
- Then we create the vFW packet generator; give it a name, i.e. vFW_PG. Select the Vendor (onap) and the Category (Firewall) and give it a description.
- Click on the warning, and add a licence model
- Get the zip package: vfw_pg.zip
- Click on overview, and import the zip
- Click Proceed to validation then check-in then submit
- Go to SDC home. Click on the top right icon with the orange arrow.
- Import the VSP one by one
- Submit for both testing
- Logout and Login as the tester: jm0007/demo123456!
- Go to the SDC portal
- Test and accept the two VSP
- click Create a new VSP
- Service Creation
- Logout and login as the designer: cs0008/demo123456!
- Go to the SDC home page
- Click Add a Service
- Fill in the required field
- Click Create
- Click on the Composition left tab
- In the search bar, type "vFW" to narrow down the created VSP, and drag them both.
- Then click Submit for Testing
- Service Testing
- Logout and Login as the tester: jm0007/demo123456!
- Go to the SDC portal
- Test and accept the service
- Service Approval
- Logout and Login as the governor: gv0001/demo123456!
- Go to the SDC portal
- Approve the service
- Service Distribution
- Logout and Login as the operator: op0001/demo123456!
- Go to the SDC portal
- Distribute the service
- Click on the left tab monitor and click on arrow to open the distribution status
- Wait until everything is distributed (green tick)
- Service Instance creation:
- Logout and Login as the user: demo/demo123456!
- Go to the VID portal
- Click the Browse SDC Service Models tab
- Click Deploy on the service to deploy
- Fill in the required field, call it vFW_Service for instance. Once done, this will redirect you to a new screen
- Click Add VNF, and select the vFW_SINC VNF first
- Fill in the required field. Call it vFW_SINC_VNF, for instance.
- Click Add VNF, and select the vFW_PG_VNF first
- Fill in the required field. Call it vFW_PG_VNF, for instance.
- SDNC preload:
Then go to the SDNC Admin portal and create an account
<kubernetes-host-ip>:30201/signup
Login into the SDNC admin portal
<kubernetes-host-ip>:30201/login
- Click Profiles then Add VNF Profile
- The VNF Type is the string that looks like this: VfwPg..base_vpkg..module-0 It can be copy/paste from VID, when attempting to create the VF-Module
- Enter 100 for the Availability Zone Count
- Enter vFW for Equipment Role
- Repeat the same for the other VNF
Pre-load the vFW SINC. Mind the following values:
service-type: it's the service instance ID of the service instance created step 9
vnf-name: the name to give to the VF-Module. The same name will have to be re-use when creating the VF-Module
vnf-type: Same as the one used to add the profile in SDNC admin portal
generic-vnf-name: The name of the created VNF, see step 9f
vfw_name_0: is the same as the generic-vnf-name
generic-vnf-type: Can be find in VID, please see video if not found.
dcae_collector_ip: Has to be the IP address of the dcaedoks00 VM
Make sure image_name, flavor_name, public_net_id, onap_private_net_id, onap_private_subnet_id, key_name and pub_key reflect your environmentExpected result:
{ "output": { "svc-request-id": "robot12", "response-code": "200", "ack-final-indicator": "Y" } }
Pre-load the vFW PG. Mind the following values:
service-type: it's the service instance ID of the service instance created step 9
vnf-name: the name to give to the VF-Module. The same name will have to be re-use when creating the VF-Module
vnf-type: Same as the one used to add the profile in SDNC admin portal
generic-vnf-name: The name of the created VNF, see step 9h
vpg_name_0: is the same as the generic-vnf-name
generic-vnf-type: Can be find in VID, please see video if not found.
Make sure image_name, flavor_name, public_net_id, onap_private_net_id, onap_private_subnet_id, key_name and pub_key reflect your environmentExpected result:
{ "output": { "svc-request-id": "robot12", "response-code": "200", "ack-final-indicator": "Y" } }
- Create the VF-Module for vFW_SINC
- The instance name must be the vnf-name setup in the preload phase.
- After a few minutes, the stack should be created.
- Create the VF-Module for vFW_PG
- The instance name must be the vnf-name setup in the preload phase.
- After a few minutes, the stack should be created.
Close loop
Run heatbridge robot tag to tell AAI about the relationship between the created HEAT stack (SINC one) and the service instance id.
To run this, you need:
- the heat stack name of the vSINC
- the service instance id- Upload operational policy: this is to tell policy that for this specific instance, we should apply this policy.
Retrieve from MSO Catalog the modelInvariantUuid for the vFW_PG. Specify in the below request the service-model-name, as defined step 5.c.
curl -X GET \ 'http://<kubernetes-host>:30223/ecomp/mso/catalog/v2/serviceVnfs?serviceModelName=<service-model-name>' \ -H 'Accept: application/json' \ -H 'Authorization: Basic SW5mcmFQb3J0YWxDbGllbnQ6cGFzc3dvcmQxJA==' \ -H 'Content-Type: application/json' \ -H 'X-FromAppId: Postman' \ -H 'X-TransactionId: get_service_vnfs'
Based on the payload below, result would be: 86a1bdd8-1f59-4796-bf30-3002108068f6
Under
oom/kubernetes/policy/script
invoke the script as follows:
Usage: update-vfw-op-policy.sh <k8s-host> <policy-pdp-node-port> <policy-drools-node-port> <resource-id> ./update-vfw-op-policy.sh 10.195.197.53 30220 30221 86a1bdd8-1f59-4796-bf30-3002108068f
Result can look like, with debug enable (/bin/bash -x)
- Mount APPC
Get the VNF instance ID, either through VID or through AAI. Below the AAI request
curl -X GET \ https://<kubernetes-host>:30233/aai/v8/network/generic-vnfs/ \ -H 'Accept: application/json' \ -H 'Authorization: Basic QUFJOkFBSQ==' \ -H 'Content-Type: application/json' \ -H 'X-FromAppId: Postman' \ -H 'X-TransactionId: get_generic_vnf'
In the result, search for the vFW_PG_VNF and get its vnf-id. In the payload below, it would be e6fd60b4-f436-4a21-963c-cc9060127633
- Get the public IP address of the Packet Generator from your deployment.
In the below curl request, replace <vnf-id> with the VNF ID retrieved at step 2.a (it needs to be updated at two places), and replace <vnf-ip> with the ip retrieved at step 2.b.
curl -X PUT \ http://<kubernetes-host>:30230/restconf/config/network-topology:network-topology/topology/topology-netconf/node/<vnf-id> \ -H 'Accept: application/xml' \ -H 'Authorization: Basic YWRtaW46S3A4Yko0U1hzek0wV1hsaGFrM2VIbGNzZTJnQXc4NHZhb0dHbUp2VXkyVQ==' \ -H 'Content-Type: text/xml' \ -d '<node xmlns="urn:TBD:params:xml:ns:yang:network-topology"> <node-id><vnf-id></node-id> <host xmlns="urn:opendaylight:netconf-node-topology"><vnf-ip></host> <port xmlns="urn:opendaylight:netconf-node-topology">2831</port> <username xmlns="urn:opendaylight:netconf-node-topology">admin</username> <password xmlns="urn:opendaylight:netconf-node-topology">admin</password> <tcp-only xmlns="urn:opendaylight:netconf-node-topology">false</tcp-only> </node>'
If you want to verify the NETCONF connection has successfully being established, use the following request (replace <vnd-id> with yours
curl -X GET \ http://<kubernetes-host>:30230/restconf/operational/network-topology:network-topology/topology/topology-netconf/node/<vnf-id> \ -H 'Accept: application/json' \ -H 'Authorization: Basic YWRtaW46S3A4Yko0U1hzek0wV1hsaGFrM2VIbGNzZTJnQXc4NHZhb0dHbUp2VXkyVQ=='
Result should be:
Using NETCONF, let's get the current streams being active in our Packet Generator. The number of streams will change along the time, this is the result of close-loop policy. When the traffic goes over a certain threshold, DCAE will publish an event on the unauthenticated.DCAE_CL_OUTPUT topic that will be picked up by APPC, that will send a NETCONF request to the packet generator to adjust the traffic it's sending.
curl -X GET \ http://10.195.197.53:30230/restconf/config/network-topology:network-topology/topology/topology-netconf/node/e6fd60b4-f436-4a21-963c-cc9060127633/yang-ext:mount/sample-plugin:sample-plugin/pg-streams \ -H 'Accept: application/json' \ -H 'Authorization: Basic YWRtaW46S3A4Yko0U1hzek0wV1hsaGFrM2VIbGNzZTJnQXc4NHZhb0dHbUp2VXkyVQ=='
Browse to the zdfw1fwl01snk01 on port 667 to see a graph representing the traffic being received:
http://<zdfw1fwl01snk01>:667/
As you can see in the below graph, looking at the top right square, we can see the first two fluctuations are going from very low to very high. This is when close-loop isn't running.
Once close-loop is running, you'll have some medium bars.Check the events sent by Virtual Event Collector (VES) to Threshold Crossing Analytic (TCA) app:
curl -X GET \ http://<K8S_IP>:3904/events/unauthenticated.SEC_MEASUREMENT_OUTPUT/group1/C1 \ -H 'Accept: application/json' \ -H 'Content-Type: application/cambria'
The VES resides in the VNF itself, whereas the TCA is an application running on Cask. A DCAE component.
Check the events sent by TCA on unauthenticated.DCAE_CL_OUTPUT:
curl -X GET \ http://<K8S_IP>:3904/events/unauthenticated.DCAE_CL_OUTPUT/group1/C1 \ -H 'Accept: application/json' \ -H 'Content-Type: application/cambria'
Those events are the resulting of the TCA application, e.g. TCA has noticed an event was crossing a given threshold, hence is sending a message of that particular topic. Then Policy will grab this event and perform the appropriate action, as defined in the Policy. In the case of vFWCL, Policy will send an event on the APPC_CL topic, that APPC will consume. This will trigger a NETCONF request to the packet generator to adjust the traffic.
I hope everything worked for you, if not, please leave a comment. Thanks