Release notes

These release notes provide product information about the F5 VNF Manager support for version 2.0.1. This release contains mostly fixes for known issues, and only a few new/changed functionalities.

User documentation

You can find the user documentation on: https://clouddocs.f5.com/cloud/nfv/latest/.

Platform support requirements

This section provides system requirements for VNFM and additional platform components.

VNF Manager

F5 VNF Manager version 2.0.0 - 2.0.1 requires the following system requirements:

Platform name Platform ID System Requirements
F5 VNF Manager All versions
  • vCPUs: 4 minimum, 8 recommended
  • RAM: 8GB minimum, 16GB recommended
  • Root Disk Storage: 160GB minimum
  • Storage: 5GB minimum, 64GB recommended
  • 64-bit host: with RHEL/CentOS 7.9
  • Private network: dedicated for communicating with other VNFM components, including cluster members

VNFM Sizing guidelines

The following table includes some guidelines and insights for determining VNF Manager sizing.

VNFM Component Sizing guideline
Tenants Define a maximum of 1000 tenants in a VNF Manager
Users Currently, no limit to the number of users you can define in the system; however, the maximum, concurrent users interacting with VNFM is 200.
Blueprints Allocate 50GB of storage to the VNF Manager. Currently, no limit to the number of blueprints, as the average blueprint storage requires less than 1M of disk space and database space.
Plugins Plugins are stored in the VNF Manager hard drive. Typically, plugins can consume approximately 5M to 20M of storage.
Deployments A single VNFM can maintain up to 500K of deployed nodes. Typical deployment size consumes 10K maximum of disk size and very few entries in the database
Workflows A VNFM can operate up to 100 concurrent workflows; a default limit enforced by the system. However, you can modify this threshold.
Secrets No limit to the number of secrets.
Agents A maximum of 2000 agents deployed per a single VNFM.
UI/CLI/API requests/second Although the REST API performance varies depending on multiple factors, typically VNF Manager can support a maximum of 10 requests/second.
Events The system can process a maximum of 100 events/second.
Logs, events, and metrics Define enough storage to store the logs, events, and metrics sent from the hosts, configuring log rotation to minimize the amount of storage space required.

Additional platforms

The following table provides system requirements for the additional components.

Platform name Platform ID System Requirements
BIG-IP Virtual Edition (VE) Version 13.1.X
Version 14.1.X
F5 AS3 Declaration 3.26.1 LTS F5 AS3 Declaration version 3.26.1 (LTS) documentation
BIG-IQ Version 6.0.1.0.0.813 BIG-IQ 6.0.1.0.0.813 Release Notes
CentOS-7-x86_64-GenericCloud-1503 GenericCloud-1503 Release Notes

Virtual Infrastructure Manager (VIM) compatibility

F5 VNF Manager and VIM compatibility matrix:

VNF Manager ID VIM Platform ID VIM System Requirements
F5 VNF Manager 1.1.X OpenStack Newton Version 10 Environment requirements
F5 VNF Manager 1.2.0 VMware vSphere ESXi Version 6.5 Requirements and patch notices
F5 VNF Manager 1.2.1 VMware vSphere ESXi Version 6.5
OpenStack Newton Version 10
See previous links for requirements information.
F5 VNF Manager 1.3.0 OpenStack Newton Version 10 and Queens Version 13
VMware vSphere ESXi Version 6.5
Newton Version 10 Environment requirements
Queens Version 13 Environment requirements
vSphere ESXi Version 6.5 Requirements and patch notices
F5 VNF Manager 1.3.1 OpenStack Newton Version 10 and Queens Version 13
VMware vSphere ESXi Version 6.5
See previous links for compatible platform requirements.
F5 VNF Manager 1.4.0 OpenStack Newton Version 10 and Queens Version 13
VMware vSphere ESXi Version 6.5
See the previous links for compatible other platform requirements.
F5 VNF Manager 2.0.0 - 2.0.1 OpenStack Newton Version 10 and Queens Version 13
VMware vSphere ESXi Version 6.5 and VIO version 5.1
See VMware Integrated OpenStack (VIO), and the previous links for other compatible platform requirements.

Note

To verify supported versions of OpenStack compatibility for all versions of VNFM, F5 used Red Hat and VIO infrastructures; however, F5 is confident that VNFM is compatible with supported versions of OpenStack in other infrastructures.

