packaged nfv solutions

Packaged NFV Solutions

Nov 14, 2018

By the end of this lab you will be able to instantiate, configure and operateF5 VNF Manager product to deploy Gilan BIG-IP blueprint. Follow the labguide and support personnel instructions to create and start UDF VNFm

environment

1 F5 Virtual Network Function Manager (VNFM) 11.1 About F5 Virtual Network Function Manager (VNFM) . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Part I. Review and prepare UDF Openstack environment . . . . . . . . . . . . . . . . . . . . . . . . 21.3 VNF Manager deployment Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91.4 Part II: Deploy F5 VNF Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121.5 Part III. Deploy local F5 Gilan blueprint and create traffic server VM . . . . . . . . . . . . . . . . . 151.6 Part IV. Trigger auto scale-out . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221.7 Part V. Initiate manual scale-out . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231.8 Part VI. Configuration change . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251.9 Part VII. (Optional) Uninstall workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321.10 VNF manager Workflows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331.11 Use the Secret Store . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 391.12 Sample Gi LAN Inputs File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

i

CHAPTER 1

F5 Virtual Network Function Manager (VNFM)

1.1 About F5 Virtual Network Function Manager (VNFM)

Customer-facing documentation can be found here:

F5 utilizes a third-party orchestration framework to bring you the F5 Virtual Network Function Manager (VNFM).This cloud orchestration tool uses blueprints and plugins to manage the processing resources between your packetgateway and the Internet (Gi-LAN), in a private cloud environment (such as, OpenStack), auto-scaling your BIG-IPVE virtual machines, during high-volume periods. VNFM relies on BIG-IQ 6.0.1 and BIG-IP 13.1.1 images to provideservices such as, scaling services and resources, load-balancing, and high availability (HA).

When finished deploying your VNFM, you will have the following system:

1


F5 VNFM resides in the layer. Once you upload BIG-IQ, BIG-IP, and the VNFM images into OpenStack, and deploythe VNFM blueprint, the BIG-IQ license manager, BIG-IPs deployed by the blueprint, and your VNFM will comprisethe management network.

Traffic will pass through the disaggregation (DAG) tier and the predefined-throughput service layers, connecting yoursubscriber packet gateway with the Internet (Gi LAN). The service layers will auto-scale out or add virtual machineinstances, depending on your traffic demands. BIG-IPs in the DAG tier load-balance the subscriber traffic acrossBIG-IP VEs providing the virtualized network functions (VNF) inside the VNF service layer. This diagram depicts ansetting for the Gilan solution, auto_last_hop set to disabled (default), routing the return traffic through the DAG tier.However, this is a configurable setting in the F5 blueprint, which you can enable, and route return traffic directly backto the VNF service layer (bypassing the DAG tier).

Processes like, your policy engines, your subscriber service-charging functions, and signaling will occur on the controlnetwork.

What’s Next?

Review and Prepare UDF Blueprint

1.2 Part I. Review and prepare UDF Openstack environment

UDF blueprint for VNF manager lab has been created with Openstack Newton ( community equivalent of RH OSP 10).Due to UDF specifics, parts of networking config need to be re-created for each deployment. In order to successfullyuse VNF manager lab you will need to run the specified script and review network configuration inside the Openstack

1. Blueprint setup

2 Chapter 1. F5 Virtual Network Function Manager (VNFM)


2. Credentials

3. Start UDF Environment

4. Review Openstack configuration

5. Verify BIG-IQ route

1.2.1 Blueprint setup

1.2.2 Credentials

Blueprint component username/passwordBIG-IQ TMUI admin/adminBIG-IQ SSH root/defaultjumphost xRDP ubuntu/ravelloCloudOpenstack Horizon UI f5admin/f5adminVNFmanager VM admin/adminBIG-IP VMs TMUI admin/adminBIG-IP VMs SSH root/defaultOpenstack CLI(controller) sudo -i;source keystonerc_f5adminkeystone f5admin/f5admin

1.2.3 Start UDF environment

1. Deploy “Packaged NFV Solutions” blueprint and start it Southwest(Arizona) or East(Virginia) Ravelloregion

1.2. Part I. Review and prepare UDF Openstack environment 3


2. Wait until all components are in “Running” state. BIG-IQ usually boots last

3. Login to BIG-IQ TMUI and ensure “regkeys” licenses are present and unexpired



Warning: Wait at least 5 minutes to allow Openstack Services to come up before running the script

4. xRDP to jumphost and run “run_this_first.sh” script

Note: When prompted, choose to run the script in Terminal

Note: Script performs the following: Creates extnet Openstack network and 2 Routers with corresponding interfaces;starts rabbitmq-server on controller node; forces Nova service to register compute nodes with new hostnames andcreates necessary routes on jumphost and BIG-IQ VMs

5. Point Firefox browser to Openstack Horizon Dashboard at http://10.1.20.4/



6. Login with f5admin user

1.2.4 Review Openstack configuration

The private cloud environment (for example, OpenStack) must have the following administrative components definedPRIOR to deploying F5 VNFM. (Click the following links to learn more about using the latest version of OpenStack,or refer to the documentation specific to the version you are using.)

Note: Openstack in this blueprint has been pre-configured and no action is required. Review table below and compareit to components found in Openstack Horizon Dashboard.



Component Description(Admin->Flavors) Defined flavors sized to accommodate the VNFM com-

ponent images. BIG-IP VEs use m1.large flavor:• vCPU: 4• RAM: 8GB• Root disk: 160GB

(Project->Network) The following networks and one subnet for each, de-fined with sufficient IP address space in each networkhave been created:

• Management network (mgmt) – VNF Managerand BIG-IP VE management interfaces are on thisnetwork.

• Provider gateway network (pgw_net) – Networkused for the internal-facing DAG data plane inter-faces.

• Provider data network (pdn_net) – Network usedfor the external-facing DAG data plane interfaces.

• DAG to provider gateway network(pgw_dag_net) – Network used for the internal-facing VNF data plane interfaces.

• DAG to provider data network (pdn_dag_net) –Network used for the external-facing VNF dataplane interfaces.

• Control network (control_net) – Network fused orcommunication with control and value-added ser-vices.

• HA network (ha_net) – Network used for internalHA communication between clustered VNF BIG-IP VE instances.

(Project->Compute->Access and Security) The following security groups created:• SNMP security group (snmp_sg) – Allow UDP

ports 161/162.• Control security group (control_sg) – Configure

as needed for your envronment.• Management security group (mgmt_sg) – Allow

TCP port 443.• Provider data network security group (pdn_sg) –

Configure as needed for your envronment.• Provider gateway security group (pgw_sg) – Con-

figure as needed for your envronment.

(Project->Compute->Access and Security) Defined key pairs for accessing VNFM instance re-motely, using SSH.

(Project->Network->Routers) Created 2 routers with interfaces into VxLANs (router1is connected to extnet)

1.2.5 Verify BIG-IQ route

