Cloud-Native Network Functions on AON 2.3.3 release notes¶
About this release¶
Introduction¶
These release notes describe the differences between CNFs on AON 2.3.2 and 2.3.3.
Note
This is a hardened release - please see Overview of F5 Hardened Releases for more information and treat every release as though it closes a critical gap.
Security updates¶
(No F5 security updates)
List of other CVEs¶
| CVE Number | Bug IDs | Image Names | Package Name |
|---|---|---|---|
| CVE-2024-24786 | 2362081 | f5dr-img | google.golang.org/protobuf |
| CVE-2026-10536 | 2363081, 2426393 | f5-fluentbit, vault-init | curl, libcurl4t64 |
| CVE-2026-11352 | 2426337 | vault-init | curl |
| CVE-2026-11564 | 2426397 | vault-init | curl |
| CVE-2026-11586 | 2426341 | vault-init | curl |
| CVE-2026-11850 | 2426757 | postgresql | krb5 |
| CVE-2026-11856 | 2426401 | vault-init | curl |
| CVE-2026-12064 | 2426345 | vault-init | curl |
| CVE-2026-25680 | 2362377, 2425873 | f5-downloader, ocnos-img | golang.org/x/net |
| CVE-2026-25681 | 2362381, 2425821 | f5-downloader, ocnos-img | golang.org/x/net |
| CVE-2026-27136 | 2362385, 2425825 | f5-downloader, ocnos-img | golang.org/x/net |
| CVE-2026-33630 | 2426349 | vault-init | c-ares |
| CVE-2026-39822 | 2425781, 2425789, 2425813, 2425833, 2425921, 2425937, 2425957, 2425973, 2425989, 2426005, 2426021, 2426037, 2426053, 2426069, 2426085, 2426105, 2426173, 2426189, 2426209, 2426237, 2426253, 2426269, 2426289, 2426301, 2426317, 2426329, 2426477, 2426493, 2426533, 2426549, 2426565, 2426581, 2426601, 2426605, 2426609, 2426613, 2426617, 2426621, 2426689, 2426697, 2426717, 2426737, 2426761, 2426797, 2426813, 2426821, 2426929, 2430541 | baseos, cert-manager-cainjector, cert-manager-controller, cert-manager-startupapicheck, cert-manager-webhook, crd-conversion, crd-installer, crdupdater, f5-analyzer, f5-bdosd, f5-blobd, f5-bnk-cis, f5-cert-client, f5-debug-sidecar, f5-downloader, f5-dssm-store, f5-dwbld, f5-env-discovery, f5-eowyn-install, f5-fluentbit, f5-fluentd, f5-fqdn-resolver, f5-ipam-controller, f5-l4p-engine, f5-license-helper, f5-license-proxy, f5-lifecycle-operator, f5-node-labeler, f5-nsec-ips-daemon, f5-toda-observer, f5-toda-tmstatsd, f5-urlcat, f5dr-img, f5ing-tmm-pod-manager, f5ingress, init-certmgr, ocnos-img, opentelemetry-collector-contri, rabbit, spk-csrc, spk-cwc, tmrouted-img | stdlib |
| CVE-2026-39824 | 2362401, 2425905, 2426161 | f5-downloader, f5-fluentd, ocnos-img | golang.org/x/sys |
| CVE-2026-39827 | 2425877 | f5-downloader | golang.org/x/crypto |
| CVE-2026-39828 | 2425837 | f5-downloader | golang.org/x/crypto |
| CVE-2026-39829 | 2425841 | f5-downloader | golang.org/x/crypto |
| CVE-2026-39830 | 2425845 | f5-downloader | golang.org/x/crypto |
| CVE-2026-39831 | 2425849, 2426437 | f5-downloader, f5-lifecycle-operator-catalog | golang.org/x/crypto |
| CVE-2026-39832 | 2425853 | f5-downloader | golang.org/x/crypto |
| CVE-2026-39833 | 2425881, 2426449 | f5-downloader, f5-lifecycle-operator-catalog | golang.org/x/crypto |
| CVE-2026-39834 | 2425885, 2426453 | f5-downloader, f5-lifecycle-operator-catalog | golang.org/x/crypto |
| CVE-2026-39835 | 2425857 | f5-downloader | golang.org/x/crypto |
| CVE-2026-41991 | 2426941 | baseos | gzip |
| CVE-2026-41992 | 2426945 | baseos | gzip |
| CVE-2026-42502 | 2362393, 2425889 | f5-downloader, ocnos-img | golang.org/x/net |
| CVE-2026-42505 | 2425785, 2425793, 2425817, 2425893, 2425925, 2425941, 2425961, 2425977, 2425993, 2426009, 2426025, 2426041, 2426057, 2426073, 2426089, 2426129, 2426177, 2426193, 2426213, 2426241, 2426257, 2426273, 2426293, 2426305, 2426321, 2426333, 2426481, 2426505, 2426537, 2426553, 2426569, 2426585, 2426625, 2426629, 2426633, 2426637, 2426641, 2426645, 2426693, 2426701, 2426721, 2426741, 2426765, 2426801, 2426817, 2426825, 2426933, 2430545 | baseos, cert-manager-cainjector, cert-manager-controller, cert-manager-startupapicheck, cert-manager-webhook, crd-conversion, crd-installer, crdupdater, f5-analyzer, f5-bdosd, f5-blobd, f5-bnk-cis, f5-cert-client, f5-debug-sidecar, f5-downloader, f5-dssm-store, f5-dwbld, f5-env-discovery, f5-eowyn-install, f5-fluentbit, f5-fluentd, f5-fqdn-resolver, f5-ipam-controller, f5-l4p-engine, f5-license-helper, f5-license-proxy, f5-lifecycle-operator, f5-node-labeler, f5-nsec-ips-daemon, f5-toda-observer, f5-toda-tmstatsd, f5-urlcat, f5dr-img, f5ing-tmm-pod-manager, f5ingress, init-certmgr, ocnos-img, opentelemetry-collector-contri, rabbit, spk-csrc, spk-cwc, tmrouted-img | stdlib |
| CVE-2026-42506 | 2362397, 2425897 | f5-downloader, ocnos-img | golang.org/x/net |
| CVE-2026-42508 | 2425861 | f5-downloader | golang.org/x/crypto |
| CVE-2026-45570 | 2426461 | f5-lifecycle-operator-catalog | github.com/go-git/go-git/v5 |
| CVE-2026-46595 | 2425865 | f5-downloader | golang.org/x/crypto |
| CVE-2026-46597 | 2425869 | f5-downloader | golang.org/x/crypto |
| CVE-2026-46598 | 2425901 | f5-downloader | golang.org/x/crypto |
| CVE-2026-46600 | 2426225 | f5-csm-qkview | golang.org/x/net |
| CVE-2026-47240 | 2334729 | f5-fluentd | net-imap |
| CVE-2026-47241 | 2334737 | f5-fluentd | net-imap |
| CVE-2026-47242 | 2334733 | f5-fluentd | net-imap |
| CVE-2026-48978 | 2426517 | f5-lifecycle-operator | oras.land/oras-go/v2 |
| CVE-2026-50151 | 2426497 | f5-lifecycle-operator | oras.land/oras-go/v2 |
| CVE-2026-50162 | 2426509 | f5-lifecycle-operator | oras.land/oras-go/v2 |
| CVE-2026-50163 | 2426445 | f5-lifecycle-operator-catalog | oras.land/oras-go/v2 |
| CVE-2026-54500 | 2426133 | f5-fluentd | oj |
| CVE-2026-54502 | 2426137 | f5-fluentd | oj |
| CVE-2026-54592 | 2426109 | f5-fluentd | oj |
| CVE-2026-54696 | 2426157 | f5-fluentd | json |
| CVE-2026-54896 | 2426113 | f5-fluentd | oj |
| CVE-2026-54897 | 2426117 | f5-fluentd | oj |
| CVE-2026-54898 | 2426141 | f5-fluentd | oj |
| CVE-2026-54899 | 2426145 | f5-fluentd | oj |
| CVE-2026-54900 | 2426121 | f5-fluentd | oj |
| CVE-2026-54901 | 2426149 | f5-fluentd | oj |
| CVE-2026-54902 | 2426153 | f5-fluentd | oj |
| CVE-2026-54903 | 2426125 | f5-fluentd | oj |
| CVE-2026-55199 | 2426749 | postgresql | libssh2 |
| CVE-2026-55200 | 2426753 | postgresql | libssh2 |
| CVE-2026-56852 | 2425913, 2425933, 2425949, 2425969, 2425985, 2426001, 2426017, 2426033, 2426049, 2426065, 2426081, 2426097, 2426165, 2426185, 2426201, 2426217, 2426229, 2426249, 2426265, 2426281, 2426313, 2426489, 2426525, 2426545, 2426561, 2426577, 2426593, 2426665, 2426669, 2426673, 2426677, 2426681, 2426709, 2426729, 2426773, 2426809 | crd-conversion, crd-installer, crdupdater, f5-analyzer, f5-bdosd, f5-blobd, f5-bnk-cis, f5-csm-qkview, f5-debug-sidecar, f5-downloader, f5-dwbld, f5-env-discovery, f5-fluentd, f5-fqdn-resolver, f5-ipam-controller, f5-l4p-engine, f5-license-helper, f5-license-proxy, f5-lifecycle-operator, f5-node-labeler, f5-nsec-ips-daemon, f5-toda-observer, f5-toda-tmstatsd, f5-urlcat, f5dr-img, f5ing-tmm-pod-manager, f5ingress, init-certmgr, ocnos-img, opentelemetry-collector-contri, spk-csrc, spk-cwc | golang.org/x/text |
| CVE-2026-58469 | 2426833, 2426849, 2426869 | f5-downloader, f5-urlcat, f5ing-tmm-pod-manager | wget |
| CVE-2026-58470 | 2426837, 2426853, 2426873 | f5-downloader, f5-urlcat, f5ing-tmm-pod-manager | wget |
| CVE-2026-58471 | 2426841, 2426857, 2426877 | f5-downloader, f5-urlcat, f5ing-tmm-pod-manager | wget |
| CVE-2026-58472 | 2426845, 2426861, 2426881 | f5-downloader, f5-urlcat, f5ing-tmm-pod-manager | wget |
| CVE-2026-59995 | 2426893 | gslb-engine | openssh-client |
| CVE-2026-59996 | 2426897 | gslb-engine | openssh-client |
| CVE-2026-59997 | 2426901 | gslb-engine | openssh-client |
| CVE-2026-59998 | 2426905 | gslb-engine | openssh-client |
| CVE-2026-59999 | 2426909 | gslb-engine | openssh-client |
| CVE-2026-60000 | 2426913 | gslb-engine | openssh-client |
| CVE-2026-60001 | 2426917 | gslb-engine | openssh-client |
| CVE-2026-60002 | 2426921 | gslb-engine | openssh-client |
| CVE-2026-8286 | 2426357 | vault-init | curl |
| CVE-2026-8458 | 2426417 | vault-init | curl |
| CVE-2026-8924 | 2426409 | vault-init | curl |
| CVE-2026-8925 | 2426361 | vault-init | curl |
| CVE-2026-8926 | 2426413 | vault-init | curl |
| CVE-2026-8927 | 2426365 | vault-init | curl |
| CVE-2026-8932 | 2426369 | vault-init | curl |
| CVE-2026-9079 | 2426373 | vault-init | curl |
| CVE-2026-9080 | 2426377 | vault-init | curl |
| CVE-2026-9545 | 2426381 | vault-init | curl |
| CVE-2026-9546 | 2426385 | vault-init | curl |
| CVE-2026-9547 | 2426389 | vault-init | curl |
Model changes¶
(No model changes)
Fixed Issues¶
2313345-2¶
Title: F5-license-proxy Helm Chart Fails to Deploy with CSI-Based Storage Provisioners or OpenShift Restricted Security Constraints
Component: License Proxy
Symptoms: When you deploy the f5-license-proxy (FLP) Helm chart in an environment that uses a CSI-based dynamic storage provisioner or in an OpenShift cluster with restricted Security Context Constraints (SCC), you encounter the following issues:
On OpenShift with a restricted SCC, the IPC_LOCK capability in the container securityContext prevents the vault and vault-init pods from scheduling.
Selector.matchLabels defined in the chart prevent CSI dynamic provisioners from binding volumes, leaving all PersistentVolumeClaims (PVCs) stuck in Pending.
The chart sets storageClassName: standard in all PVs and PVCs, preventing the use of a custom storage class.
The chart always creates three hostPath PersistentVolumes with no option to disable them, making CSI-based deployments unsupported.
If you upgrade the chart and change volumes.vaultDataDir, Kubernetes returns an error: spec.persistentvolumesource is immutable after creation.
Conditions: Occurs when,
f5-license-proxy Helm chart versions earlier than 1.29.0-0.10.40 is deployed in a Kubernetes cluster that uses a CSI-based dynamic storage provisioner (such as EBS CSI or any non-hostPath provisioner), and/or an OpenShift cluster that enforces the restricted or restricted-v2 SCC.
Attempted to upgrade the chart while changing the volumes.vaultDataDir value.
Impact: Environments that use CSI-based storage or enforce OpenShift’s restricted SCC prevent deploying FLP, blocking installations entirely.
Fix Text: Below changes are done in f5-license-proxy Helm chart (1.29.0-0.10.40):
Added storage.createPV flag (default: true) to control rendering of the three static hostPath PersistentVolumes. Set this to false to skip PV creation in CSI-based environments.
Exposed storage.storageClassName (default: “standard”) and apply it uniformly to all PVs and PVCs, allowing you to specify your cluster’s storage class.
Added optional OpenShift Route support. A new flp-route.yaml template can create a Route with passthrough TLS termination (route.enabled: false by default). The Route host must match a SAN in the FLP server TLS certificate (set via FLP_HOST in setup.sh).
Removed IPC_LOCK from the vault and vault-init container securityContexts. Because disable_mlock = true is already set in vault.hcl, this capability was unnecessary and prevented scheduling under OpenShift’s restricted SCC. All containers now drop all capabilities.
Render selector.matchLabels on all three PVCs only when storage.createPV: true. Omit selectors with CSI provisioners so dynamic provisioning works correctly.
Upgrade note: The immutable PV spec issue during upgrades remains an operational constraint. Chart upgrades are not supported; reinstall the chart when changing versions.
2289845-2¶
Title: Resource limits set in Helm charts
Component: toda_fluentd
Symptoms: In release 2.2.0, installers had to manually configure resource limits for the Fluent Bit sidecar in the f5-downloader and f5-toda-fluentd pods in the Helm charts during installation. The cluster enforces the rq-f5-cor-cgn ResourceQuota, which requires explicit CPU and memory limits for all containers.
Conditions: Unable to deploy the f5-downloader and f5-toda-fluentd pods in Kubernetes because required resources were missing: the fluentbit sidecar container definition in f5-downloader and the fix-perms and fix-home-perms init container definitions in f5-toda-fluentd.
Impact: Pod creation failed with quota errors.
Fix Text: Starting with 2.2.x, the Helm charts configure CPU and memory limits by default (including for f5-downloader’s Fluent Bit sidecar and f5-toda-fluentd init containers), removing the need for manual settings.
2331037¶
Title: f5ingress crashes with nil pointer dereference when using a dual-stack service with manually managed endpoints
Component: ingress
Symptoms: f5ingress crashes with runtime error: invalid memory address or nil pointer dereference and enters CrashLoopBackOff. The following appears in the f5ingress logs:
2026-06-09 15:02:15.269|A|informational|1|CrKind=F5SPKIngressUDP|CrName=udp|AppNS=spk-app-1|Message=createF5SPKIngressUDP
2026-06-09 15:02:15.269|A|informational|1|Message="Getting endpoints for Service: udp-echo"
2026-06-09 15:02:15.274|C|informational|1|CrName=udp|AppNS=spk-app-1|Event=CR|Operation=Update|Message="CR changed, syncing"
2026-06-09 15:02:15.274|A|debug|1|Message="CR type *v1.F5SPKIngressUDP does not have a parent relationship to update."
E0609 15:02:15.275821 1 runtime.go:79] Observed a panic: "invalid memory address or nil pointer dereference"
(runtime error: invalid memory address or nil pointer dereference)
goroutine 83 [running]:
k8s.io/apimachinery/pkg/util/runtime.logPanic({0x1bfd320?, 0x32134f0})
Conditions: Occurs when,
A Kubernetes service is configured with dual-stack IP families (ipFamilies: [IPv4, IPv6]).
The service has no pod selector (Selector: none) and endpoints are managed manually via an Endpoints object (external service pattern).
An F5 SPK CR (UDP, TCP, HTTP2, etc.) references this service as a backend.
Impact: Occurs when,
f5ingress panics with runtime error: invalid memory address or nil pointer dereference immediately after the CR is applied.
f5ingress enters CrashLoopBackOff and stops processing all CRs across all namespaces.
No F5 SPK configuration is sent to TMM until f5ingress is restored.
Workaround: Change the service ipFamilyPolicy to SingleStack and ipFamilies to [IPv4].
Fix Text: The endpoint-resolution logic in f5ingress has been hardened to correctly get the list of backend endpoints for the configured dual-stack Service.
2230849-3¶
Title: Helm installation fails when namespace length causes pre-install hook Job name to exceed Kubernetes 63-character limit
Component: fsm-config
Symptoms: Installation of the f5ingress Helm chart may fail during the pre-install hook phase when deployed into namespaces with lengthy names. During installation, Helm generates a pre-install hook Job whose name includes the namespace value. If the namespace is too long, the resulting Job name exceeds the Kubernetes 63-character label limit, causing the Job creation to fail and terminating the Helm installation. The installation error may appear similar to:
INSTALLATION FAILED: failed pre-install: warning: Hook pre-install ... failed:
Job.batch "...prehook-job-<namespace>" is invalid:
spec.template.labels: Invalid value: "...": must be no more than 63 characters
Conditions: This issue occurs when:
The f5ingress Helm chart is installed.
The deployment namespace name is longer than approximately 36 characters.
The pre-install hook Job name is generated using the namespace value.
The resulting Job name exceeds Kubernetes’ 63-character limit for label values.
Impact: The Helm installation fails, preventing deployment of the f5ingress components in the affected namespace.
Workaround: Deploy the Helm chart in a namespace whose name length allows the generated Job name to remain within the Kubernetes 63-character limit.
Fix Text: Support longer namespace names when deploying.
2221753-2¶
Title: F5BigCneDatagroup configuration fails for non-address data types
Component: CRD
Symptoms: Datagroup configuration with “recordType: string” or “recordType: integer” fails with schema validation errors such as the following, preventing valid configurations: <nil>: Invalid value: "": "spec.records[0].key" must validate one and only one schema (oneOf). Found none valid.
Conditions: The Datagroup data type is specified via the “recordType” setting, which can be set to “address,” “integer,” or “string”. However for all datatypes, the CRD schema validation wrongly enforces IP Address validation, preventing “string” & “integer” data type configs to always fail.
Impact: Datagroup supports only the IP Address recordType and does not support the “integer” & “string” types.
Fix Text: CRD Schema validation is fixed to apply validation specific to the recordType setting.
1929045-7¶
Title: TMM may core after HTTP::respond is used for the first request on iSession connection
Component: LTM_HTTP
Symptoms: TMM crashes while establishing an iSession tunnel
Conditions: Occurs when:
APM configured
Traffic is handled by a virtual with an iRule having the HTTP::respond command
Tunnel is being established
Impact: Traffic disrupted while TMM restarts
Fix Text: When the tunnel is negotiated, BIG-IP prepares the connection for a graceful transition to the appropriate state, and TMM no longer crashes with the identified conditions
2262673-2¶
Title: Alternate method for driver TCL overrides using TMM_ARGS instead of –init-command
Component: fsm
Symptoms: In SPK 1.7.x user can provide driver override in TMM deployment using –init-command:
name: TMM_ARGS
value: --platform Z100 --ignore-bigstart -e --temp-platform-Z102 --init-command "ndal allow_sw_lro false"
In BNK 2.x version, these driver override specified using init-command does not work.
Conditions: Occurs when specifying driver TCL override using TMM_ARGS.
Impact: The driver TCL override does not take effect, leaving LRO types of overridden settings for driver with its factory value.
Workaround: Users can add the same TCL overrides that was added earlier using –init-command in TMM_ARGS when the configmap shows up in the TMM container as /opt/lib/tmm/tmm_init.tcl.pre file.
Fix Text: Specify the same driver TCL overrides by using preInit section as following:
f5-tmm:
tmm:
preInit:
enabled: true
content: |
ndal allow_sw_lro false
2368565-1¶
Title: TMM connects to read-only DB causing NAT operation failures
Component: dssm
Symptoms: After restart, TMM re-established its connection to the DSSM database pod but connected to the replica instead of the primary. This misconnection caused session APIs to fail, which in turn caused configured NAT operations to fail.
Conditions: TMM should be connected to sentinel based redis connection with NAT traffic enabled.
Impact: Because the TMM is connected to READONLY DB, the data sent to Redis DB will not be saved.
Fix Text: Fixed code to perform a Redis DB role check after establishing the connection.
2449625-2¶
Title: On restart, TMM reserves NAT IP ranges used by another active TMM
Component: CGNAT
Symptoms: After restart, the newly started TMM Pod may reserve NAT IP ranges already owned by another active TMM Pod, causing duplicate NAT IP range assignments across Pods.
Conditions: Occurs when,
Deployment consists of more than 10 TMM Pods.
Deployment is configured with source translation (NAT) objects.
A TMM Pod with a higher-indexed device name (e.g.,
DP-1) is restarted.
Impact: Traffic disruption caused by two TMM pods holding overlapping NAT IP ranges.
Fix Text: Fixed the NAT IP reservation logic to assign each TMM Pod a unique, non-overlapping NAT IP range after restarts or scale-ups.
2331757-1¶
Title: SPK f5ingress fails to program TMM for service endpoints using external IPs not on cluster nodes
Component: ingress
Symptoms: When an F5 SPK ingress Custom Resource (CR) references a Kubernetes Service with manually managed Endpoints that point to an external IP not hosted on any Kubernetes node, f5ingress does not send the virtual server configuration to TMM. The f5ingress logs report: “UDP Create Protobuf template processing error: error calling jsonAddr: bad address.” The CR status incorrectly reports SUCCESS even though f5ingress never delivered the configuration to TMM.
Conditions: Occurs when,
A Kubernetes service (ClusterIP: None) is configured.
The service has no pod selector (Selector: none), and endpoints are managed manually via an Endpoints object (external service pattern).
An F5 SPK CR (UDP, TCP, HTTP2, etc.) references this service as a backend.
Impact: F5ingress does not program the virtual server configuration into TMM. As a result, TMM does not forward traffic to the intended pool member. The CR status incorrectly reports SUCCESS, obscuring the failure.
Fix Text: The fix checks whether the Kubernetes Service referenced by the F5SPKIngress CR is selector-less because if it has selector then Kubernetes is managing the backend endpoints automatically. If the Service has no selector, f5ingress treats its endpoints as manually managed and skips the call that generates pool member ARPs and static routes. This prevents creation of a static_route for external endpoint IPs that do not map to any Kubernetes node. The remaining TMM configuration is generated and sent normally.
2389165-2¶
Title: IMI memory leak on every ‘show running-config’ execution
Component: fsm-dynamic-routing
Symptoms: The management/control-plane (imish) process gradually increases its memory usage over time and fails to reclaim it, which can degrade performance or trigger process restarts during prolonged or heavy CLI usage.
Conditions: Issue occurs by repeatedly viewing configuration contexts in the imish CLI—for example, by repeatedly running “show running-config.”
Impact: Each affected operation leaks a small memory block from the internal configuration tree. With frequent CLI or automation polling, long-running sessions, or scripted “show running-config” calls, memory in the imi process grows steadily, increasing memory pressure and potentially triggering an unexpected process restart on the device.
Workaround: Follow these steps if not upgraded:
Usage of
show running-configshould be restricted or reduced (e.g., avoid frequent/scripted polling).Frequent restarts of the imish process should be performed to reclaim the leaked memory.
Restart TMM pod or only the tmm-routing container.
Fix Text: Fixed a memory leak in the imi configuration module by releasing the internal patricia-tree structure allocated for each configuration mode when the mode is freed. The updated cleanup path now properly frees this structure, preventing leaks during repeated “show running-config” and related config-mode operations.
2292021-2¶
Title: Automated cleanup of orphaned log folders fully supported
Component: toda_fluentd
Symptoms: CNF 2.2.0 introduced the Automated Orphaned Log Folder Cleanup feature as an optional capability and documented it in the release notes. Initially, installation and upgrade workflows did not seamlessly support this feature.
Conditions: Helm chart for f5-toda-fluentd did not by default expose an env: or extraEnvVars: array in values.yaml to allow users to pass custom environment variables (such as those controlling the Folder Cleaner behavior) while installing/upgrading.
Impact: To support this feature, update the deployment’s environment variables after installation or an upgrade.
Fix Text: Updated Fluentd helm charts to support the feature by default from release 2.2.x.
2368509-3¶
Title: Coremond may write core files to ‘unknown’ when pod or container names mismatch
Component: toda_coremon
Symptoms: Renaming a pod causes coremond to write the pod’s core files under /var/cores/<node>/unknown/ instead of the expected namespace directory because the configuration file mis-maps the pod and container names. This is a known issue in CNF 2.2.0. In CNF 2.3.0 and later, coremond no longer uses that configuration file, so the issue does not occur.
Conditions: This occurs when the pod name or Helm release name differs from the actual container name and the configuration file cannot accurately map the renamed pod name and the container name.
Impact: The core files generated by a pod are written under /var/cores/<node>/unknown/ instead of the expected namespace directory.
Workaround: You can customize the configuration file to explicitly provide the process-to-container mapping, for example:
pods:
l1s6svcgtm:
containers:
tmm.0: f5-tmm
Fix Text: Customize the configuration file to explicitly provide the process-to-container mapping, for example:
pods:
l1s6svcgtm:
containers:
tmm.0: f5-tmm
2330525-3¶
Title: ICMP monitor prematurely marks pool member down before probe timeout
Component: fsm
Symptoms: The ICMP monitor marks pool members DOWN earlier than configured. With interval and timeout set to 5 seconds and the default down-count of 3, it should keep a pool member UP until it misses three consecutive probes, each timing out after 5 seconds (15 seconds from the first missed reply). Instead, it marks the member DOWN after approximately 13 seconds. After marking the member DOWN, the monitor also sends probes at irregular intervals; probes expected every 5 seconds arrive inconsistently, sometimes 2 or more seconds late.
Conditions: Any ICMP monitor where a probe does not receive a reply for 3 consecutive attempts.
Impact: The ICMP monitor may incorrectly mark pool members DOWN sooner than the configuration intends. This behavior can cause unnecessary traffic disruption, particularly in environments that expect brief network delays and set the timeout to tolerate them. The issue occurs specifically when the interval equals the timeout.
Fix Text: The ICMP monitor now calculates its internal idle timeout based on the monitor’s configured Interval and Timeout settings, instead of using a fixed short internal value. As a result, pool members are no longer marked DOWN prematurely due to an internal timing mismatch — the monitor now waits for the full configured timeout period before marking a pool member DOWN, consistent with the down-count and interval/timeout settings configured on the monitor.
2440693-3¶
Title: Stale NAT kernel routes remain after routing container restart
Component: fsm-dynamic-routing
Symptoms: A routing container restart can leave stale NAT kernel routes when the system updates NAT policy mid-restart (for example, during an OOM-triggered restart).
Conditions: Occurs when,
The routing container is restarted.
The NAT policy addresses are modified.
Impact: A stale route is invalid or could cause cross-pod BGP route advertisements.
Workaround: Restart the entire Pod, or just the tmrouted container.
Fix Text: During reinitialization of the routing daemon a full load sync of routes will occur.
2379869-1¶
Title: Redis sends user script errors to TMM
Component: dssm
Symptoms: Performing an arithmetic operation on a string value triggers a Lua script error and sends error logs to TMM.
Conditions: Only the conditional_incr_script_normal Lua script triggers this issue. On a key miss, the script sets data to 0 (a Lua number). It then evaluates data <= ARGV[3], which compares a number to a string because Redis Lua supplies all ARGV as strings.
Impact: The script skips the conditional increment on the value, and any non-numeric or empty-string delta breaks arithmetic coercion.
Fix Text: The script handles non-numeric or empty strings to prevent performing arithmetic on non-numeric values.
2379873-1¶
Title: Redis sends user script errors to TMM for bad Lua arguments
Component: dssm
Symptoms: When the master aux list has fewer than two elements, Redis returns nil for LINDEX aux_key 1, and the three subsequent string.sub(m_aux_data, …) calls raise errors.
Conditions: This issue will occur when master aux list has fewer than two values.
Impact: Passing fewer arguments causes the script to terminate immediately with a “bad argument” error.
Fix Text: Pass a nil value when the master aux list contains fewer than two keys to avoid a bad script error.
2377749-2¶
Title: DNS Transparent Cache with “answer-default-zones no” Responds Locally to _dns.resolver.arpa Instead of Forwarding to Pool
Component: DNS_CACHE
Symptoms: Due to new zones being added to Unbound as default zones, the domains ‘resolver.arpa’ and ‘service.arpa’ receive default answers instead of being resolved by upstream servers, even if ‘answer-default-zones’ is disabled.
Conditions: Resolver or transparent cache configured in DNS profile.
Impact: Client queries for names inside of zones ‘resolver.arpa’ and ‘service.arpa’ receive default answers instead of answers from authoritative servers. This may prevent clients from using the RFC9462 mechanisms to discover higher security DNS transports.
Workaround: If any local data with ‘type transparent’ is set for the names that are currently receiving default answers, this will override the default zone setting, and allow client queries to be answered using configured authoritative servers. For instance, a local data record of '_dns.resolver.arpa 3600 IN TXT "workaround"' set as a ‘type transparent’ record will allow clients to query that same name but for type SVCB, and those queries will be forwarded to the configured pool (for transparent cache).
Fix Text: With ‘answer-default-zones’ set to disabled, domains ‘resolver.arpa’ and ‘service.arpa’ are not answered with default responses. Queries are forwarded upstream.
2302053-1¶
Core File Streaming Supported from CNF 2.3.0 and higher
Component toda_coremon
Symptoms Initially core files were written to host volume. hostPath presents limitations in security, and flexibility, especially in cloud-native environments. In CNF 2.3.0 we introduced the streaming functionality to address this. For full feature documentation, see https://clouddocs.f5.com/cnfs/robin/latest/cnf-coremond.html. This feature is not supported in releases CNF 2.2.0 and lower.
Fix Text Set streaming=true in the override file. This would enable streaming in the supported platforms thus avoiding mounting the hostPath Volume that triggers security violations.
2390813-4¶
Title: Controller fails to update TMM pod annotations after reconfiguring VLAN
Component: ingress
Symptoms: Controller fails to update “k8s.v1.cni.cncf.io/network-status” annotation on TMM pods with its assigned selfIP from the internal VLAN.
Conditions:
If the internal VLAN is updated with change in selfIPs.
If controller deployment is updated with change in
MAX_ACTIVE_TMM_REPLICASenvironment variable.
Impact: The k8s.v1.cni.cncf.io/network-status annotations on TMM pods show stale or missing selfIPs which result into egress traffic failure.
Workaround: Delete the internal VLAN and recreate it.
Known issues¶
DSSM issues¶
2368573-1¶
Title: Lua script returns user-script errors when handling large arrays
Component: dssm
Symptoms: Scripts assume ARGV[] fields and Redis LINDEX/LRANGE results are always non-nil numeric strings, and they raise a Lua runtime error as soon as that assumption is violated.
Conditions: Lua scripts in Redis perform set and incr_if operations on long array data.
Impact: Script errors prevent Redis from storing the data.
Fix Text: Fixed missing string-to-number conversions in the Lua scripts wherever needed to handle non-nil numeric strings.
2389797-1¶
Title: Subscriber ID is missing in the rsyslog logs following the termination of all DSSM pods
Component: dssm
Symptoms: All DSSM pods are terminated at the same time.
Conditions: When all the DSSM pods are terminated at the same time.
Impact: When all DSSM pods are simultaneously terminated, recently added keys may not be saved to disk, resulting in missing subscriber IDs. The extent of data loss is dependent on the data being added to Redis.
Workaround: To avoid any loss of data, the aof-enabled can be set to true. This may have performance implications.
2130325-2¶
Title: GSLB virtual server health monitors don’t recover after GSLB Engine pod restart in Sync Group with a large number of monitor instances
Component: dssm
Symptoms: In GSLB Sync Groups with a high volume of health monitor instances (approximately 2,000 or more), certain virtual servers may persistently display a “no reply from probe-agent: timed out” health status following a GSLB Engine pod restart. These virtual servers do not recover to their correct health status, despite the underlying servers and monitors operating as expected.
Conditions: A GSLB Sync Group comprising three or more members is configured with a significant number of health monitor instances (for example, 50 HTTP and 50 ICMP monitors per generic host, with 10 or more virtual servers—totaling approximately 2,000 monitor instances). Subsequently, one or more GSLB Engine pods within the Sync Group are restarted (that is, scaled down and then back up).
Impact: Following a GSLB Engine pod restart, some virtual servers consistently report an incorrect health status (“no reply from probe-agent: timed out”), despite the monitors functioning as expected. As a result, GSLB DNS load balancing excludes healthy virtual servers from DNS responses, leading to suboptimal traffic distribution.
Workaround: To resolve this issue, simultaneously restart all GSLB Engine pods across every member of the Sync Group by scaling all GSLB Engine deployments down to zero replicas. Wait for all pods to fully terminate before scaling the deployments back up to one replica. If the problem persists after restarting the engines, re-create the GSLB Sync Group. To do this, remove all GSLB custom resources (CRs), beginning with the GSLB Local Instance CRs at each deployment, and then reapply them.
2287989-2¶
Title: DSSM Pod may restart if you add over 250k subscribers with GX at 1k rate
Component: dssm
Symptoms: Adding over 250k known subscribers with GX at a 1k rate may cause DSSM Pod restarts if the dssm-db container lacks enough resources.
Conditions: DSSM db container is not allocated with enough resources.
Impact: The DSSM Pod restarts and will impact the subscriber addition.
Workaround: Allocate at least 8 CPUs and 45GB memory for the DSSM DB container and set PVC to 45G for dssm-db pods. When deploying dssm-db pods, please specify these values in overrides file :
db:
persistent_storage_gb: 45
resources:
limits:
cpu: "8"
memory: 45Gi
requests:
cpu: "8"
memory: 45Gi
2264981-2¶
Title: Cross-cluster MDSSM communication fails if network routing is not set up for MDSSM pods
Component: dssm
Symptoms: When GSLB Sync Group is deployed with MDSSM enabled across two or more clusters, MDSSM pods in one cluster are unable to communicate with MDSSM pods or GSLB pods in the other cluster. The cross-cluster MDSSM connectivity fails due to missing network routing configuration for MDSSM pods.
Conditions: GSLB Sync Group is deployed on OpenShift with MDSSM enabled across two or more clusters. The f5ingress controller does not include MDSSM pod information in the initial egress routing configuration sent to the Cluster Static Route Controller (CSRC). As a result, no routing rules are created for MDSSM pod traffic to reach the shim interface.
Impact: MDSSM cross-cluster replication does not function. GSLB resource status data stored in MDSSM cannot be synchronized between clusters, preventing distributed session state sharing across sites.
Workaround: Restart both the f5ingress pod and the CSRC pod. After the restart, f5ingress will include MDSSM pods in the egress routing configuration, and CSRC will install the correct routing rules for MDSSM pod traffic. In some cases, restarting f5ingress alone may be sufficient, but if MDSSM communication still fails, delete and restart both the f5ingress and CSRC pods.
FSM issues¶
2389713-1¶
Title: Intermittent retention of HTTP profile settings after detachment
Component: fsm
Symptoms: Certain non-default HTTP profile settings remain active after applying a Custom Resource (CR) intended to remove HTTP settings. Specifically, the “insert_xforwarded_for = ENABLE” setting has been observed to remain active.
Conditions: When virtual server configured with HTTP and TCP profiles, and a CR is applied with only TCP settings.
Impact: Intermittently, requests have been observed with X-Forwarded-For header set to client IP address.
Workaround: Shut down the virtual server and then restart it. HTTP profile settings no longer active when HTTP profile removed from virtual server.
2284337-2¶
Title: WIPs config not pushed to GTM after correcting invalid GTM password in CIS
Component: fsm
Symptoms: If the GTM password in CIS is wrong, the WIPs configuration does not push to GTM for the related gateways. The issue continues even after you fix the password.
Conditions: Negative test when the GTM password in CIS is incorrect.
Impact: The WIPs configuration is not being pushed to GTM for the associated gateways even after correcting the password.
Workaround: Restart the CIS pod.
2277685-2¶
Title: When applying VRF and VLAN CRs before routing CRs, connected routes for non-default VRFs are incorrectly added to the default VRF routing table
Component: fsm-dynamic-routing
Symptoms: When VRF and VLAN custom resources (CRs) are applied before routing CRs, connected routes that belong to non-default VRFs (red, blue, green) are incorrectly installed in the default VRF routing table instead of their respective VRF routing tables. The per-VRF routing tables remain empty.
Conditions: VRF and VLAN custom resources (CRs) are applied before routing CRs.
Impact: Connected routes that belong to non-default VRFs are incorrectly installed in the default VRF routing table instead of their respective VRF routing tables.
Workaround: If the routing CRs are applied first and then the VRF/VLAN CRs are applied, the routes are correctly placed in their respective VRF tables.
f5ingress issues¶
2288497-2¶
Title: CR status may report success even when configuration was not applied to f5-tmm
Component: ingress
Symptoms: The f5ingress controller CR status field can report READY=true with the message “CR config sent to all grpc endpoints” even when f5-tmm did not receive or successfully apply the configuration. This gives a false-positive indication of successful configuration delivery, as the status only reflects that the gRPC send call completed without a transport-level error, not that f5-tmm actually applied the configuration internally.
Conditions:
An f5-tmm pod is evicted/rescheduled (e.g., during node draining) while configuration is in-flight, causing partial delivery when the connection is re-established.
A transient network interruption occurs while an f5-tmm pod is restarting, resulting in some objects being delivered before the interruption and others after, leaving f5-tmm with a partial configuration set.
f5-tmm receives the gRPC message without a transport error but fails to apply the configuration internally (e.g., due to a transient internal error or state inconsistency), most frequently observed in clusters with a large number of f5-tmm replicas.
Impact: Configuration expected to be present on f5-tmm may be silently missing or only partially applied, while the Kubernetes CR status continues to report success. This can result in traffic-affecting misconfiguration (e.g., missing Snatpool, virtual server, or pool objects) with no indication to the customer or operator that remediation is required.
Workaround: F5ingress restart. If issues persist even after an f5ingress pod restart, the restart removes the missing configuration and forces f5ingress to send a new configuration.
2289809-2¶
Title: The CNE controller does not remove SNAT pool translation addresses for non-default route domains after deleting two VLANs in a row
Component: ingress
Symptoms: TMM contains outdated SNAT pool addresses.
Conditions: The issue occurs under the following scenarios:
Scenario 1:
The configuration consists of one Egress, one Snatpool, one VRF, and two VLANs. One VLAN is VRF-aware and referenced by the Egress; the other is non-VRF and not referenced by the Egress.
The non-VRF VLAN is deleted.
The VRF-aware VLAN (referenced by the Egress) is subsequently deleted. As a result, a stale custom RD Snatpool remains.
Scenario 2:
The configuration consists of one Egress, one Snatpool, one VRF, and one VLAN that is VRF-aware and referenced by the Egress.
When the VLAN is deleted, a stale custom RD Snatpool persists.
Impact: TMM has stale snatpool addresses that may interfere with any new snat configuration.
Workaround:
Scenario 1:
Reapply both VLANs.
Delete the VRF-aware VLAN first.
Delete the non-VRF VLAN.
Scenario 2:
Reapply the VRF-aware VLAN together with the non-VRF VLAN.
Delete the VRF-aware VLAN first.
Delete the non-VRF VLAN.
GSLB issues¶
2277417-2¶
Title: GSLB Sync Group cannot have Sync Agent role changed when deployment with such role is down
Component: dns-gslb sync group
Symptoms: When GSLB instance with current Sync Agent role is down, due to GSLB Engine failure or an entire CNF deployment failure, then the GSLB Sync Group cannot reassign the Sync Agent role to another active GSLB instance.
Conditions: The GSLB deployment with the current Sync Agent role is down due to either a GSLB Engine failure or a complete CNF deployment failure. An attempt is made to apply the GSLB Sync Agent Custom Resource (CR) with a different GSLB instance name to another CNF deployment.
Impact: The GSLB Sync Agent CR cannot be applied with a different GSLB Instance Name because current GSLB Sync Agent CR is not removed.
Workaround: All CNF deployments must be removed from GSLB Custom Resources (CRs) by deleting the GSLB Local Instance CRs for each deployment individually. This action will initiate the internal cleanup process on the GSLB Engines, removing both their internal configurations and the associated GSLB CRs from their respective local Kubernetes servers. If the GSLB Engines are unable to communicate with their local Kubernetes servers to delete the GSLB CRs, manual removal is possible. To do so, set the GSLB_FORCE_DELETE_ENABLED environment variable to true in f5ingress. Afterward, restart all GSLB Engines and all TMMs to ensure the configurations are fully cleared.
2186801-3¶
Title: A GSLB object can be created with a reference to a GSLB monitor, even if the monitor itself has not yet been created
Component: dns-gslb general
Symptoms: The GSLB configuration object such as GSLB Server, GSLB Virtual Server, a GSLB Pool, or a GSLB Pool Member, can be created and referencing the name of a GSLB Monitor that does not exist. In these cases, the configuration objects are still created, even though the referenced GSLB Monitor is missing.
Conditions: GSLB configuration objects with referencing to a monitor are created while the monitor does not exist.
Impact: GSLB objects will remain in the blue state; however, based on the configured load balancing options, they may still be selected in response to DNS queries.
Workaround: GSLB configuration objects and corresponding monitors must be created regardless of order to ensure accurate reflection of object states.
2261089-2¶
Title: GSLB Sync Group fails inter-cluster communication due to SSL/TLS certificate issues. Configuration does not sync after connection
Component: dns-gslb engine
Symptoms: When deploying two CNF instances with GSLB enabled across separate Kubernetes clusters, the GSLB stream to the remote peer remains in a reconnecting state and reports a “Failed to establish connection” error. The status of the remote GSLB server displays as “Checking” rather than “Available.” Furthermore, even after successful inter-cluster communication is established through the configuration of shared certificates, the remote GSLB member may still fail to synchronize configurations from the Sync Agent.
Conditions: The GSLB Sync Group is deployed across multiple CNF instances in separate Kubernetes clusters. While basic network connectivity between clusters is established (ICMP ping is successful), each cluster utilizes SSL/TLS certificates issued by distinct Certificate Authorities, rather than a shared common CA. To enable GSLB traffic across clusters, TMM tunnels are required. This necessitates proper configuration of the GSLB Packet Path, including CSRC routing rules and the use of shared TLS certificates.
Impact: Inter-cluster communication within the GSLB Sync Group is currently non-functional. Remote GSLB instances remain in a “Checking” state and are unreachable, which prevents configuration synchronization and disrupts GSLB availability across sites. Although the certificate issue has been resolved and communication has been established, configuration synchronization from the Sync Agent to remote members may still fail to complete. As a result, remote GSLB instances do not receive the expected configuration updates.
Workaround: All clusters participating in the GSLB Sync Group must use SSL/TLS certificates issued by a common Certificate Authority (CA). Distribute the root and intermediate CA certificates to every cluster prior to deploying cert-manager and f5ingress. Strictly adhere to the GSLB Packet Path documentation when configuring CSRC routing rules to ensure GSLB gRPC traffic traverses the TMM shim interface. Note that a successful ICMP ping between GSLB instances does not guarantee the functionality of the GSLB gRPC communication path, as ICMP and gRPC traffic may follow different network routes. If configuration synchronization remains incomplete after establishing connectivity, remove all GSLB Custom Resources (beginning with the GSLB Local Instance CRs) from each deployment and reapply them to reset the synchronization state.
2265957-2¶
Title: GSLB Engine unable to establish TCP connections on OpenShift clusters with OVN-Kubernetes networking
Component: dns-gslb engine
Symptoms: On OpenShift clusters using OVN-Kubernetes networking, GSLB Engine is unable to establish TCP connections for inter-cluster communication. The initial connection handshake begins successfully, but subsequent packets are dropped by the network layer, causing connection failures. GSLB streams between clusters remain in a reconnecting state, and GSLB servers report “No enabled virtual server available” with monitor timeouts.
Conditions: OpenShift 4.14 or later cluster using OVN-Kubernetes as the networking plugin. GSLB Sync Group configured with multiple clusters requiring inter-cluster communication.
Impact: GSLB synchronization between clusters fails. Health monitors cannot reach remote virtual servers, causing GSLB to mark all servers as unavailable. DNS load balancing across clusters does not function correctly.
Workaround: Adjust the network routing rule priority configuration.
2283789-2¶
Title: GSLB Sync Group Communication Issues on OpenShift with OVN-Kubernetes Networking
Component: dns-gslb sync group
Symptoms: On OpenShift clusters with OVN-Kubernetes networking, GSLB Sync Group inter-cluster communication fails unless specific Linux kernel networking parameters are manually changed on the worker nodes where GSLB Engine and Probe Agent pods are running. Without these changes, traffic from GSLB pods is not forwarded correctly, and GSLB instances in the Sync Group cannot reach each other.
Conditions: GSLB Sync Group is deployed on OpenShift 4.14 or 4.16 with OVN-Kubernetes as the cluster networking plugin. The worker nodes are using default OVN-Kubernetes sysctl settings (IP forwarding disabled, strict reverse path filtering).
Impact: GSLB Sync Group functionality does not work with default OpenShift node settings. Inter-cluster GSLB communication is broken, preventing configuration synchronization and probe data exchange between GSLB instances. The required workaround involves host-level changes to OpenShift worker nodes, which may conflict with your security policies or operational constraints.
Workaround: On each OpenShift worker node where GSLB Engine or Probe Agent pods are scheduled, apply the following sysctl settings:
set net.ipv4.ip_forward to 1
set net.ipv4.conf.all.rp_filter to 2
set net.ipv4.conf.default.rp_filter to 2.
These settings enable IP forwarding and relax reverse path filtering to loose mode. They can be applied at runtime using sysctl -w or persisted via sysctl configuration files or an OpenShift MachineConfig.
Note
These are node-level changes and must be applied on every worker node hosting GSLB pods.
2279717-2¶
Title:GSLB Sync Group traffic between instances fails on OpenShift without manually added static routes
Component: dns-gslb sync group
Symptoms: On OpenShift environments, GSLB Engine and GSLB Probe Agent pods are unable to communicate with remote GSLB instances. Traffic destined for remote GSLB instance addresses is not correctly forwarded through the expected network path, causing GSLB Sync Group connectivity failures.
Conditions: GSLB Sync Group is deployed on an OpenShift 4.14 environment with OVN-Kubernetes networking. Multiple GSLB instances are configured across different CNF deployments that need to communicate with each other.
Impact: GSLB Sync Group functionality does not work out of the box on OpenShift. Without manual intervention, GSLB instances cannot synchronize configuration or exchange probe data with remote instances, effectively preventing multi-site GSLB operation. The required manual workaround must be reapplied after every pod restart.
Workaround: After each GSLB Engine or GSLB Probe Agent pod starts (or restarts), manually add a static route inside the pod to direct traffic for remote GSLB instance subnets through the OVN management port gateway. For example: ip route add <remote-gslb-instance-subnet> via <ovn-management-port-gateway-ip> dev eth0. This route must be re-added whenever the affected pods are restarted.
2285413-2¶
Title: GSLB inter-instance traffic on non-Sync Agent member is routed through the Kubernetes pod network instead of the TMM internal VLAN
Component: dns-gslb sync group
Symptoms: On the non-Sync Agent member of a GSLB Sync Group deployed on OpenShift, incoming GSLB traffic from the Sync Agent is received by TMM but is forwarded to the GSLB Engine via the Kubernetes pod network interface (eth0) instead of the TMM internal VLAN (shim interface). This causes GSLB inter-engine communication to use an incorrect network path, with ingress traffic not following the same data plane path as egress traffic.
Conditions: A GSLB Sync Group with two or more CNF deployments is configured on OpenShift. The non-Sync Agent member receives GSLB traffic from the Sync Agent. The f5ingress controller does not add the required static route on TMM to direct GSLB traffic through the internal VLAN interface.
Impact: GSLB traffic between Sync Group members on the non-Sync Agent side flows through the Kubernetes pod network instead of the TMM data plane. This results in asymmetric routing where egress GSLB traffic uses the correct internal VLAN path but ingress GSLB traffic bypasses it. This may cause GSLB health monitoring (e.g., HTTPS monitors) and probe traffic to fail or behave unexpectedly.
Workaround: None