Open source components

F5 VNF Manager is built with the following open-source components.

Component Description
Nginx

Nginx is a high-performing Web server. In F5 VNF Manager, it serves two purposes:

  • A proxy for the F5 VNFM REST service and F5 VNFM Console
  • A file server to host F5 VNFM-specific resources, agent packages, and blueprint resources.

File server

The file server served by Nginx, while tied to Nginx by default, is not logically bound to it. Although currently it is accessed directly frequently (via disk rather than via network), we will be working towards having it decoupled from the management environment so that it can be deployed anywhere. The file server served by Nginx, is available at https://{manager_ip}:53333/resources, which is mapped to the /opt/manager/resources/ directory. You must authenticate in order to access the file server. To access subdirectories that include tenant names in their path, you must have privileges on that tenant. These subdirectories include:

  • blueprints
  • uploaded-blueprints
  • deployments
  • tenant-resources

The directories that are stored in snapshots include:

  • blueprints
  • uploaded-blueprints
  • deployments
  • tenant-resources
  • plugins
  • global-resources

Note: The tenant-resources and global-resources directories are not used by F5 VNF Manager; therefore, users can create these directories for storing custom resources.

Gunicorn and Flask Gunicorn is a Web server gateway interface HTTP server. Flask is a Web framework. Together, Gunicorn and Flask provide the F5 VNFM REST service. The REST service is written using Flask, and Gunicorn is the server. Nginx, is the proxy to that server. The F5 VNFM’s REST service is the integrator of all parts of the F5 VNFM environment.
PostgreSQL

PostgreSQL is an object-relational database that can handle workloads ranging from small single-machine applications to large Internet-facing applications. In F5 VNF Manager, PostgreSQL serves two purposes:

  • Provides the main database that stores the application’s model (for example, blueprints, deployments, runtime properties)
  • Provides indexing, and logs’ and events’ storage

Recommended system requirements include:

  • vCPUs: 2
  • RAM: 16GB
  • Storage: 64GB

These recommended specifications consider the average use of 1000-2000 workflows per hour and certified for 1 million deployments. To increase this scaling volume, increase your hardware specification; for example, the equivalent AWS instance is r5.large.

Logstash Logstash is a data handler. It can push/pull messages using inputs, and apply filters and output to different outputs. Logstash is used by F5 VNFM to pull log and event messages from RabbitMQ and index them in PostGresSQL.
RabbitMQ

RabbitMQ is a queue-based messaging platform. RabbitMQ is used by F5 VNFM as a message queue for different purposes:

  • Queueing deployment tasks
  • Queueing logs and events
  • Queueing metrics

Recommended system requirements include:

  • vCPUs: 2
  • RAM: 4GB
  • Storage: 32GB

These recommended specifications consider the average use of 1000-2000 workflows per hour and certified for 1 million deployments. To increase this scaling volume, increase your hardware specification; for example, the equivalent AWS instance is c5.large.

Pika

Pika is a pure-Python implementation of the AMQP 0-9-1 protocol. The VNF management worker and the host agents are using pika to communicate with RabbitMQ.

Management worker (or agent)

Both the Workflow Executor and the Task Broker that appear in the diagram are part of the F5 VNFM Management Worker.

  • The Workflow Executor receives workflow execution requests, creates the tasks specified by the workflow, submits the tasks for execution by host agents and the Task Broker, and manages workflow state.
  • The Task Broker executes API calls to IaaS providers to create deployment resources, and executes other tasks specified in central_deployment_agent plugins.

Note: All agents (the management worker, and agents deployed on application hosts) are using the same implementation.

Features

Feature Name Description
Install/Uninstall Installs the target deployment, lifecycle operations, and starts all instances. Uninstalls target deployment, frees resources allocated during install, performs uninstall lifecycle operations, stops/deletes deployments and additional blueprints created during install.
Scale out Adds and installs BIG-IP Virtual Editions (VEs) and VNF instances on demand as your network needs resources based on configurable parameters.
Scale in Removes and uninstalls BIG-IP Virtual Editions on demand as your network reduces its need for resources based on configurable parameters.
Heal VEs and layers Creates a new copy of any BIG-IP VEs, layers, and related objects on demand as your network reports dysfunctional instances.
Purge VEs and layers Uninstalls and removes dysfunctional VEs, VNF layer instance(s), and related objects, which you start manually after heal layer workflow runs and problem investigation is complete.
Upgrade Initiates the upgrade process and sets new software reference data. Disables VEs with lower revision numbers. Scaled and healed VEs are installed using the new software reference data.
Update NSD Updates AS3 declaration pushed to the VE as a part of NSD definition.
High Availability (HA) Due to changes in a third-party application, the three-cluster VNFM HA solution in VNFM 2.0.0 - 2.0.1 no longer works as designed. Refer to the Cloudify 5.0.5 HA Guide for configuration information.
REST API Provides all VNFM functionality using a REST-based API.