Open UDF Console or SSH(47010) to BIG-IQ and confirm that route to 10.1.40.0/24 network is present and networkis reachable. Gateway IP is unique for each deployment and depends on Openstack Router interface extnet IP



[root@bigiq1:Active:Standalone] config # tmsh list net routenet route openstack {gw 10.1.20.105network 10.1.40.0/24}[root@bigiq1:Active:Standalone] config # ping 10.1.40.1PING 10.1.40.1 (10.1.40.1) 56(84) bytes of data.64 bytes from 10.1.40.1: icmp_seq=1 ttl=64 time=7.18 ms64 bytes from 10.1.40.1: icmp_seq=2 ttl=64 time=3.53 ms64 bytes from 10.1.40.1: icmp_seq=3 ttl=64 time=3.66 ms64 bytes from 10.1.40.1: icmp_seq=4 ttl=64 time=3.05 ms^C--- 10.1.40.1 ping statistics ---4 packets transmitted, 4 received, 0% packet loss, time 3558msrtt min/avg/max/mdev = 3.056/4.359/7.180/1.644 ms

Note: If BIG-IQ doesn’t show a valid route into .40 subnet, run the “run_this_first.sh” script again and seek assistancebefore proceeding further



What’s Next?

Set up VNFM

1.3 VNF Manager deployment Prerequisites

Upon purchasing a VFNM solution, customer will receive an email with a VNFM install package download URL, aswell as an associated product license key, which is used only for obtaining support. For the purpose of this lab, VNFMpackage has already been downloaded and stored in Openstack Glance. To learn more about Glance procedures, see

1.3.1 Prerequisites

In addition to the VNFM install package, the following supported components have been downloaded from and storedin Glance:

• and F5-BIQ-VE-LIC-MGR-LIC license key–This activates the BIG-IQ utility that manages licensing for BIG-IPs (utility pools) during orchestration.

• and F5-BIG-MSP-LOADV6-LIC license key–Use the Utility License, (if connected to the Internet) or the (ifnot connected).

1.3.2 F5 VNFM Solutions

F5 offers the following VNFM solutions with built-in services. This lab uses Gi LAN Solution Blueprint

1.3. VNF Manager deployment Prerequisites 9


Solution DescriptionGi LAN VNFM is comprised of an F5 blueprint with specific

parameters plus a Gi LAN inputs YAML file that de-fines those parameters with your system requirements.These components use plugins, enabling you to auto-matically deploy all the necessary pieces to create ahighly-available set of services, deployed in service lay-ers. These layers auto-scale virtual machines and ser-vices to provide a complete and fully configured lifecy-cle management workflow:

1. Install (push button)2. Auto-Scale (out and in)3. Auto-Heal (with quarantine of instances for trou-

bleshooting)4. Update (push button)5. Upgrade (push button)6. Delete (push button)

Gi Firewall VNFM is comprised of an F5 blueprint with specific pa-rameters plus this solution also uses the same Gi LANinputs YAML file as the previous solution, which de-fines those parameters with your system requirements.These components use plugins enabling you to utilizefirewall protection services only like, DDoS mitigation,DNS security, and intrusion protection

VNFM Base VNFM is comprised of a base F5 blueprint and a baseinputs YAML file, lacking monitoring and resource col-lecting parameters, plus a VNFM Base inputs file thatdefines those base parameters with your system require-ments.

1.3.3 F5 blueprint

A blueprint is a model of your application’s topology and its operations implementation written in a YAML DomainSpecific Language (DSL). The F5 blueprint defines all node types and the relationship between each node, for example:

imports:- gilan_vnfd.yaml

inputs:pgw_min_instance_number:type: integerdefault: 1

pgw_max_instance_number:type: integerdefault: 1000

pdn_min_instance_number:type: integerdefault: 1

pdn_max_instance_number:type: integerdefault: 1000

(continues on next page)



(continued from previous page)

vnf_min_instance_number:type: integerdefault: 1

vnf_max_instance_number:type: integerdefault: 1000

node_templates:

pgw_lbs_ve_config:type: f5.gilan.nodes.Configurationproperties:port: 443ssl: trueverify: false

interfaces:cloudify.interfaces.lifecycle:

configure:inputs:template_file: templates/check-all-services.yamlparams:

username: { get_secret: bigip_username }password: { get_secret: bigip_admin_password }host: { get_attribute: [ SELF, target_host_ip ] }

relationships:- type: cloudify.relationships.contained_in

target: pgw_lbs_vesource_interfaces:

cloudify.interfaces.relationship_lifecycle:preconfigure:implementation: gilan.gilan_plugin.relationship_lifecycle.copy_runtime_

→˓propertiesinputs:properties:- value: {get_attribute: [TARGET, ip]}name: target_host_ip

- type: cloudify.relationships.depends_ontarget: pgw_lbs_ve_revoke_license

• Nodes—-all components in your network are listed in the nodes section (YAML list) in the blueprint YAMLfile, which defines the application topology of those components and the relationship between them.

• Workflows—-the different automation processes for the application are defined in the workflow section of theblueprint YAML file. Workflows are orchestration algorithms written in an executable language (for example,Python) using dedicated, APIs. VNFM workflows are delivered by way of plugins.

• Plugins-—communicate with external services, such as: cloud services like OpenStack, container-managementsystems like Kubernetes, configuration management tools like Ansible, and other communication protocols likeHTTP and SSH.

What’s Next?

Deploy VNFM orchestration

1.3. VNF Manager deployment Prerequisites 11


1.4 Part II: Deploy F5 VNF Manager

To deploy F5 VNFM, do the following:

1. Launch an instance in OpenStack

2. Add a floating IP in OpenStack

3. Access F5 VNFM UI

4. Manage secrets

5. Define parameters in the inputs.yaml file

1.4.1 Step 1: Launch an instance in OpenStack

PREREQUISITE: The following table lists the VNFM-required administrative OpenStack environment componentsand guidelines that must exist PRIOR to creating a VNFM instance in your OpenStack project. See previous stepReview and Prepare UDF Blueprint for details.

1. Once the following components exist in your environment, , and then define the following parameters, clickingNext to complete the wizard. (Click the following links to learn more about using the latest version of OpenStack,or refer to the documentation specific to the version of OpenStack you are using.)

Project -> Compute -> Instances -> Launch Instance

Component DescriptionExpand Select Boot Source, and choose Image, underCreate New Volume, click No, and then click + next tothe latest VNFM image file to move it to the Allocatedlist.

Select m1.medium flavorSelect + next to the following predefined network (andsubnet), to add to the Allocated list:

• Management network (mgmt) – The VNF Man-ager and BIG-IP VE management interfaces withone DNS server in the subnet configuration.

Ensure that default security group is selectedEnsure that existing jumphost.pem key pair is selectedfor accessing VNFM instance remotely from jumphost,using SSH.

2. For all other Instance component definitions, use the default values provided by OpenStack. For details, see .

1.4.2 Step 2: Add a floating IP

