This page documents the steps taken to set up the vFW Closed Loop test as part of an investigation to identify changes needed to support the same.

The general method used was to review the operation of the integration Robot 'instantiatevFWCL' and 'vfwclosedloop' test and replicate the steps manually for an instance of vFW deployed to a K8S cloud region.

Recap of the vFW closed loop test

The following things are needed to run the closed loop test:

1. APPC must be able to perform a netconf mount to the VPP honeycomb component of the Packet Generator so that the number of packet streams produced by the packet generator can be configured in response to policy reacting to a threshold event.  In the case of the K8S vFW, this requires that a Service be added which exposes a NodePort (at least, this is the approach taken for this investigation).
2. DCAE must be able to receive VES events sent by the vFirewall component.  In the K8S vFW instance, this was possible to do, although the DCAE IP and Port values were not passed in, so the VES sending application needed to be restarted with the correct values.
3. The statistics reported by the vSink component need to be exposed via a Service (already present in the K8S vFW helm charts).  This is convenient for monitoring the behavior of the vFW and its reaction to configuration changes - whether made manually or by Policy.

Notes on the environment used for the investigation

This was done on a Dublin installation running in the Intel ONAP Integration Lab.  The K8S KUD cloud region was running as a single node cluster running in a VM in another single server Titanium Cloud system which has external network connectivity to the ONAP Integration system - e.g. on the 10.12.x.x network.

The K8S vFW instance was deployed per the steps described here: Deploying vFw and EdgeXFoundry Services on Kubernets Cluster with ONAP and as presented here:  https://wiki.lfnetworking.org/download/attachments/15630468/ONAP_Dublin_SO_Multicloud.pdf?version=1&modificationDate=1560495527000&api=v2

Per the issue here:   MULTICLOUD-718 - Getting issue details... STATUS  multicloud was deleted, multicloud-k8s updated to version 1.4.0 and then multicloud was redeployed. (before onboarding and distributing the K8S VF and Service)

root@onap-rancher:~/oom# git diff
diff --git a/kubernetes/multicloud/values.yaml b/kubernetes/multicloud/values.yaml
index bff78caf..00fd8c33 100644
--- a/kubernetes/multicloud/values.yaml
+++ b/kubernetes/multicloud/values.yaml
@@ -20,7 +20,7 @@ global:
   nodePortPrefix: 302
   loggingRepository: docker.elastic.co
   loggingImage: beats/filebeat:5.5.0
-  artifactImage: onap/multicloud/framework-artifactbroker:1.3.3
+  artifactImage: onap/multicloud/framework-artifactbroker:1.4.0
   prometheus:
     enabled: false

@@ -29,7 +29,7 @@ global:
 #################################################################
 # application image
 repository: nexus3.onap.org:10001
-image: onap/multicloud/framework:1.3.3
+image: onap/multicloud/framework:1.4.0
 pullPolicy: Always

 #Istio sidecar injection policy

Setting up a Service the Packet Generator netconf mount

In the K8S cloud region, a Service needed to be added to expose the netconf port.

Such as:  kubectl create -f pgservice.yaml where:

apiVersion: v1
kind: Service
metadata:
  name: packetgen-service
  labels:
    app: packetgen
    chart: packetgen
    release: profile1
spec:
  selector:
    app: packetgen
    release: profile1
  ports:
  - port: 2831
    nodePort: 30831
    protocol: TCP
    targetPort: 2831
  type: NodePort

This exposes the packet generator honeycomb port 2831 to the K8S cloud region nodes as NodePort 30831.

On the ONAP side, the APPC netconf mount was then created using a Postman command:

PUT http://{{AAI1_PUB_IP}}:30230/restconf/config/network-topology:network-topology/topology/topology-netconf/node/ef4aa32c-0eb9-46c0-b6b0-c6a35184f07b

with a body of:

<node xmlns="urn:TBD:params:xml:ns:yang:network-topology">
<node-id>ef4aa32c-0eb9-46c0-b6b0-c6a35184f07b</node-id>
<host xmlns="urn:opendaylight:netconf-node-topology">10.12.17.12</host>
<port xmlns="urn:opendaylight:netconf-node-topology">30831</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>
<!-- non-mandatory fields with default values, you can safely remove these if you do not wish to override any of these values-->
<reconnect-on-changed-schema xmlns="urn:opendaylight:netconf-node-topology">false</reconnect-on-changed-schema>
<connection-timeout-millis xmlns="urn:opendaylight:netconf-node-topology">20000</connection-timeout-millis>
<max-connection-attempts xmlns="urn:opendaylight:netconf-node-topology">0</max-connection-attempts>
<between-attempts-timeout-millis xmlns="urn:opendaylight:netconf-node-topology">2000</between-attempts-timeout-millis>
<sleep-factor xmlns="urn:opendaylight:netconf-node-topology">1.5</sleep-factor>
<!-- keepalive-delay set to 0 turns off keepalives-->
<keepalive-delay xmlns="urn:opendaylight:netconf-node-topology">120</keepalive-delay>
</node>

The node-id 'ef4aa32c-0eb9-46c0-b6b0-c6a35184f07b' is the generic-vnf-id of the deployed K8S vFW VNF.

The host IP '10.12.17.12' is the host IP of the K8S KUD cluster and the port '30831' is the exposed node port as described above.

Once this netconf mount is executed, the K8s vFW packet generator should show up in the APPC list of Mounted Resources - and the packet generator stream-count can be controlled from APPC.

Stop the automatic vFW packet generator test

Note - that after it is deployed the packet generator automatically starts a script called run_traffic_fw_demo.sh.

Before running closed loop, this script should be terminated.  This script will alternate between running 1 and 10 packet streams (e.g. 100 or 1000 packets per second).

When running the closed loop test, this script will interfere so it is best to stop it.

Configure the Firewall to send VES events to DCAE

The vFirewall component sends VES using the 'vpp_measurement_reporter' program found in the directory '/opt/VES/evel/evel-library/code/VESreporting'.

By default this will be running following deployment, but it will be using the wrong parameters.  To fix, do the following:

• Edit the files /opt/config/dcae_collector_ip.txt and /opt/config/dcae_collector_port.txt and place in them the IP and port for the DCAE collector of the ONAP.

For example:

root@profile1-firewall-6558957c88-2rxdh:/opt/config# cat dcae_collector_ip.txt
10.12.5.63                                                                     t
root@profile1-firewall-6558957c88-2rxdh:/opt/config# cat dcae_collector_port.txt
30235

Where the address '10.12.5.63' is a Host IP of one of the ONAP cluster nodes and port '30235' is the port of the DCAE VES collector service.

Once this is done, run the 'go-client.sh' script, which is also found in the directory '/opt/VES/evel/evel-library/code/VESreporting'

#!/bin/bash

export LD_LIBRARY_PATH="/opt/VES/evel/evel-library/libs/x86_64/"
DCAE_COLLECTOR_IP=$(cat /opt/config/dcae_collector_ip.txt)
DCAE_COLLECTOR_PORT=$(cat /opt/config/dcae_collector_port.txt)
./vpp_measurement_reporter $DCAE_COLLECTOR_IP $DCAE_COLLECTOR_PORT eth1

Add a vserver object to AAI

Configure the vFW Closed Loop Policy