What’s new

The following table describes new/changed functionality added in VNF Manager version 2.0.1.

Feature Description
Bug fixes This release contains several fixes for existing issues.
Python OpenStackClient (OSC) Added python-openstackclient 3.14.4, which is a command-line client tool for OpenStack Queens. You can execute the OpenStack command set from VNF Manager for Compute, Identity, Image, Network, Object Store, and Block Storage APIs.
PREVIEW: Added tmsh/bash commands PREVIEW FEATURE: Supplemented all VNFM blueprint solutions with the new additional_commands input for executing TMSH/BASH commands for configuration purposes. The default setting for this input is an empty list (of commands).
VNFM image file versioning Starting with VNF Manager v2.0.1, the image file name will use a three-digit version number instead of a four-digit version number.

Security Vulnerabilities

The following list provides known common vulnerabilities and exposures (CVEs) shipped with the VNF Manager 2.0.1 release. Visit the F5 Security Center for complete F5 BIG-IP and F5 BIG-IQ security information. For the latest list of known and fixed vulnerabilities related to versions of BIG-IP VE and BIG-IQ, visit the F5 Documentation Center and select the Security Advisory document type to narrow the search results.

Important

The following libraries listed in the Known CVEs are NOT accessible directly from F5 VNF Manager. You must run the Gi-LAN plugin and launch a blueprint, to access these libraries. Therefore, a bad actor must write a blueprint and launch that blueprint in the VNF Manager in order to exploit these libraries. F5 recommends that you always deploy the VNF Manager on a secure management network, which is NOT accessible externally.

Known CVEs

lodash-4.17.10.js

Vulnerability Code Severity Description
CVE-2021-23337 High Lodash versions prior to 4.17.21 are vulnerable to Command Injection using the template function.
CVE-2020-28500 Medium Lodash versions prior to 4.17.21 are vulnerable to Regular Expression Denial of Service (ReDoS) via the toNumber, trim, and trimEnd functions.
CVE-2019-10744 Critical Versions of lodash lower than 4.17.12 are vulnerable to Prototype Pollution. The function defaultsDeep could be tricked into adding or modifying properties of Object.prototype using a constructor payload.
CVE-2019-1010266 Medium lodash prior to 4.17.11 is affected by: CWE-400: Uncontrolled Resource Consumption. The impact is: Denial of service. The component is: Date handler. The attack vector is: Attacker provides very long strings, which the library attempts to match using a regular expression. The fixed version is: 4.17.11.
CVE-2020-8203 High Prototype pollution attack when using _.zipObjectDeep in lodash before 4.17.20.
CVE-2018-16487 Medium A prototype pollution vulnerability was found in lodash <4.17.11 where the functions merge, mergeWith, and defaultsDeep can be tricked into adding or modifying properties of Object.prototype.

bottle-0.12.7.tar.gz

Vulnerability Code Severity Description
CVE-2020-28473 Medium The package bottle from 0 and before 0.12.19 are vulnerable to Web Cache Poisoning by using a vector called parameter cloaking. When the attacker can separate query parameters using a semicolon (;), they can cause a difference in the interpretation of the request between the proxy (running with default configuration) and the server. This can result in malicious requests being cached as completely safe ones, as the proxy would usually not see the semicolon as a separator, and therefore would not include it in a cache key of an unkeyed parameter.

ipaddress-1.0.23-py2.py3-none-any.whl