Once you launch your instance in OpenStack, expand the Create Snapshot drop-down ( or press Associate Floating IPif instance is still spawning) next to your instance in the table, and select from the list. Choose an IP address from the



list. If none, click + to add one. This allocates the floating extnet IP on the management network. Do this to accessthe VNFM externally from a browser, using https.

1.4.3 Step 3: Access F5 VNFM UI

To acces your VNFM, point your browser to the public floating 10.1.20.x IP address you created and assigned in theprevious steps, using https.

1.4.4 Step 4: Manage secrets

In F5 VNFM UI, click System Resources -> Secret Store Management, click next to each of the following secrets toedit the values for your project. Doing so enables your blueprint to access these values as needed, during orchestration,without exposing the plain text values.

1. Change the following credentials:

BIG-IP Notesbigip_admin_password Set to the desired password for the default BIG-IP admin account. See Credentialsbigip_root_password Set to the desired password for the default BIG-IP root account. See Credentialsbigip_username Set bigip admin user to the desired value. See Credentials

For more information, see using the secret store.

2. A special jumphost script vnfm-secrets.sh should be used to update Secret Store

Open jumphost MATE terminal and run the following command:

1.4. Part II: Deploy F5 VNF Manager 13


$sudo ~/Downloads/vnfm-secrets.sh <vnfmanager .40 net IP>

For list of credentials updated by script, see

1.4.5 Step 5: Define parameters in the inputs.yaml file

The F5 blueprint uses an inputs.yaml file that you edit, adding your system definitions:

1. Open inputs_gilan_udf-v3.yaml on the Desktop and change the <changeMe> parameter values according toyour network implementation. See the following tables for parameter descriptions that you will define in theinputs.YAML file.

Note: The 2 parameters that need to be changed are: cm_ip, floating_network_id

cm_ip: Horizon UI: Project -> Compute -> Instances -> vnfmanager 10.1.40.x IP address of the VNF Managerinstance

floating_network_id: Horizon UI: Project -> Networks -> Network -> extnet

2. Save the .yaml file. You will upload this file into VNFM in the next step, deploy F5 Gilan blueprint.

Gi LAN blueprint

For up-to-date gilan inputs YAML content see



What’s Next?

Deploy Gilan blueprint

1.5 Part III. Deploy local F5 Gilan blueprint and create traffic serverVM

1. Deploy Gilan blueprint

2. Stand up traffic server VM

3. Run test traffic

1.5.1 Step 1. Deploy Gilan blueprint

Once you change all the values in the Gi LAN inputs file and save it locally, upload the file in F5 VNF Manager. Itwill define all required parameters for the F5 Gilan yaml blueprint.

1. Open F5 VNFM, click Local Blueprints. The F5-VNF-Service-Layer-GiLAN_1.0.0.1 main blueprint file ap-pears.

2. Click Deploy.

3. Enter a name, under Deployment Inputs, click browse for the inputs_gilan_udf-v3.yaml file you edited, andthen click Open. The Deploy blueprint form is completed automatically with the values you entered in thegilan_inputs.yaml file. Click Deploy

Warning: Deployment name should be a single word with no spaces, dashes or special characters

4. On the left-side menu click the Deployments blade, in the list next to blueprint you created in the preivous step,expand , click Gilan install, and then click Execute. VNFM starts creating BIG-IP VEs according to theparameters you defined for your network. Also installed includes additional, sub-blueprints packaged with theF5 gilan blueprint.

Note: You may see the following error appearing intermittently during the first few minutes of deployment. It doesn’taffect the deployment process

1.5. Part III. Deploy local F5 Gilan blueprint and create traffic server VM 15


5. To view the list of Gilan workflows (for example, scale out group, deregister VE, etc.) that you can run, on theDeployments blade, click next to your Gilan deployment in the list. A list of applicable workflows for yoursolution appears. Learn more about

6. To view the multiple BIP-IP VEs created by installing your F5 Gilan blueprint, open your OpenStack projectand navigate to Compute -> Instances.



Note: Deployment will take 40-45 minutes to complete. Monitor the process by viewing Deployments screen untilall nodes are green

Resulting Gilan deployment architecture includes 2 DAG and 2 ( master + 1 slave) VNF instances:

For more information about Install Workflow see: Install Workflow

1.5.2 Step 2. Stand up traffic server VM

Server VM can be launched from CLI or using Horizon UI.

1. To launch traffic server VM from CLI SSH to controller_neutron VM



Run the following script:

#./create_trafficserver.sh

Note: Script will perform the following actions automatically to simplify lab process: 1. Add route to traffic_servervia DAG1 on router1 2. Add route to client via DAG2 in userdata.sh for traffic_server 3. Stand up traffic server withcorresponding neutron port/ip and userdata.sh as user data

2. Verify traffic_server VM is in Running state and has correct IP assigned

Project -> Compute -> Instances

3. Review target traffic flows

Note: This lab uses pdn_dag_net to return traffic from server to DAG2 instance. This is due tovarious environment limitations



Three-way TCP handshake flow:

Apache Bench HTTP request flow:



Note: For load testing VNF BIG-IP uses a special “CPU killer” iRule which generates a 200 OKanswer locally without forwarding traffic to the server for client IP ending with .21 - .24 (.20 IP ispassed to traffic server)

Apache Bench Load test flow:

1.5.3 Step 3. Run test traffic to validate connectivity

1. SSH to UDF traffic_gen VM and run Apache Bench and curl commands

sudo ab -n 10 -c 1 -b 1400 -B 10.1.20.20 http://10.1.52.101/sudo ab -n 10 -c 1 -b 1400 -B 10.1.20.21 http://10.1.52.101/sudo ab -n 10 -c 1 -b 1400 -B 10.1.20.22 http://10.1.52.101/curl --interface eth1 http://10.1.52.101/





curl --interface eth1:0 http://10.1.52.101/curl --interface eth1:1 http://10.1.52.101/

2. AB Output should contain statisticcal information on average RTT and # of bytes sent/received, among otherdata. Ensure Apache Bench received data back from the server.

Benchmarking 10.1.52.101 (be patient).....done

Server Software: Apache/2.4.6Server Hostname: 10.1.52.101Server Port: 80

Document Path: /Document Length: 4897 bytes

