Setup guide

Upon purchasing a VFNM solution, you will receive an email with a VNFM install package download URL, as well as an associated product license key, which you use only for obtaining support.


Download the following supported F5 products.

Supported Platforms Description
BIG-IQ 6.0.1 and F5-BIQ-VE-LIC-MGR-LIC license key This activates the BIG-IQ License Manager utility that manages licensing for BIG-IPs (utility pools) during orchestration.
BIG-IP Virtual-Edition and F5-BIG-MSP-LOADV12-LIC license key Use the Utility License, automatic method (if connected to the Internet) or the manual method (if not connected).
CentOS-7-x86_64-GenericCloud-1503 Image used by VNFM blueprints to create the Nagios virtual machine that monitors BIG-IP VE’s.

Private cloud environment setup

Currently, F5 supports BIG-IP Virtual-Edition and BIG-IQ 6.0.1 on OpenStack Newton, version 10, using the following setup:


Due to a known issue with OpenStack Newton (version 10), you must add the F5 VNF Manager to your admin project.

OpenStack Newton Component Description

Define flavors sized to accommodate the VNFM component images you previously uploaded. The minimum flavor requirements for deploying the F5 VNF Manager include:

  • vCPU: 4
  • RAM: 8GB
  • Root disk: 160GB

Define the following networks and one subnet for each, with sufficient IP address space in each network:

  • Management network (mgmt) – Configure the VNF Manager and BIG-IP VE management interfaces on this network, specifying at least one DNS server in the subnet configuration.
  • Provider gateway network (pgw_net) – Network used for the internal-facing DAG data plane interfaces.
  • Provider data network (pdn_net) – Network used for 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 data plane interfaces.
  • Control network (control_net) – Network fused or communication with control and value-added services.
  • HA network (ha_net) – Network used for internal HA communication between clustered VNF BIG-IP VE instances.
Security Groups

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 environment.
  • Management security group (mgmt_sg) – Allow TCP port 443.
  • Provider data network security group (pdn_sg) – Configure as needed for your environment.
  • Provider gateway security group (pgw_sg) – Configure as needed for your environment.
Key Pair Defined key pairs for accessing VNFM instance remotely, using SSH.

F5 recommendations

F5 recommends the following guidelines when implementing VNFM for your organization:

  • Deploy the VNFM solution in a test environment first, to determine the scaling parameters and workflows required for your network traffic.
  • If implementing High Availability, deploy three VNF Managers (see the High availability guide).

VNFM orchestration framework

F5 uses an open source orchestration framework to create the VNFM. You can use the console manager to deploy the orchestration elements, or the VNFM CLI in the F5 VNF Manager ONLY.

F5 blueprint

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

 - gilan_vnfd.yaml

   type: integer
   default: 1
 type: integer
 default: 1000

 type: integer
 default: 1
 type: integer
 default: 1000

 type: integer
 default: 1
 type: integer
 default: 1000


 type: f5.gilan.nodes.Configuration
   port: 443
   ssl: true
   verify: false
         template_file: templates/check-all-services.yaml
           username: { get_secret: bigip_username }
           password: { get_secret: bigip_admin_password }
           host: { get_attribute: [ SELF, target_host_ip ] }
   - type: relationships.contained_in
     target: pgw_lbs_ve
           implementation: gilan.gilan_plugin.relationship_lifecycle.copy_runtime_properties
               - value: {get_attribute: [TARGET, ip]}
                 name: target_host_ip
   - type: relationships.depends_on
     target: pgw_lbs_ve_revoke_license
  • Nodes—-all components in your network are listed in the nodes section (YAML list) in the blueprint YAML file, 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 the blueprint 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-management systems like Kubernetes, configuration management tools like Ansible, and other communication protocols like HTTP and SSH.

What’s Next?

Deploy VNFM orchestration