Vulnerability Code Severity Description
CVE-2020-14422 Medium Lib/ipaddress.py in Python through 3.8.3 improperly computes hash values in the IPv4Interface and IPv6Interface classes, which might allow a remote attacker to cause a denial of service if an application is affected by the performance of a dictionary containing IPv4Interface or IPv6Interface objects, and this attacker can cause many dictionary entries to be created. This is fixed in: v3.5.10, v3.5.10rc1; v3.6.12; v3.7.9; v3.8.4, v3.8.4rc1, v3.8.5, v3.8.6, v3.8.6rc1; v3.9.0, v3.9.0b4, v3.9.0b5, v3.9.0rc1, v3.9.0rc2.

pycrypto-2.6.1.tar.gz

Note

This vulnerability is in the product as a dependency, but is NOT used.

Vulnerability Code Severity Description
CVE-2013-7459 Critical Heap-based buffer overflow in the ALGnew function in block_templace.c in Python Cryptography Toolkit (aka pycrypto) allows remote attackers to execute arbitrary code as demonstrated by a crafted iv parameter to cryptmsg.py.
CVE-2018-6594 High The lib/Crypto/PublicKey/ElGamal.py library in PyCrypto through 2.6.1 generates weak ElGamal key parameters, which allows attackers to obtain sensitive information by reading ciphertext data (for example, it does not have semantic security in face of a ciphertext-only attack). The Decisional Diffie-Hellman (DDH) assumption does not hold for PyCrypto’s ElGamal implementation.

Known issues

The following table lists known issues in the designated version release:

Platform name Description
F5 VNF Manager Version 2.0.1
  • If deploying the F5-VNF-BIG-IQ blueprint from a VMware vSphere ESXi VIM, you must NOT use 192.168.1.200 and 192.168.1.245 IP addresses on the same network the F5 VNF Manager is connected, until AFTER you deploy the BIG-IQ blueprint and the BIG-IQ HA pair is online. Once the BIG-IQ HA pair is online, those IP addresses become available.

  • In VMware vSphere ESXi, when using the VNFM REST API, you must set up your networks to use unique port group names, regardless of the directories in which they reside.

  • OpenStack v10 (Newton) has an issue with privileges and connecting devices residing outside the OpenStack environment with those residing inside the OpenStack environment, including F5 VNF Managers. To work around this issue, you must add the VNF Manager to the admin project, or upgrade to OpenStack v13 (Queens).

  • When instantiating the VNFM image in your VIM, the image at boot-up requires proper networking. If not, then your user accounts are not created correctly, and login to the OS VM is not possible. Additionally, services do not start and there is no access to the VNF Manager UI. This prohibits logging into VNFM and adding the required networking. Workaround depends upon your VIM:

  • The failover_state is not updated for deployment outputs on VNF layer.

  • No validator for the security_groups input setting.

  • A few inaccurate descriptions in the UI of some data types for various blueprint inputs.

  • The current UI description of the Scale workflows and inputs for VNF group is inaccurate. The description should read, add_layers, NOT add_instances.

  • The starting_ip_number input definition corresponds to the natSourceTranslation addresses value for VNF VE on the CGNAT layer. The starting_ip_number parameter has a functional limit of 3000 addresses; however, you can define a larger value. This functional limit will increase in a future release.

  • Running the Heal and Purge workflows for VNF layers causes the slave node to fail in VMware Vsphere environment. These workflows execute as expected in OpenStack.

  • Currently, you cannot change the system password using the CLI. This will be fixed in a later version VNFM 2.1.0.

  • For Gi-LAN blueprint solution deployments, an error occurs, resulting in the second slave failing on check_all_services node.

  • Currently, NOT all VNFM components are in sync with the internal VNFM NTP server.

  • Cloud-Libs may result in errors like MCP unavailable and ECONNRESET.

  • By default, all BIG-IP VEs have preassigned openstacklocal hostnames, regardless of environment, which can cause confusion.

  • If the Heal workflow is in progress, you may experience DISRUPTED traffic flow/transition.

  • When assigning security groups that do NOT currently exist in OpenStack/VIO for a deployment, the deployment fails to create that security group correctly, resulting in a failed deployment. To workaround this issue, create the security group BEFORE deploying a blueprint.

  • When assigning networks that do NOT currently exist in OpenStack/VIO for a deployment, the deployment fails to create that network correctly, resulting in a failed deployment. To workaround this issue, create the security group BEFORE deploying a blueprint.

  • Currently in VNFM v2.0.1 and earlier, there is a default page size limit of 1000. For larger deployments, you can work around this limit by changing the following default_page_size config parameter:

    $ vnfm config update '{ "default_page_size": 20000}'
    $ cfy_manager stop
    $ cfy_manager start
    

    If your deployment is stuck, after changing the config parameter, perform restore DB snapshot.

  • When deploying the CGNAT-Offering blueprint, two Control NICs are created unintentionally.

  • After running the Uninstall workflow on a deployment, the ves and layers tables are NOT deleted from f5_db database.

  • When executing the Configuration update workflow on vSphere GiLAN (non-CGNAT) deployments, you will receive an error on the additional NSD layers.