Concurrency Level: 1Time taken for tests: 0.067 secondsComplete requests: 10Failed requests: 0Non-2xx responses: 10Total transferred: 51680 bytesHTML transferred: 48970 bytesRequests per second: 150.03 [#/sec] (mean)Time per request: 6.665 [ms] (mean)Time per request: 6.665 [ms] (mean, across all concurrent requests)Transfer rate: 757.16 [Kbytes/sec] received

Connection Times (ms)min mean[+/-sd] median max

Connect: 1 2 1.2 1 5Processing: 4 5 0.4 5 6Waiting: 1 2 0.3 2 2Total: 6 7 1.4 6 10

Percentage of the requests served within a certain time (ms)50% 666% 675% 680% 790% 1095% 1098% 1099% 10100% 10 (longest request)

3. Curl output should depend on the source IP used - for a default client IP (eth1 - 10.1.20.20) curl will return aXML payload in HTTP answer. For other client IPs ( eth1:0-eth1:3 10.1.20.21 - .24) curl will return “Hello!”generated by VNF BIG-IP

curl --interface eth1:0 http://10.1.52.101/Thursday November,08 2018 - 14:40:38 (UTC)Hello!

What’s Next?

Trigger Auto-scaleout



1.6 Part IV. Trigger auto scale-out

1. Run Apache Bench

2. Watch BIG-IP and Nagios statistics, VNF manager actions

1.6.1 Step 1. Run Apache Bench from traffic_gen VM

1. SSH to traffic_gen VM and run run_traffic.sh script passing Server IP as an argument:

./run_traffic.sh 10.1.52.101

2. Log files are generated for each thread and are located in the same directory (ab[1-10].out)

1.6.2 Step 2. Watch BIG-IP and Nagios statistics, scaleout process in VNF manager

1. Point Jumphost Browser to a slave VNF(FW) BIG-IP instance .40 IP address and login to BIG-IP TMUI

(a) Navigate to Statistics –> Analytics –> CPU

(b) Watch CPU graph as it crosses pre-defined 40% CPU threshold

2. Open a new tab in the browser and point it to the public floating https://10.1.20.x/nagios IP address of Nagios VM. Login using Nagios credentials and navigate to ServicesSee Credentials

After 2-3 minutes Nagios will show a CRITICAL alarm when CPU utilization on VNF layer BIG-IPs reaches pre-defined threshold:

Clicking on the alarm brings up detailed state information



3. Point your browser to the public floating 10.1.20.x IP address of VNF Manager VM

(a) Login to VNF manager UI and click on Deployments from the left-side menuIcon

(b) Watch as VNF manager performs auto scale-out of VNF(FW) instances:

4. Stop the traffic using the following script:

./stop_traffic.sh

What’s Next?

Initiate Manual scaleout

1.7 Part V. Initiate manual scale-out

1. Execute scale-out workflow

2. Modify Openstack route to new DAG instance

3. Run test traffic

1.7.1 Step 1. Execute Scale-out workflow

VNF Manager can scale-out/in both DAG and Firewall layers. THis lab focuses on manual scale-out procedure forscaling out DAG layer.

To manually scale-out DAG layer, select Deployments –> dag_group_xxx Blueprint Expand , click Gilan scale outgroup. Keep add_instances value of 1, and then click Execute.

1.7. Part V. Initiate manual scale-out 23


1.7.2 Step 2. Modify openstack route

1. Note newly created DAG layer BIG-IP pgw_net

2. Select Project –> Network –> Routers and click on router1 Open Static Routes tab and click on Delete StaticRoute to delete previously provisioned route. Click on Add Static Route Add the following route:10.1.52.101/32 Next Hop <DAG layer BIG-IP pgw_net IP>

1.7.3 Step 3. Run test traffic

1. Run test traffic through new DAG instance

Run test traffic

Note: This test is the same as in Part III Step 3 of this lab guide

2. Point Jumphost Browser to new DAG BIG-IP instance .40 IP address and login to BIG-IP TMUI

3. Navigate to Local Traffic –> Virtual Servers, then select f5dag partition from Partition: menu



4. Select firewall_fastL4 VS and click on Statistics menu

Traffic statistics will be visible in Traffic Details and Connections parts of Statistics screen. Note thatdue to the asymmetric routing, return traffic is NOT passing through the same DAG instance

Note: Other methods may be used to validate that the traffic is flowing through new DAG instances including runninga tcpdump

For more information about Scale Workflow see: The Scale Workflow

What’s Next?

Change AFM Configuration via AS3

1.8 Part VI. Configuration change

1. Check existing FW config

2. Configuration change workflow

3. Check VNF BIG-IP config and run test traffic

VNF Manager allows users to perform BIG-IP configuration change by invoking nsd_xxx Workflow and passingcorresponding AS3 payload. This lab contains a modified AS3 payload that will provision AFM policy and rules forFirewall layer of Gilan blueprint.

1.8.1 Step 1. Check Existing VNF BIG-IP configuration

Check VNF BIG-IP FW rules and configuration. There should be no policy or rules configured

1. Check Master VNF BIG-IP Management IP in Openstack Horizon UI:

Project –> Compute –> Instances

2. Point the browser to .40 IP of Master VNF BIG-IP and login as admin

3. In f5vnf partition navigate to Security –> Network Firewall –> Active Rules –> Context: Virtual Server

1.8. Part VI. Configuration change 25


1.8.2 Step 2. Apply updated AS3 configuration

1. To change the AFM configuration, open as3_update.json on jumphost Desktop and copy it’s contents

2. Select Deployments –> nsd_vnf_xxxx Blueprint

3. Expand , click Gilan update as3 nsd, paste the entire AS3 json payload copied from the file, and then clickExecute.

For more information about Install Workflow see: Update FW layer configuration Workflow

AS3 payload for configuration of Firewall rules

{"class": "AS3","action": "deploy","persist": true,"declaration": {

"class": "ADC",





"schemaVersion": "3.0.0","id": "cfy_vnf_01","label": "vnf","remark": "VNF","f5vnf": {

"class": "Tenant","Shared": {

"class": "Application","template": "shared","fwAllowedAddressList": {

"addresses": ["10.0.0.0/8","172.20.0.0/16","192.168.0.0/16"

],"class": "Firewall_Address_List"

},"fwAllowedPortList": {

"class": "Firewall_Port_List","ports": [

"8080-8081",22,443,53,80

]},"fwDefaultDenyAddressList": {

"addresses": ["0.0.0.0/0"

],"class": "Firewall_Address_List"

},"fwLogDestinationHsl": {

"class": "Log_Destination","distribution": "adaptive","pool": {

"use": "poolHsl"},"protocol": "tcp","type": "remote-high-speed-log"

},"fwLogDestinationSyslog": {

"class": "Log_Destination","format": "rfc5424","remoteHighSpeedLog": {

"use": "fwLogDestinationHsl"},"type": "remote-syslog"

},"fwLogPublisher": {

"class": "Log_Publisher","destinations": [

{"use": "fwLogDestinationSyslog"

}]





},"fwPolicy": {

"class": "Firewall_Policy","rules": [

{"use": "fwRuleList"

}]

},"fwRuleList": {

"class": "Firewall_Rule_List","rules": [

{"action": "accept","destination": {

"portLists": [{

"use": "fwAllowedPortList"}

]},"loggingEnabled": true,"name": "tcpAllow","protocol": "tcp","source": {

"addressLists": [{

"use": "fwAllowedAddressList"}

]}

},{

"action": "accept","loggingEnabled": true,"name": "udpAllow","protocol": "udp","source": {

"addressLists": [{

"use": "fwAllowedAddressList"}

]}

},{

"action": "drop","loggingEnabled": true,"name": "defaultDeny","protocol": "any","source": {

"addressLists": [{

"use": "fwDefaultDenyAddressList"}

]}





}]

},"fwSecurityLogProfile": {

"class": "Security_Log_Profile","network": {

"logIpErrors": true,"logRuleMatchAccepts": true,"logRuleMatchDrops": true,"logRuleMatchRejects": true,"logTcpErrors": true,"logTcpEvents": true,"logTranslationFields": true,"publisher": {

"use": "fwLogPublisher"},"storageFormat": {

"fields": ["action","bigip-hostname","context-name","context-type","date-time","dest-ip","dest-port","drop-reason","protocol","src-ip","src-port"

]}

}},"poolHsl": {

"class": "Pool","members": [

{"enable": true,"serverAddresses": [

"255.255.255.254"],"servicePort": 514

}],"monitors": [

{"bigip": "/Common/udp"

}]

},"lbSelectedRule": {

"class": "iRule","iRule": "when LB_SELECTED {log local0. \"Selected server [LB::server]\

→˓"}","remark": "Log load balanced server"

},"cpu_killer": {





"remark": "Log load balanced server","iRule": "when HTTP_REQUEST {\r\nif {[IP::addr [IP::client_addr]

→˓equals 10.1.20.20]} {\r\n# Do nothing and forward traffic to server\r\nlog local0. \→˓"Source IP is 10.1.20.20 - Forwarding to destination...\" \r\nreturn\r\n} else→˓{\r\n # Kill CPU Cycles\r\n log local0. \"Running CPU killer and responding→˓locally...\"\r\n set count 10\r\n for {set i 0} { $i < $count } {incr i}→˓{\r\n set keys [CRYPTO::keygen -alg rsa -salthex 0f0f0f0f0f0f0f0f0f0f -len→˓1024]\r\n set pub_rsakey [lindex $keys 0]\r\n set priv_rsakey [lindex→˓$keys 1]\r\n set data [string repeat \"rsakeygen1\" 11]\r\n set enc_→˓data [CRYPTO::encrypt -alg rsa-pub -key $pub_rsakey $data]\r\n HTTP::header→˓insert rsa_encrypted \"$enc_data\"\r\n set dec_data [CRYPTO::decrypt -alg→˓rsa-priv -key $priv_rsakey $enc_data]\r\n }\r\n\t# Set some basic response→˓headers\r\n\tset server_name \"BIG-IP ($static::tcl_platform(machine))\"\r\n\tset→˓conn_keepalive \"Close\"\r\n\tset content_type \"text/plain; charset=us-ascii\"\r\n→˓ # initialize response page\r\n set page \"[clock format [clock seconds] -→˓format {%A %B,%d %Y - %H:%M:%S (%Z)}]\\r\\n\"\r\n\tappend page \"Hello!\\r\\n\"\r\n→˓ # return response page\r\n HTTP::respond 200 content ${page} noserver Server $→˓{server_name} Connection ${conn_keepalive} Content-Type $content_type\r\n}\r\n}\r\n→˓",

"class": "iRule"},"profileL4": {

"class": "L4_Profile"},"serviceAddress": {

"class": "Service_Address","arpEnabled": false,"spanningEnabled": true,"virtualAddress": "0.0.0.0"

}},"f5_http": {

"class": "Application","template": "http","serviceMain": {

"allowVlans": [{

"bigip": "/Common/pgw_dag_net"}

],"translateServerAddress": false,"layer4": "tcp","profileHTTP": {

"bigip": "/Common/http"},"virtualPort": 0,"iRules": [

"/f5vnf/Shared/lbSelectedRule","/f5vnf/Shared/cpu_killer"

],"translateServerPort": false,"profileL4": {

"use": "/f5vnf/Shared/profileL4"},"virtualAddresses": [

{"use": "/f5vnf/Shared/serviceAddress"





}],"snat": "none","lastHop": "disable","policyFirewallEnforced": {

"use": "/f5vnf/Shared/fwPolicy"},"securityLogProfiles": [

{"use": "/f5vnf/Shared/fwSecurityLogProfile"

}],"class": "Service_HTTP"

}},"f5_inbound": {

"class": "Application","template": "generic","serviceMain": {

"allowVlans": [{

"bigip": "/Common/pdn_dag_net"}

],"class": "Service_Generic","iRules": [

"/f5vnf/Shared/lbSelectedRule"],"layer4": "any","profileL4": {

"use": "/f5vnf/Shared/profileL4"},"snat": "none","translateServerAddress": false,"translateServerPort": false,"virtualAddresses": [

{"use": "/f5vnf/Shared/serviceAddress"

}],"virtualPort": 0

}}

}}

}

