Release Notes

F5 Cloud-Native Network Functions (CNFs) for - 1.3.0

New Features and Improvements

  • The Cloud-Native Network Functions (CNFs) Helm charts, Docker images, and utilities are now available via the F5 Artifact Registry. Users can pull Helm charts, Docker images, and utilities directly from the F5 Artifact Registry. For more information, refer to CNFs Artifacts Via F5 Artifact Registry section.

  • The tmm.add_k8s_routes parameter enables the Traffic Management Microkernel’s (TMM) default gateway to be configured using either BGP or the F5BigNetStaticroute Custom Resource (CR) without impacting Kubernetes control plane traffic. When enabled (true), a Helm hook will obtain and add the Kubernetes Pod and Service IPv4/IPv6 networks to the TMM routing table. For more information, refer to the TMM section of BIG-IP Controller.

  • Added a new setting called selfipAsDest in the F5BigContextSecure CR to use selfip as the destination address from vlans.vlanList and attach iRules RULE_INIT for Upstream Routing Readiness, indicating when the TMM is ready to receive traffic from the upstream router.

  • The new TMM_IGNORE_IPV4_GATEWAYS and TMM_IGNORE_IPV6_GATEWAYS parameters have been added to allow TMM to exclude IPv4 and IPv6 gateway configurations. For more information, refer to the tmm.customEnvVars section of BIG-IP Controller Reference.

  • As part of the effort to support standardized logging across all F5 products, starting from CNF 1.3.0 release, the log messages generated by Go Containers will follow a standardized log format that is consistent with the f5-log library.

    The standardized log format supports the following data fields:

    • Severity
    • Type
    • Message
    • Arguments
    • Cause (if annotation exists)
    • Workaround (if annotation exists)

    To see the list of log messages generated by a few Go Containers added in this release, refer the Log Messages List section of Log Formats guide.

  • Added the following new containers for this release:

    • f5ing-tmm-pod-manager
    • f5-core-file-manager
    • spk-csrc

    For more information on version details and description of the newly added containers, see CNFs Software guide.

Bug Fixes

1319157 (DoS)

BA/BD statistics not functioning issue for the IP Unknown Protocol and IPv6 extended headers is now resolved.


Added BA/BD support for IP Unknown Protocol and IPv6 extended headers.

1382125 (toda_logging)

An invalid yaml file issue impacting the installation process is now resolved. The yaml files become invalid as the tolerations are not defined in f5-toda-fluentd/templates/fluentd_deploy.yaml files.


Added support to configure tolerations field in f5-toda-fluentd/templates/fluentd_deploy.yaml files.

1402425 (Downloader)

Excessive disc space consumption issue is now resolved.


After sending a package to the endpoint, the packages that were unpacked before are being purged.

1505473 (TMM)

Responses for TMM originated ICMPv6 requests are being dropped.


This issue is resolved by creating the forwarding flow for TMM-originated ICMPV6 Packets on the correct TMM.

1566621 (Ingress)

Helm upgrade failure issue while using an older version of helm such as v3.2.4 is now resolved.


The helm chart templates were modified to use the existing information from the resource/object when the resource/object exists already during the upgrade.

1505477 (toda_metrics)

gRPC connection between tmstatsd and OpenTelemetry Collector is broken during reconnection due to incorrect handling of client certificate rotation.


The tmstatsd correctly reloads the client certificate, generated by certificate manager, during reconnection. Metrics are now exported from OpenTelemetry Collector without any issues.

1329849-1 (Drivers)

TMM container crashes on startup and does not process traffic due to a bug in the dpdk mlx5 driver.


Added support to fix this issue and the TMM container no longer crashes on startup.

1505481 (Ingress)

The existing VLAN CR configuration is not applied to new TMM pods. If the TMM was deployed with one replica and then incrementally scaled up to N pods, then the (N-1)th and/or Nth TMM pods will not get VLAN configuration.


Added support to ensure that all the TMM replicas in the replica set reliably receive VLAN CR configuration regardless of whether they were deployed in one go or incrementally scaled up.

Known Issues

1567725 (TMM)

Untagged VLANs are not currently supported. While using untagged VLANs, there is an intermittent problem with only one TMM processing the traffic.


Do not use untagged VLANs as they are not currently supported.

1574561-1 (TMM)

TMM init config map gets overwritten during rolling upgrade.


Save TMM init config, update F5 Ingress Helm chart, transfer custom config from saved TMM init to the user_conf.tcl section of the new TMM init config.

1578581 (Ingress)

A configured V4 snat pool cannot be updated with V6 snat pool members. If a V4 snatpool is configured and it has to be changed to V6 pool members by editing the CR, the kernel routes for V6 snat pool are not created.


To update a configured V4 snat pool to V6 snat pool, delete the existing CR with V4 pool and re-apply the CR with V6 pool members.

1578569 (Ingress)

New pool members are not being added after scaling up the application pods in the watch namespace. This issue occurs as the F5ingress controller fails to send the updated pool members associated with secure context virtual server to the TMM, after scaling the application pods in the watch namespace.


Before deploying the secure context CR, deploy the application with the required number of replicas, instead of scaling it up later. This workaround is recommended as TMM will not forward the traffic to new pool members (scaled up application pods).

1570593 (Downloader)

A multi-attach error occurs if the f5-downloader pod changes nodes during upgrade. This issue is seen when the f5-downloader pod was deployed using the storage access mode with the default type as ReadWriteOnce, and is deployed on a cluster with multiple worker nodes.


Perform the following steps to avoid the multi-attach error that is preventing the upgraded pod from deploying.

  1. Change the access to ReadWriteMany, and the storage class to one that supports ReadWriteMany in the new values file.

    enabled: true
                    enabled: true
                    access: ReadWriteMany
                    storageClassName: robin-rwx

    For more information on how to set the access values, see Downloader values section in the BIG-IP Controller guide.

  2. Verify if the User has added any data to {downloader_pod}:/var/downloader-localfile-upload file.

    Case 1: If data is added, perform the following steps:

    1. Copy data from {downloader_pod}:/var/downloader-localfile-upload to a local directory.

      "kubectl cp {pod_name}:/var/downloader-localfile-upload {local/temp/path}"

      Note: This may not be a lossless process.

    2. Scale the downloader pod to 0 replicas.

      "kubectl scale deploy/f5-downloader -n {namespace} --replicas=0"
    3. Delete downloader-storage pvc.

      "kubectl delete pvc downloader-storage -n {namespace}
    4. Upgrade to CNF 1.3.0 with the values that have the ReadWriteMany selected.

      "helm upgrade {deployment-name} {tarball file} -n {namespace} -f {values file}"
    5. Restore the backed up data to {upgraded_downloader_pod}:/var/downloader-localfile-upload folder.

      Run the following command to restore the data:

      "kubectl cp {local/temp/path} {pod_name}:/var/downloader-localfile-upload"

    Case 2: If data is not added, perform step 2, 3 and 4 mentioned in Case 1.

Software upgrades

For assistance with software upgrades, refer to the Upgrading CNFs overview.

_images/spk_info.png Note: The upgrade of CNF from previous release is not supported.

Next step

Continue to the Cluster Requirements guide to ensure the cluster has the required software components.