BIG-IP 13.1.0.5 or 14.1.2.8 Virtual Edition 13.1.X Issues list or 14.1.2.8 Issues list
BIG-IQ 6.0.1.0.0.813 Issues list
CentOS-7-GenericCloud-1503 Issues list
OpenStack Newton Issues list for v10 and Issues list for v13
VMware vSphere ESXi 6.5 and VIO v5.1 Issues list and documents for VMware Integrated OpenStack (VIO)

Fixed issues

The following table lists issues that were fixed in the designated version release:

Platform name Fixed in version Description
F5 VNF Manager 2.0.1
  • Scale in workflow works as expected on DNS SEC Layer.
  • Changed the 1-year certificate expiration to a 10-year expiration. VNFM manager works as expected, and no longer becomes unresponsive after 365 days.
  • After running the Purge workflow a member node is now removed from the DAG, as designed.
  • DAG vnf_pool is now updated after running the Scale in workflow on the vnf_group deployment.
  • The CGNAT Offering blueprint works as expected.
  • The enable_cgnat_on_single_nsd_deployment workflow operates as expected.
  • GiLAN blueprint solution no longer fails while installing one slave.
  • Zooming the map view in the new Site Management widget now works as expected.
  • Input parameter vnic_binding_type description updated with more clarity.
  • The Heal workflow for a VNF layer runs successfully without failing due to a dictionary size change.
  • BIG-IQ Blueprint installs successfully, and no longer tries to retrieve inputs from an external database.
  • Updated PyYAML to 5.4.1 and resolved a security vulnerability.
  • Updated cloudlibs to v4.23.1 and fixed a security vulnerability with the lodash.js file.
  • Resolved the incorrect CGNAT IP addresses on healed instances.
  • Base blueprint installs successfully as design without a AS3 rpm install failure.
  • When deploying the vSphere-F5-VNF-Service-Layer-Firewall blueprint, you no longer get a, “Task failed ‘gilan_plugin.tasks.ha_rest_wrapper’ -> 404 Client Error: Not Found for url” error message.
  • When installing deployment from vSphere-F5-VNF-Service-Layer-Firewall blueprint, you no longer get a “Nagios internal server error 500” message.
  • When installing the DNS SEC in blueprint, the deployment runs successfully as designed, without runtime errors while trying to run proxy task upload_blueprint command.
  • In OpenStack the DNS SEC blueprint installs successfully, and no longer fails due to CGNAT code.
  • In vSphere the GiLAN blueprint installs successfully without a conflicting SNMP URL.
  • DNS and DNS SEC blueprint installations no longer fail in vSphere due to a runtime error.
  • Blueprint installations no longer randomly times out due to a restjavad problems.
  • For the DNS and DNS SEC blueprints, the Scale Out workflow runs successfully, as designed.
  • You no longer get an “UnboundLocalError” message, when running the Heal workflow, on the Firewall blueprint with CGNAT inputs defined.
  • Open port in Nagios server (port 111) is rpcbind, and is now fire-walled off.
  • You can now restore a snapshot (with the exception of VNFM 2.0.0), and you will no longer encounter the following error: “Restoring snapshot from version 0.0.0 is not supported.” Be aware, you may need to make repeated attempts at a snapshot before success.
  • The Upgrade workflow no longer automatically admin-disables the old layer. Perform this step manually, as designed.
  • The Heal workflow no longer returns an error on the vnf_layer for Gi LAN blueprint deployments.
  • The telemetry AS3 declaration now propagates as expected, after executing sync-to-device group.
  • You will no longer receive a 404 error message when trying to deploy any blueprint on vSphere VIM with a setting of switch_distributed=False.
  • Device configuration groups now sync with the master node after executing a Scale out workflow for a vnf_layer deployment.
  • New deployments created during a Scale out workflow or a Heal workflow are now created with updated inputs.
  • When you select one type of declaration (AS3, Telemetry Streaming, or Syslog), VNFM no longer triggers all three declaration types, during an update, and the declaration no longer breaks the configuration services on the VNFs.
  • VNFM now provides enough space to install all .rpm package types available on F5 Downloads site.
  • When launching the Gi LAN blueprint solution, the increment_ips_proxy workflow is now blocked when CGNAT is NOT enabled. This is the intended behavior.
  • Nagios installs successfully and no longer fails or freezes when reloading systemd configuration.
  • If you have not defined the vlan_ip_map key, you can now scale out resources without failure.
  • The Configuration Update workflow runs successfully as designed without an error in the NSD node-telemetry_declaration.
  • The Cloud-libs is no longer stuck on /tm/sys/available, and will no longer cause BIG-IP deployment failures on the node.
  • The Update declaration workflow now synchronizes across all VEs in the VNF layer; therefore, you no longer need to manually push the changes using a curl command.
  • For GiLAN or Gi Firewall + CGNAT deployments install successfully as designed, and you can now make changes to the CGNAT configuration, post deployment.
  • The blueprint wizard launched from the VNFM dashboard are branded with VNF Manager, as expected.
  • The CLI for license and site management is now VNFM-branded, as expected.
  • Corrected the assigned permissions level required for reading VNFM certificates.
  • BIG-IP VEs uninstall correctly in vSphere, and the execution and logs no longer stop at: main payload handler.
  • BIG-IQ blueprint in vSphere now checks for activation status of license offerings.
  • During the Uninstall workflow in a Multi-VIM environment, the registration node no longer encounters a RecoverableError and no longer fails to unregister one or more VE instances.
  • VNFD Purge workflow executes as expected, and no longer fails with a NoneType object has no attribute config error message.
  • VNFD Install workflow executes as expected and will no longer fail in OpenStack during the check_all_services with a No key error message.
  • Fixed the Upgrade workflow so DNS deployments no longer fail.
  • The ntpdate is no longer stuck during cloud-init execution.
  • Added a REST call for the MAC interface list to return a null value in order to get an accurate NIC ordering.
  • Removed Syslog code.
  • When uninstalling deployments, the Nagios VM is removed appropriately allowing for the workflow and logs to execute as intended.
  • AS3 declaration is now updated on healed instances by executing the Update declaration workflow as intended.
  • DNS SEC traffic flows as expected in an OpenStack environment.
  • When uninstalling one slave, the BIG-IP VE no longer hangs.
  • Running the Increment ip proxy workflow on a Gi-LAN + CGNAT deployment works as designed without a runtime error.
  • The Enable CGNAT workflow run on Gi-LAN blueprint now works as designed.
  • The Modify cgnat workflow no longer appears in the Execute Workflow menu. You cannot run this workflow manually.