1.8.3 Step 3. Validate configuration change

1. Check VNF BIG-IP configuration In f5vnf partition navigate to Security –> Network Firewall –> Active Rules –>Context: Virtual Server



2. Run test traffic through Gilan to ensure Firewall configuration doesn’t block the flow.

Run test traffic

Note: This test is the same as in Part III Step 3 of this lab guide

What’s Next?

(Optional) Run Uninstall workflow

1.9 Part VII. (Optional) Uninstall workflow

This step will force VNF Manager to remove all BIG-IP and Nagios VMs and corresponding configuration.

Note: It is recommended to skip this step if current UDF deployment will be used later for customer PoCs and/ordemos

To uninstall the entire deployment, select Deployments –> F5-VNF-Service-Layer-GiLAN_1.0.0.1 Blueprint Expand, click Gilan uninstall and then click Execute.

For more information about Uninstall Workflow see: Uninstall Workflow

This concludes ISC 2018 VNF manager lab



1.10 VNF manager Workflows

VNF manager Workflow-deployment matrix:

1.10.1 The Install Workflow

Workflow name: ‘‘install‘‘

Workflow description: Workflow for installing applications.

Workflow high-level pseudo-code:

For each node, for each node instance (in parallel):

1. Wait for node instance relationships to be started. (Only start processing this node instance when the nodeinstances it depends on are started).

2. Execute cloudify.interfaces.lifecycle.create operation.1

3. Execute cloudify.interfaces.relationship_lifecycle.preconfigure relationship opera-tions.2

4. Execute cloudify.interfaces.lifecycle.configure operation.1

5. Execute cloudify.interfaces.relationship_lifecycle.postconfigure relationship oper-ations.2

6. Execute cloudify.interfaces.lifecycle.start operation.1

7. If the node instance is a host node (its type is a subtype of cloudify.nodes.Compute):

• Install agent workers and required plugins on this host.

• Execute cloudify.interfaces.monitoring_agent interface install and start opera-tions.1

8. Execute cloudify.interfaces.monitoring.start operation.1

9. Execute cloudify.interfaces.relationship_lifecycle.establish relationship opera-tions.2

1.10.2 The Scale Workflow

Workflow name: ‘‘scale‘‘

Workflow description:

