Cloud-Native Network Functions on Robin 2.2.4 release notes¶
About this release¶
Introduction¶
These release notes describe the differences between CNFs on Robin 2.2.3 and 2.2.4.
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.
Supported container-orchestration platforms¶
This release is officially supported on these container-orchestration platforms and versions:
| Platform | Version | Recommended Helm version |
|---|---|---|
| Robin | 5.4.3-616 | 3 or later |
| Robin | 5.4.3-564 | 3 or later |
| Robin | 5.4.3-302 | 3 or later |
| Robin | 5.3.11-217 | 3 or later |
Security updates¶
(No F5 security updates)
List of other CVEs¶
| CVE Number | Bug IDs | Image Names | Package Name |
|---|---|---|---|
| CVE-2026-10536 | 2361337, 2425233 | f5-fluentbit, vault-init | curl, libcurl4t64 |
| CVE-2026-11352 | 2425177 | vault-init | curl |
| CVE-2026-11564 | 2425237 | vault-init | curl |
| CVE-2026-11586 | 2425181 | vault-init | curl |
| CVE-2026-11850 | 2425453 | postgresql | krb5 |
| CVE-2026-11856 | 2425241 | vault-init | curl |
| CVE-2026-12064 | 2425185 | vault-init | curl |
| CVE-2026-33630 | 2425189 | vault-init | c-ares |
| CVE-2026-39822 | 2424733, 2424753, 2424769, 2424785, 2424801, 2424817, 2424833, 2424849, 2424865, 2424873, 2424889, 2424905, 2424909, 2424913, 2424917, 2424921, 2424989, 2425005, 2425025, 2425033, 2425053, 2425069, 2425085, 2425097, 2425113, 2425133, 2425149, 2425161, 2425273, 2425293, 2425309, 2425317, 2425333, 2425401, 2425417, 2425433, 2425457, 2425493, 2425513, 2425541, 2425557, 2425565, 2425573, 2425589, 2425609, 2425757, 2430509, 2430513 | 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-cert-client, f5-coremond, 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-41991 | 2425765 | baseos | gzip |
| CVE-2026-41992 | 2425769 | baseos | gzip |
| CVE-2026-42505 | 2424737, 2424757, 2424773, 2424789, 2424805, 2424821, 2424837, 2424853, 2424869, 2424877, 2424893, 2424925, 2424929, 2424933, 2424937, 2424941, 2424993, 2425009, 2425029, 2425037, 2425057, 2425073, 2425089, 2425101, 2425117, 2425137, 2425153, 2425165, 2425277, 2425297, 2425313, 2425321, 2425345, 2425405, 2425421, 2425437, 2425477, 2425497, 2425517, 2425545, 2425561, 2425569, 2425577, 2425593, 2425613, 2425773, 2430517, 2430521 | 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-cert-client, f5-coremond, 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-46600 | 2425373, 2425597 | f5-coremond, f5-csm-qkview | golang.org/x/net |
| CVE-2026-47240 | 2334101 | f5-fluentd | net-imap |
| CVE-2026-47241 | 2334109 | f5-fluentd | net-imap |
| CVE-2026-47242 | 2334105 | f5-fluentd | net-imap |
| CVE-2026-48978 | 2425357 | f5-lifecycle-operator | oras.land/oras-go/v2 |
| CVE-2026-50151 | 2425337 | f5-lifecycle-operator | oras.land/oras-go/v2 |
| CVE-2026-50162 | 2425349 | f5-lifecycle-operator | oras.land/oras-go/v2 |
| CVE-2026-54696 | 2425501 | f5-fluentd | json |
| CVE-2026-55199 | 2425445 | postgresql | libssh2 |
| CVE-2026-55200 | 2425449 | postgresql | libssh2 |
| CVE-2026-56852 | 2424745, 2424765, 2424781, 2424797, 2424813, 2424829, 2424845, 2424861, 2424885, 2424901, 2424965, 2424969, 2424973, 2424977, 2424981, 2425001, 2425017, 2425045, 2425061, 2425081, 2425109, 2425125, 2425145, 2425173, 2425285, 2425305, 2425329, 2425365, 2425377, 2425413, 2425429, 2425485, 2425505, 2425553, 2425585, 2425601 | crd-conversion, crd-installer, crdupdater, f5-analyzer, f5-bdosd, f5-blobd, f5-coremond, 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 | 2425685, 2425705, 2425721, 2425737 | f5-downloader, f5-urlcat, f5ing-tmm-pod-manager, rabbit | wget |
| CVE-2026-58470 | 2425693, 2425709, 2425725, 2425741 | f5-downloader, f5-urlcat, f5ing-tmm-pod-manager, rabbit | wget |
| CVE-2026-58471 | 2425697, 2425713, 2425729, 2425745 | f5-downloader, f5-urlcat, f5ing-tmm-pod-manager, rabbit | wget |
| CVE-2026-58472 | 2425701, 2425717, 2425733, 2425749 | f5-downloader, f5-urlcat, f5ing-tmm-pod-manager, rabbit | wget |
| CVE-2026-59995 | 2425633 | gslb-engine | openssh-client |
| CVE-2026-59996 | 2425637 | gslb-engine | openssh-client |
| CVE-2026-59997 | 2425641 | gslb-engine | openssh-client |
| CVE-2026-59998 | 2425645 | gslb-engine | openssh-client |
| CVE-2026-59999 | 2425649 | gslb-engine | openssh-client |
| CVE-2026-60000 | 2425653 | gslb-engine | openssh-client |
| CVE-2026-60001 | 2425657 | gslb-engine | openssh-client |
| CVE-2026-60002 | 2425661 | gslb-engine | openssh-client |
| CVE-2026-8286 | 2425197 | vault-init | curl |
| CVE-2026-8458 | 2425257 | vault-init | curl |
| CVE-2026-8924 | 2425249 | vault-init | curl |
| CVE-2026-8925 | 2425201 | vault-init | curl |
| CVE-2026-8926 | 2425253 | vault-init | curl |
| CVE-2026-8927 | 2425205 | vault-init | curl |
| CVE-2026-8932 | 2425209 | vault-init | curl |
| CVE-2026-9079 | 2425213 | vault-init | curl |
| CVE-2026-9080 | 2425217 | vault-init | curl |
| CVE-2026-9545 | 2425221 | vault-init | curl |
| CVE-2026-9546 | 2425225 | vault-init | curl |
| CVE-2026-9547 | 2425229 | vault-init | curl |
New features¶
(No new features)
Enhancements¶
(No new enhancements)
Model changes¶
(No model changes)
Fixed Issues¶
2289845-1¶
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.
2313345-3¶
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.
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.
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.
Example service configuration:
apiVersion: v1
kind: Service
metadata:
annotations:
meta.helm.sh/release-name: udp-app
meta.helm.sh/release-namespace: spk-app-1
creationTimestamp: "2026-06-09T14:57:36Z"
labels:
app.kubernetes.io/managed-by: Helm
name: udp-echo
namespace: spk-app-1
resourceVersion: "120597"
uid: aadeaa18-6827-4010-b105-447d1b23fa68
spec:
clusterIP: None
clusterIPs:
- None
internalTrafficPolicy: Cluster
ipFamilies:
- IPv4
- IPv6
ipFamilyPolicy: PreferDualStack
ports:
- port: 9181
protocol: UDP
targetPort: 9181
sessionAffinity: None
type: ClusterIP
status:
loadBalancer: {}
kind: List
metadata:
resourceVersion: ""
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.
2221753-1¶
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 from working.
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.
2262673-1¶
Title: Alternate method for driver TCL overrides using TMM_ARGS instead of –init-command
Component: fsm
Symptoms: In SPK 1.7.x users can provide driver overrides 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 overrides specified using –init-command do 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 the driver with its factory value.
Workaround: Users can add the same TCL overrides that were 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 the preInit section as follows:
f5-tmm:
tmm:
preInit:
enabled: true
content: |
ndal allow_sw_lro false
2230849-2¶
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.
2368565-2¶
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-1¶
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-2¶
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.
Example service configuration:
apiVersion: v1
kind: Service
metadata:
annotations:
meta.helm.sh/release-name: udp-app
meta.helm.sh/release-namespace: spk-app-1
creationTimestamp: "2026-06-09T14:57:36Z"
labels:
app.kubernetes.io/managed-by: Helm
name: udp-echo
namespace: spk-app-1
resourceVersion: "120597"
uid: aadeaa18-6827-4010-b105-447d1b23fa68
spec:
clusterIP: None
clusterIPs:
- None
internalTrafficPolicy: Cluster
ipFamilies:
- IPv4
- IPv6
ipFamilyPolicy: PreferDualStack
ports:
- port: 9181
protocol: UDP
targetPort: 9181
sessionAffinity: None
type: ClusterIP
status:
loadBalancer: {}
kind: List
metadata:
resourceVersion: ""
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. 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-1¶
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 the 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.
2289817-2¶
Title: Erroneous TXQ Full Health Check Marks Interface Down, Causing TMM Pod Connectivity Loss
Component: Drivers
Symptoms: TMM fails with error:
"Error: Set unhealthy status flag because txq has been full for <####> seconds""Error: Marking down interface because unhealthy flag set to true."
Conditions:
TMM handles traffic, but one or more dataplane interfaces (e.g., 1.1, 1.2) expose fewer device queues than the available threads.
In this scenario, multiple TMM threads share a single device queue, which increases the likelihood that the underlying NIC struggles to handle the traffic those threads transmit simultaneously on the TX path.
When this happens, one or more device queues temporarily increase their “blocked” counters in the ‘tmm/ndal_tx_stats’ table. This behavior usually does not cause issues because the NIC almost always recovers on its own.
The temporary rise in blocked counters can trigger the internal device TXQ health check, which also uses the number of sent packets to detect when the queue becomes unblocked. If the “sent” counter wraps to zero after it reaches its maximum value, the health check triggers after the next increment of the “blocked” counter.
Impact: Loss of data-plane connectivity as interfaces are marked down.
Workaround: Disable txq healthcheck by setting the timeout to 0. In your TMM deployment, add a new configmap or a host file with the following content: ndal tx_dq_timeout_sec 0. This configmap or host-file should appear within the TMM container as /opt/lib/tmm/tmm_init.tcl.pre.
Fix Text: Update the health check to correctly handle wrap-arounds of the “sent” counter.
2262673-1¶
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
1929045-8¶
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
2292021-1¶
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: The 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, the deployment’s environment variables had to be updated after installation or an upgrade.
Fix Text: Updated Fluentd helm charts to support the feature by default from release 2.2.x.
2330525-2¶
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-2¶
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-2¶
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-2¶
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 the 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.
2390813-3¶
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.
Fix Text: Stale annotation on TMM pods are removed.
Known Issues¶
2288497-1¶
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.
2390145-1¶
Title: Egress traffic is disrupted during the upgrade process
Component: egress
Symptoms: Egress traffic from the application pod will fail following the upgrade.
Conditions: Version upgrade and TMM Pod restart.
Impact: VXLAN interfaces and IP routes are wrongly provisioned on node and TMM, resulting in disruption of egress traffic.
Workaround: Delete Egress CR and restart the cne-controller pod. Improved the APP-TMM pod IP mappings synchronization logic in BIG-IP Next for Kubernetes 2.3.0 and higher versions.
2330929-5¶
Title: ACL hardware stat intermittently out of sync
Component: Firewall (ACL)
Symptoms: The hw_counter field in the fw_rule_stat tmctl table may intermittently fail to increment.
Conditions: This occurs intermittently for gateway attached firewall policies.
Impact: ACL hw_counter stat may report values lower than actual traffic counts.
Workaround: Remove and reapply the configurations to reset the stats.
2183833-3¶
Title: SIP egress CRD installation is not supported by FLO
Component: egress
Symptoms: SIP egress CRD is not installed when installing BNK via the F5 Lifecycle Operator (FLO).
Conditions: CRD installation is done using only FLO.
Impact: SIP egress CRD will be missing in the CRDs installed using FLO and SIP egress functionality will not be supported.
Workaround: Install SIP egress CRD using helm.
2391145-1¶
Title: HTTP/2 egress traffic is not forwarded on OpenShift 4.18.39 with ConnectX-7 (CX7) adapters
Component: Drivers
Symptoms: HTTP/2 client requests time out occurs when TMM does not forward HTTP/2 egress traffic to the backend server, even though the HTTP/2 virtual servers are configured and operational.
Conditions: This issue occurs on OpenShift 4.18.39 deployments using NVIDIA ConnectX-7 (CX7) adapters with HTTP/2 egress traffic. The issue is not observed on equivalent ConnectX-6 (CX6) deployments.
Impact: HTTP/2 egress connections fail, preventing client applications from communicating with backend HTTP/2 servers.
2302053-2¶
Title: Core File Streaming Supported from BNK 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 BNK 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 BNK 2.2.0 and lower.
Conditions: Streaming=false
Workaround: HostPath volume gets created, and security violation gets triggered.
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.
2368573-2¶
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.