BIG-IP Virtual Edition 13.1.0.5 or 14.1.2.8 13.1.X Issues list or 14.1.2.8 Issues list
BIG-IQ 6.0.1.0.0.813 Issues list
CentOS-7-x86_64 GenericCloud-1503 Issues list
OpenStack 10.0 and 13.0 Issues list for v10 and Issues list for v13
VMware vSphere ESXi and VIO 6.5 and 5.1 Issues list and documents for VMware Integrated OpenStack (VIO)

Installation overview

To install F5 VNF Manager, point your browser to the F5 Downloads site and download locally, either a qcow2 (OpenStack/VIO) or an OVA (vSphere) file.

Additionally, you will need the following F5 product license keys:

Platform name Product license
BIG-IQ 6.0.1.0.0.813 F5-BIQ-VE-LIC-MGR-LIC
BIG-IP 13.1.0.5 or 14.1.2.8 Virtual Edition F5-BIG-MSP-LOADV12-LIC
CentOS-7-x86_64-GenericCloud-1503 NA

Upgrade overview

You can upgrade HA clusters two ways:

  • Upgrade on new hosts (recommended method).

  • In-place upgrade (prevents ability to rollback).

    Important

    This method works only if you leave the IP, AMQP credentials and certificates unchanged.

For the complete F5 NFV Solutions and VNF Manager software upgrade policy, consult this K35549824 article. For BIG-IP VE upgrade procedures, visit BIG-IP VE upgrade guide.

What’s Next?

Set up VNFM