Scales out/in the node subgraph of the system topology applying the install/uninstall workflows’ logic re-spectively.

If the entity denoted by scalable_entity_name is a node template that is contained in a compute node (or is acompute node itself) and scale_compute is true, the node graph will consist of all nodes that are contained inthe compute node which contains scalable_entity_name and the compute node itself. Otherwise, the subgraphwill consist of all nodes that are contained in the node/scaling group denoted by scalable_entity_name.

In addition, nodes that are connected to nodes that are part of the contained subgraph will have their establishrelationship operations executed during scale out and their unlink relationship operations executed during scale in.

1 Execute the task mapped to the node’s lifecycle operation. (do nothing if no task is defined).2 Execute all tasks mapped to this node’s relationship lifecycle operation. (Operations are executed in the order defined by the node template

relationships)

1.10. VNF manager Workflows 33


Workflow parameters:

• ‘‘scalable_entity_name‘‘: The name of the node/scaling group to apply the scaling logic to.

• ‘‘delta‘‘: The scale factor. (Default: 1)

– For delta > 0: If the current number of instances is N, scale out to N + delta.

– For delta < 0: If the current number of instances is N, scale in to N - |delta|.

– For delta == 0, leave things as they are.

• scale_compute: should scale apply on the compute node containing the node denoted byscalable_entity_name (default value is false).

– If scalable_entity_name specifies a node, and scale_compute is set to false, the subgraphwill consist of all the nodes that are contained in the that node and the node itself.

– If scalable_entity_name specifies a node, and scale_compute is set to true, the subgraphwill consist of all nodes that are contained in the compute node that contains the node denoted byscalable_entity_name and the compute node itself.

– If the node denoted by scalable_entity_name is not contained in a compute node or it specifies agroup name, this parameter is ignored.


1. Retrieve the scaled node/scaling group, based on scalable_entity_name and scale_compute param-eters.

2. Start deployment modification, adding or removing node instances and relationship instances.

3. If delta > 0:

• Execute install lifecycle operations (create, configure, start) on added node instances.

• Execute the establish relationship lifecycle operation for all affected relationships.

4. If delta < 0:

• Execute the unlink relationship lifecycle operation for all affected relationships.

• Execute uninstall lifecycle operations (stop, delete) on removed node instances.

NOTE: Detailed description of the terms graph and sub-graph that are used in this section, can be found in the Healworkflow section.

1.10.3 The Heal Workflow

Workflow name: ‘‘heal‘‘

Workflow description: Reinstalls the whole subgraph of the system topology by applying the uninstall andinstall workflows’ logic respectively. The subgraph consists of all the node instances that are contained in thecompute node instance which contains the failing node instance and/or the compute node instance itself. Additionally,this workflow handles unlinking and establishing all affected relationships in an appropriate order.


• ‘‘node_instance_id‘‘: The ID of the failing node instance that needs healing. The whole compute node instancecontaining (or being) this node instance will be reinstalled.


1. Retrieve the compute node instance of the failed node instance.

2. Construct a compute sub-graph (see note below).



3. Uninstall the sub-graph:

• Execute uninstall lifecycle operations (stop, delete) on the compute node instance and all it’s containednode instances1.

• Execute uninstall relationship lifecycle operations (unlink) for all affected relationships.

4. Install the sub-graph:

• Execute install lifecycle operations (create, configure, start) on the compute node instance andall it’s contained nodes instances.

• Execute install relationship lifecycle operations (preconfigure, postconfigure, establish)for all affected relationships.

A compute sub-graph can be thought of as a blueprint that defines only nodes that are contained inside a computenode. For example, if the full blueprint looks something like this: {{< highlight yaml >}} . . .

node_templates:

webserver_host: type: cloudify.nodes.Compute relationships: - target:floating_ip type: cloudify.relationships.connected_to

webserver: type: cloudify.nodes.WebServer relationships: - target:webserver_host type: cloudify.relationships.contained_in

war: type: cloudify.nodes.ApplicationModule relationships: - target:webserver type: cloudify.relationships.contained_in - target: databasetype: cloudify.relationships.connected_to

database_host: type: cloudify.nodes.Compute

database: type: cloudify.nodes.Database relationships: - target:database_host type: cloudify.relationships.contained_in

floating_ip: type: cloudify.nodes.VirtualIP...

Then the corresponding graph will look like so:

And a compute sub-graph for the ‘‘webserver_host‘‘ will look like:

NOTE: This sub-graph determines the operations that execute during the workflow execution. In this example:

• The following node instances will be re-installed: war_1, webserver_1 and webserver_host_1.

• The following relationships will be re-established: war_1 connected to database_1 andwebserver_host_1 connected to floating_ip_1.

1.10.4 Update FW layer configuration Workflow

Workflow name: ‘‘AS3 Update‘‘

Workflow description: Reinstalls the whole subgraph of the system topology by applying the uninstall andinstall workflows’ logic respectively. The subgraph consists of all the node instances that are contained in thecompute node instance which contains the failing node instance and/or the compute node instance itself. Additionally,this workflow handles unlinking and establishing all affected relationships in an appropriate order.

Workflow parameters:1 Effectively, all node instances that are contained inside the compute node instance of the failing node instance, are considered failed as well

and will be re-installed.



Fig. 1: Blueprint as Graph




• ‘‘node_instance_id‘‘: The ID of the failing node instance that needs healing. The whole compute node instancecontaining (or being) this node instance will be reinstalled.


1. Retrieve the compute node instance of the failed node instance.

2. Construct a compute sub-graph (see note below).

3. Uninstall the sub-graph:

• Execute uninstall lifecycle operations (stop, delete) on the compute node instance and all it’s containednode instances1.

• Execute uninstall relationship lifecycle operations (unlink) for all affected relationships.

4. Install the sub-graph:

• Execute install lifecycle operations (create, configure, start) on the compute node instance andall it’s contained nodes instances.

• Execute install relationship lifecycle operations (preconfigure, postconfigure, establish)for all affected relationships.

A compute sub-graph can be thought of as a blueprint that defines only nodes that are contained inside a computenode. For example, if the full blueprint looks something like this: {{< highlight yaml >}} . . .

node_templates:

webserver_host: type: cloudify.nodes.Compute relationships: - target:floating_ip type: cloudify.relationships.connected_to

webserver: type: cloudify.nodes.WebServer relationships: - target:webserver_host type: cloudify.relationships.contained_in

war: type: cloudify.nodes.ApplicationModule relationships: - target:webserver type: cloudify.relationships.contained_in - target: databasetype: cloudify.relationships.connected_to

database_host: type: cloudify.nodes.Compute

database: type: cloudify.nodes.Database relationships: - target:database_host type: cloudify.relationships.contained_in

floating_ip: type: cloudify.nodes.VirtualIP...

Then the corresponding graph will look like so:

And a compute sub-graph for the ‘‘webserver_host‘‘ will look like:

NOTE: This sub-graph determines the operations that execute during the workflow execution. In this example:

• The following node instances will be re-installed: war_1, webserver_1 and webserver_host_1.

• The following relationships will be re-established: war_1 connected to database_1 andwebserver_host_1 connected to floating_ip_1.

1 Effectively, all node instances that are contained inside the compute node instance of the failing node instance, are considered failed as welland will be re-installed.



1.10.5 The Uninstall Workflow

Workflow name: ‘‘uninstall‘‘

Workflow description: Workflow for uninstalling applications.


• ignore_failure: If true, then operation errors encountered during uninstallation will not prevent theworkflow from moving on; errors will be logged and printed. If false, errors encountered during uninstallationwill prompt the orchestrator to behave similarly to install (that is: retrying recoverable errors, aboring onnon-recoverable errors).


For each node, for each node instance (in parallel):

1. Wait for dependent node instances to be deleted. (Only start processing this node instance when the nodeinstances dependent on it are deleted).

2. Execute cloudify.interfaces.monitoring.stop operation.1

3. If node instance is host node (its type is a subtype of cloudify.nodes.Compute):

• Execute cloudify.interfaces.monitoring_agent interface stop and uninstall opera-tions.1

• Stop and uninstall agent workers.

4. Execute cloudify.interfaces.lifecycle.stop operation.1

5. Execute cloudify.interfaces.relationship_lifecycle.unlink relationship operations.2

6. Execute cloudify.interfaces.lifecycle.delete operation.1

1.11 Use the Secret Store

The secrets store provides a secured variable storage (key-value pairs) for data that you do not want to expose in plaintext in F5 VNFM blueprints, such as login credentials for a platform. The values of the secrets are encrypted in thedatabase. We use the Fernet encryption of cryptography library, which is a symmetric encryption method that makessure that the message encrypted cannot be manipulated/read without the key. When you create a secret, the key valuecan be a text string or it can be a file that contains the key value. The secret store lets you make sure all secrets(for example credentials to IaaS environments) are stored separately from blueprints, and that the secrets adhere toisolation requirements between different tenants. You can include the secret key in your blueprints and not include theactual values in the blueprints. For more information, see the get_secret intrinsic function.

1.11.1 Secrets with a hidden value

All the values of the secrets are encrypted in the database. When you create a secret you can specify if you want itsvalue to be hidden or not. A secret with a hidden value means the value is only shown to the user who created it, tenantmanagers and sys-admins. Users can use the secret according to the user roles and the visibility of the secret.

1 Execute the task mapped to the node’s lifecycle operation (does nothing, if no task is defined).2 Execute all tasks mapped to this node’s relationship lifecycle operation (operations execute in the order defined by the node template relation-

ships).

1.11. Use the Secret Store 39


Updating a secret

1.11.2 Updating a secret with a shown value

• Updating the secret’s value and visibility or deleting the secret is allowed according to the user roles and thevisibility of the secret.

• Updating the secret to hide the value is only allowed to the user who created it, tenant managers and sys-admins.

1.11.3 Updating a secret with a hidden value

Only the creator of the secret, a sys-admin or a tenant manager of the tenant the secret is stored on can see, updateor delete the secret with a hidden value (unlike a secret with a shown value which other users in the tenant can alsoupdate or delete).

Creating a secret from the CLI

You can use the cfy secrets command to manage VNFM secrets (key-value pairs).

$ cfy secrets create test -s test_value ...

Secret ``test`` created

...

For more commands, see Secrets commands.

Creating a secret from the F5 VNFM Console

Secret Store Management is performed from the System Resources page in the VNFM Console.

1. Click Create in the Secret Store Management widget.

2. Insert the following values:

• The secret key

• The secret value (or select the secret file from your file repository)

• The visibility level (the icon of the green man)

• If the value of the secret should be hidden

3. Click Create.

4. Press on the eye icon for viewing the secret value.

5. To change the visibility level of the secret, click on the visibility icon in the key cell.

6. To hide the secret value, select the Hidden checkbox.

7. For updating the secret value there is an edit icon in the right and next to it the delete icon.



1.11. Use the Secret Store 41


get_secret

get_secret is used for referencing secrets described in the Secrets API. get_secret can be used in nodeproperties, outputs, node/relationship operation inputs, and runtime-properties of node instances. The function isevaluated at runtime.

Example

node_templates: host: type: cloudify.nodes.Compute properties: ip: {get_secret: ip } cloudify_agent: key: { get_secret: agent_key } user: {get_secret: user } interfaces: test_interface: test_operation:implementation: central_deployment_agent inputs: operation_input: {get_secret: operation_input }

outputs:

webserver_url: description: Web server url value: { concat: [‘http://’,{ get_secret: ip }, ‘:’, { get_secret: webserver_port }] }

In this example, get_secret is used for completing several of the host node’s properties, as well as an operation input.In addition, it is used twice in the concatenated webserver_url output.

1.12 Sample Gi LAN Inputs File

You will copy and paste the following code sample into a new YAML file you will use for the Gi LAN Solution. Thenyou will change the values according to your implementation, and save it locally. Once completed, you will intoVNFM to auto-complete the F5 blueprint. Learn more about these .

# VNF Resource Information Collector inputs for Reportingric_purchasing_model: subscription # perpetual or→˓subscriptionric_throughput: '5' # 5, 10, or 50 Gbps→˓total throughput for a layerric_vnfm_serial: '12345' # Serial Number from→˓purchasing email

# VNF specific inputsauto_last_hop: "disabled" # disables last_hop on→˓VNF and creates inbound VS on DAG when No CGNAT, or when CGNAT is not F5 BIG-IPdefault_gateway: 10.1.52.1 # The default gateway→˓the VNF should use to reach the Internet

#### Scaling Thresholds and Values ##############################################→˓############################### Maximum number of 'instances' that can be created during scale outmax_scale_dag_group: '1000' # Max Dag Group Membersmax_scale_vnf_group: '1000' # Max VNF Group Members

# Max number of times that a heal can be tried before giving up.max_heal_vnfd_dag_ve: '5'max_heal_vnf_layer: '5'max_heal_vnf_slave_ve: '5'

# VNF Layer scaling inputsvnf_layer_cpu_threshold: '15' # percent of→˓aggregated CPU for when to scale the next slave member





vnf_layer_cpu_threshold_check_interval: '1' # number of seconds→˓between checks .5 is possible

# VNF Group scaling inputsvnf_group_throughput: '10' # 5, 10 or 50 total→˓agregated Gbps for entire layervnf_group_throughput_threshold: '50' # percent of→˓aggregated CPU for when to scale the next layervnf_group_throughput_check_interval: '1' # number of seconds→˓between checks .5 is possible

# DAG Group scaling inputsdag_group_cpu_threshold: '50' # percent of aggregated→˓CPU for when to scale the next dag memberdag_group_cpu_threshold_check_interval: '1' # number of seconds→˓between checks .5 is possible

######################################################################################→˓##############################

# Nagios inputsfloating_network_id: <changeMe> # OpenStack ID of the→˓floating IP network (extnet)centos_image_id: dd291320-035b-479f-9e98-e05c6d7c44d2 # OpenStack ID of the→˓CentOS image to use for the monitoring nodesnagios_flavor_id: 5371c5f1-2496-4862-a0ea-b740b7000162 # OpenStack ID of the→˓flavor to use for the monitoring nodes

# Common inputsbigip_os_ssh_key: jumphost # OpenStack SSH Key Namecm_ip: <changeMe> # The management IP→˓address (.40 subnet) of the VNF Manager

# Software references for the BIG-IP VEsw_ref_dag:

data:image: BIG-IP-13.1.0.7 # OpenStack Image Nameflavor: m1.large # OpenStack Flavor Name

revision: 0sw_ref_vnf:

data:image: BIG-IP-13.1.0.7 # OpenStack Image Nameflavor: m1.large # OpenStack Flavor Name

revision: 0

# BIG-IQ License Managerbig_iq_host: 10.1.20.14 # Management IP address→˓of the BIG-IQ License Managerbig_iq_lic_pool: regkeys # Pool Name containing the→˓BIG-IP VE Licenses created on the BIG-IQ from the Reg Key provided in the Email→˓from F5

# BGP Router Configbgp_dag_pgw_peer_ip: 10.1.55.201 # IP address of the→˓PGateway router use for BGP Neighbor commandbgp_vnf_pgw_peer_ip: 10.1.55.201 # IP address of the→˓PGateway router that the VNF will use to route traffic back to the UE devices


1.12. Sample Gi LAN Inputs File 43



bgp_pgw_peer_as: '200' # Autonomous System (AS)→˓number of the PGateway BGP routerbgp_dag_egw_peer_ip: 10.1.52.201 # IP address of the→˓External Gateway router that the DAG will advertise to to send traffic back to the→˓UE devicesbgp_egw_peer_as: '300' # Autonomous System (AS)→˓number of the External Gateway BGP router

# Security Groups In OpenStackctrl_sg_name: control_sgmgmt_sg_name: mgmt_sgpgw_sg_name: pgw_sgpdn_sg_name: pdn_sgsnmp_sg_name: snmp_sg

# Networks and Subnets in OpenStackmgmt_net: mgmtmgmt_subnet: mgmt_subnetpgw_net: pgw_netpgw_subnet: pgw_net_subnetpdn_net: pdn_netpdn_subnet: pdn_net_subnetpgw_dag_net: pgw_dag_netpgw_dag_subnet: pgw_dag_subnetpdn_dag_net: pdn_dag_netpdn_dag_subnet: pdn_dag_subnetctrl_net: controlctrl_subnet: control_subnetha_net: ha_netha_subnet: ha_subnetpgw_dag_subnet_cidr: 10.1.55.0/24pgw_dag_subnet_mask: '/24'pdn_dag_subnet_cidr: 10.1.52.0/24

###################################################################################### Configuration of the F5 VNF Service Layers in AS3 Declaration format ## Example: Your Firewall Configuration. ## Example: Your Subscriber based Policy enforcement Configuration. ## The format of this YAML is critical, please use a YAML linter, and double check ## the spelling of keys and values. If any of the declaration is incorrect, an HTTP ## 422 error will be seen the deployment logs. ######################################################################################vnf_as3_nsd_payload:

class: AS3action: deploypersist: Truedeclaration:class: ADCschemaVersion: 3.0.0id: cfy_vnf_01label: vnfremark: VNFf5vnf:

class: TenantShared:

class: Application(continues on next page)




template: sharedlbSelectedRule:class: iRuleiRule: when LB_SELECTED {log local0. "Selected server [LB::server]"}remark: Log load balanced server

cpu_killer:remark: Log load balanced serveriRule: "when HTTP_REQUEST {\r\nif {[IP::addr [IP::client_addr] equals 10.1.

→˓20.20]} {\r\n# Do nothing and forward traffic to server\r\nlog local0. \"Source IP→˓is 10.1.20.20 - Forwarding to destination...\" \r\nreturn\r\n} else {\r\n # Kill→˓CPU Cycles\r\n log local0. \"Running CPU killer and responding locally...\"\r\n→˓ set count 10\r\n for {set i 0} { $i < $count } {incr i} {\r\n set keys→˓[CRYPTO::keygen -alg rsa -salthex 0f0f0f0f0f0f0f0f0f0f -len 1024]\r\n set→˓pub_rsakey [lindex $keys 0]\r\n set priv_rsakey [lindex $keys 1]\r\n→˓set data [string repeat \"rsakeygen1\" 11]\r\n set enc_data [CRYPTO::encrypt→˓-alg rsa-pub -key $pub_rsakey $data]\r\n HTTP::header insert rsa_encrypted \"→˓$enc_data\"\r\n set dec_data [CRYPTO::decrypt -alg rsa-priv -key $priv_→˓rsakey $enc_data]\r\n }\r\n\t# Set some basic response headers\r\n\tset server_→˓name \"BIG-IP ($static::tcl_platform(machine))\"\r\n\tset conn_keepalive \"Close\→˓"\r\n\tset content_type \"text\/plain; charset=us-ascii\"\r\n # initialize→˓response page\r\n set page \"[clock format [clock seconds] -format {%A %B,%d %Y -→˓ %H:%M:%S (%Z)}]\\r\\n\"\r\n\tappend page \"Hello!\\r\\n\"\r\n # return response→˓page\r\n HTTP::respond 200 content ${page} noserver Server ${server_name}→˓Connection ${conn_keepalive} Content-Type $content_type\r\n}\r\n}\r\n"

class: iRuleprofileL4:class: L4_Profile

serviceAddress:class: Service_AddressarpEnabled: FalsespanningEnabled: TruevirtualAddress: 0.0.0.0

f5_http:class: Applicationtemplate: httpserviceMain:allowVlans:- bigip: /Common/pgw_dag_nettranslateServerAddress: falselayer4: tcpprofileHTTP:

bigip: /Common/httpvirtualPort: 0iRules:- /f5vnf/Shared/lbSelectedRule- /f5vnf/Shared/cpu_killertranslateServerPort: falseprofileL4:

use: /f5vnf/Shared/profileL4virtualAddresses:- use: /f5vnf/Shared/serviceAddresssnat: nonelastHop: disableclass: Service_HTTP

f5_inbound:class: Applicationtemplate: generic


1.12. Sample Gi LAN Inputs File 45



serviceMain:allowVlans:- bigip: /Common/pdn_dag_netclass: Service_GenericiRules:- /f5vnf/Shared/lbSelectedRulelayer4: anyprofileL4:use: /f5vnf/Shared/profileL4

snat: nonetranslateServerAddress: FalsetranslateServerPort: FalsevirtualAddresses:- use: /f5vnf/Shared/serviceAddressvirtualPort: 0


packaged nfv solutions

Documents