Cloud-Native Network Functions on AON 2.3.4 release notes¶
About this release¶
Introduction¶
These release notes describe the differences between CNFs on AON 2.3.3 and 2.3.4.
Note
This is a critical release. See Overview of F5 Critical Releases for more information and treat every release as though it closes a critical gap.
The following table summarizes the impact of Critical and High severity vulnerabilities in the data plane across the F5 product portfolio.
| Data Plane | ||
|---|---|---|
| Product | Critical | High |
| F5 Distributed Cloud Services | No | No |
| BIG-IP TMOS | Yes | Yes |
| BIG-IP Access Policy Manager (APM) Clients | No | Yes |
| BIG-IP SSL Orchestrator | Yes | Yes |
| F5OS - Appliance | Yes | Yes |
| F5OS - Chassis | Yes | Yes |
| BIG-IQ | Yes | Yes |
| F5 Insight | Yes | Yes |
| BIG-IP Next for Kubernetes | Yes | Yes |
| F5 BIG-IP Cloud-Native Network Functions (CNFs) | Yes | Yes |
| BIG-IP Next for Kubernetes (Host) | Yes | Yes |
| BIG-IP eBPF Observability (EOB) | No | No |
| BIG-IP Container Ingress Services (CIS) | No | No |
| Aspen Mesh | No | No |
| F5 NGINX Plus | No | Yes |
Security updates¶
> Click to expand
List of other CVEs¶
| CVE Number | Bug IDs | Image Names | Package Name |
|---|---|---|---|
| CVE-2025-59777 | 2479421 | postgresql | libmicrohttpd |
| CVE-2025-62689 | 2479425 | postgresql | libmicrohttpd |
| CVE-2026-10722 | 2479165 | opentelemetry-collector-contri | github.com/cilium/ebpf |
| CVE-2026-10723 | 2480105 | f5-debug-sidecar | bind9-dnsutils |
| CVE-2026-10822 | 2480109 | f5-debug-sidecar | bind9-dnsutils |
| CVE-2026-11331 | 2480113 | f5-debug-sidecar | bind9-dnsutils |
| CVE-2026-11622 | 2480117 | f5-debug-sidecar | bind9-dnsutils |
| CVE-2026-11721 | 2480121 | f5-debug-sidecar | bind9-dnsutils |
| CVE-2026-11850 | 2480089 | ocnos-img | libgssapi-krb5-2 |
| CVE-2026-11856 | 2362997, 2363073, 2363109, 2363145, 2480093 | crd-installer, f5-debug-sidecar, f5-fluentbit, f5ingress, ocnos-img | curl, libcurl4t64 |
| CVE-2026-11979 | 2479429 | postgresql | libxml2 |
| CVE-2026-12617 | 2480125 | f5-debug-sidecar | bind9-dnsutils |
| CVE-2026-13321 | 2480129 | f5-debug-sidecar | bind9-dnsutils |
| CVE-2026-14456 | 2479433 | postgresql | openssl |
| CVE-2026-14662 | 2479437 | postgresql | postgresql |
| CVE-2026-14663 | 2479537 | postgresql | postgresql |
| CVE-2026-14664 | 2479441 | postgresql | postgresql |
| CVE-2026-14666 | 2479541 | postgresql | postgresql |
| CVE-2026-14668 | 2479445 | postgresql | postgresql |
| CVE-2026-14669 | 2479449 | postgresql | postgresql |
| CVE-2026-14670 | 2479453 | postgresql | postgresql |
| CVE-2026-14671 | 2479457 | postgresql | postgresql |
| CVE-2026-14672 | 2479545 | postgresql | postgresql |
| CVE-2026-14673 | 2479577 | postgresql | postgresql |
| CVE-2026-14676 | 2479461 | postgresql | postgresql |
| CVE-2026-14677 | 2479465 | postgresql | postgresql |
| CVE-2026-14678 | 2479549 | postgresql | postgresql |
| CVE-2026-14679 | 2479469 | postgresql | postgresql |
| CVE-2026-14680 | 2479473 | postgresql | postgresql |
| CVE-2026-14681 | 2479553 | postgresql | postgresql |
| CVE-2026-15059 | 2480281 | baseos | libsystemd0 |
| CVE-2026-15741 | 2479477 | postgresql | postgresql |
| CVE-2026-15742 | 2479481 | postgresql | postgresql |
| CVE-2026-16238 | 2479485 | postgresql | postgresql |
| CVE-2026-16239 | 2479489 | postgresql | postgresql |
| CVE-2026-16241 | 2479581 | postgresql | postgresql |
| CVE-2026-16389 | 2479409 | postgresql | nss-libs |
| CVE-2026-16742 | 2480285 | baseos | libsystemd0 |
| CVE-2026-18024 | 2479557 | postgresql | postgresql |
| CVE-2026-18408 | 2479493 | postgresql | postgresql |
| CVE-2026-19385 | 2479497 | postgresql | postgresql |
| CVE-2026-33818 | 2478485, 2478513, 2478545, 2478569, 2478593, 2478617, 2478685, 2478713, 2478757, 2478785, 2478829, 2478857, 2478885, 2478913, 2478941, 2478977, 2479005, 2479037, 2479065, 2479097, 2479125, 2479173, 2479205, 2479237, 2479269, 2479297, 2479353, 2479381, 2479589, 2479625, 2479653, 2479685, 2479713, 2479749, 2479777, 2479813, 2479845, 2479849, 2479925, 2479957, 2479989, 2480025, 2480053, 2480249 | 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-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, vault, vault-init | stdlib |
| CVE-2026-39821 | 2361505, 2361509, 2361513, 2361517, 2361673, 2361701, 2361781, 2361821, 2361861, 2361893, 2361981, 2362053, 2362117, 2362145, 2362173, 2362201, 2362229, 2362309, 2362389, 2362477, 2362513, 2362541, 2362621, 2362657, 2362685, 2362765, 2362793, 2362821, 2362881, 2362909, 2425829, 2478517, 2478717, 2478789, 2478889, 2479009, 2479129, 2479209, 2479593, 2479717, 2479781, 2479817, 2479853, 2479857, 2479929, 2479961, 2479993, 2480057, 2480253 | 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-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, vault, vault-init | golang.org/x/net, stdlib |
| CVE-2026-40355 | 2480097 | ocnos-img | libgssapi-krb5-2 |
| CVE-2026-40356 | 2480101 | ocnos-img | libgssapi-krb5-2 |
| CVE-2026-40467 | 2479501 | postgresql | gawk |
| CVE-2026-40468 | 2479413 | postgresql | gawk |
| CVE-2026-40469 | 2479417 | postgresql | gawk |
| CVE-2026-40553 | 2479505 | postgresql | gawk |
| CVE-2026-41989 | 2479561 | postgresql | libgcrypt |
| CVE-2026-44604 | 2479509 | postgresql | rpm-libs |
| CVE-2026-46600 | 2425909, 2425929, 2425945, 2425965, 2425981, 2425997, 2426013, 2426029, 2426045, 2426061, 2426077, 2426093, 2426181, 2426197, 2426245, 2426261, 2426277, 2426309, 2426485, 2426521, 2426541, 2426557, 2426573, 2426589, 2426649, 2426653, 2426657, 2426661, 2426705, 2426725, 2426769, 2426805, 2478521, 2478721, 2478793, 2479013, 2479133, 2479213, 2479785, 2479861, 2479865, 2479933, 2479965, 2479997, 2480061, 2480257 | 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-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 | golang.org/x/net, stdlib |
| CVE-2026-48863 | 2479513 | postgresql | libsolv |
| CVE-2026-48864 | 2479517 | postgresql | libsolv |
| CVE-2026-54369 | 2479521 | postgresql | libacl |
| CVE-2026-54411 | 2480289 | baseos | libpam-modules |
| CVE-2026-5450 | 2480293 | baseos | libc-bin |
| CVE-2026-56853 | 2478489, 2478525, 2478549, 2478573, 2478597, 2478621, 2478689, 2478725, 2478761, 2478797, 2478833, 2478861, 2478893, 2478917, 2478945, 2478981, 2479017, 2479041, 2479069, 2479101, 2479137, 2479177, 2479217, 2479241, 2479273, 2479301, 2479357, 2479385, 2479597, 2479629, 2479657, 2479689, 2479721, 2479753, 2479789, 2479821, 2479869, 2479873, 2479937, 2479969, 2480001, 2480029, 2480065, 2480261 | 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-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, vault, vault-init | stdlib |
| CVE-2026-56858 | 2478493, 2478529, 2478553, 2478577, 2478601, 2478625, 2478693, 2478729, 2478765, 2478801, 2478837, 2478865, 2478897, 2478921, 2478949, 2478985, 2479021, 2479045, 2479073, 2479105, 2479141, 2479181, 2479221, 2479245, 2479277, 2479305, 2479361, 2479389, 2479601, 2479633, 2479661, 2479693, 2479725, 2479757, 2479793, 2479825, 2479877, 2479881, 2479941, 2479973, 2480005, 2480033, 2480069, 2480265 | 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-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, vault, vault-init | stdlib |
| CVE-2026-56859 | 2478497, 2478533, 2478557, 2478581, 2478605, 2478629, 2478697, 2478733, 2478769, 2478805, 2478841, 2478869, 2478901, 2478925, 2478953, 2478989, 2479025, 2479049, 2479077, 2479109, 2479145, 2479185, 2479225, 2479249, 2479281, 2479309, 2479365, 2479393, 2479605, 2479637, 2479665, 2479697, 2479729, 2479761, 2479797, 2479829, 2479885, 2479889, 2479945, 2479977, 2480009, 2480037, 2480073, 2480269 | 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-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, vault, vault-init | stdlib |
| CVE-2026-56860 | 2478501, 2478537, 2478561, 2478585, 2478609, 2478633, 2478701, 2478737, 2478773, 2478809, 2478845, 2478873, 2478905, 2478929, 2478957, 2478993, 2479029, 2479053, 2479081, 2479113, 2479149, 2479189, 2479229, 2479253, 2479285, 2479313, 2479369, 2479397, 2479609, 2479641, 2479669, 2479701, 2479733, 2479765, 2479801, 2479833, 2479893, 2479897, 2479949, 2479981, 2480013, 2480041, 2480077, 2480273 | 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-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, vault, vault-init | stdlib |
| CVE-2026-56862 | 2478505, 2478541, 2478565, 2478589, 2478613, 2478637, 2478705, 2478741, 2478777, 2478813, 2478849, 2478877, 2478909, 2478933, 2478961, 2478997, 2479033, 2479057, 2479085, 2479117, 2479153, 2479193, 2479233, 2479257, 2479289, 2479317, 2479373, 2479401, 2479613, 2479645, 2479673, 2479705, 2479737, 2479769, 2479805, 2479837, 2479901, 2479905, 2479953, 2479985, 2480017, 2480045, 2480081, 2480277 | 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-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, vault, vault-init | stdlib |
| CVE-2026-56864 | 2479157 | opentelemetry-collector-contri | golang.org/x/mod |
| CVE-2026-56865 | 2479161 | opentelemetry-collector-contri | golang.org/x/mod |
| CVE-2026-5928 | 2480297 | baseos | libc-bin |
| CVE-2026-59890 | 2478969 | f5-bnk-cis | setuptools |
| CVE-2026-6464 | 2479525 | postgresql | postgresql |
| CVE-2026-6469 | 2479585 | postgresql | postgresql |
| CVE-2026-6470 | 2479565 | postgresql | postgresql |
| CVE-2026-6471 | 2479529 | postgresql | postgresql |
| CVE-2026-9149 | 2479569 | postgresql | libsolv |
| CVE-2026-9150 | 2479573 | postgresql | libsolv |
| CVE-2026-94127 | 2532609 |
Model changes¶
(No model changes)
Fixed Issues¶
2524777-6¶
BIG-IP APM vulnerability CVE-2026-94127
Component: Access
Symptoms: For more information, see BIG-IP APM vulnerability CVE-2026-94127, available at https://my.f5.com/manage/s/article/K000162605
Conditions: For more information, see BIG-IP APM vulnerability CVE-2026-94127, available at https://my.f5.com/manage/s/article/K000162605
Impact: For more information, see BIG-IP APM vulnerability CVE-2026-94127, available at https://my.f5.com/manage/s/article/K000162605
Fix Text: For more information, see BIG-IP APM vulnerability CVE-2026-94127, available at https://my.f5.com/manage/s/article/K000162605
2171921-10¶
TMM crash
Component: Access
Symptoms: TMM not processing traffic properly.
Conditions: When APM is provisioned.
Impact: TMM crashes thereby impacting traffic.
Fix Text: TMM now processing traffic properly.
2349797-2¶
Configuring dynamicCapacityReduction in F5BigAnalyzer CR triggers “Invalid request schema” in the custom analyzer plugin
Component: analyzer
Symptoms: On BNK v2.3.x, a custom Python analyzer plugin fails every analyzer cycle with “status”: “error”, “message”: “Invalid request schema.” Analyzer pod logs show the system rejects the payload before the plugin runs. Consequently, the controller removes weight annotations from L4Route and HTTPRoute CRs on each cycle, and traffic falls back to the default round-robin instead of the intended weighted distribution.
Conditions: Occurs when,
BNK v2.3.x is deployed with Intelligent AI Load Balancing enabled (intelligentLB: enabled: true in CNEInstance CR).
An F5BigAnalyzer CR of type “custom” is configured referencing ConfigMap-based Python plugin.
dynamicCapacityReduction is present in the F5BigAnalyzer CR spec (the issue occurs regardless of enabled: true or enabled: false).
The custom plugin uses PLUGIN_REQUEST_SCHEMA with “additionalProperties”: False — as shown in the official reference implementation (custom_plugins/custom_plugin.py) and in CloudDocs.
Impact: Custom analyzer plugins fail on every cycle, and the system never runs the weight calculation logic. The controller removes L4Route and HTTPRoute weight annotations, so traffic reverts to default round-robin. Dynamic AI load balancing fails entirely for all custom plugin deployments on BNK v2.3.x when the CR includes dynamicCapacityReduction.
Workaround: Set “additionalProperties”: True in PLUGIN_REQUEST_SCHEMA within the custom plugin ConfigMap (replace False). This change lets the plugin accept unknown fields without failing validation. If the plugin does not use it, the plugin ignores the dynamic_capacity_reduction field. After you update the ConfigMap, restart the analyzer pod: kubectl rollout restart deployment/f5-analyzer -n f5-bnk
2399937-9¶
IPSec ESP Traffic Processing Behavior
Component: CGN_ALG
Symptoms: Certain traffic conditions may cause a service interruption on the affected blade.
Impact: Traffic disrupted while TMM restarts.
2433669-1¶
DNS cache is not created when a local zone record contains double quotes
Component: dns-cache
Symptoms: The DNS cache is not created when a local zone record contains a value with double quotes, such as a TXT record.
Conditions: A local zone contains a record whose data includes double quotes.
Impact: The DNS cache creation fails, and the affected local zone records are not available through the DNS cache.
Fix Text: The system now correctly escapes double quotes in local zone record data when creating the DNS cache.
2549993-2¶
bdt_cli connection list does not filter by IP address
Component: dsc-bdt_cli
Symptoms: When bdt_cli connection list is run with –cs_client_addr, –cs_server_addr, –ss_server_addr, or –ss_client_addr, the command returns the full connection table instead of only matching flows.
Conditions: SPK/CNF/BNK deployments that use bdt_cli to match specific flow(s) by specifying address(es) for –cs_client_addr, –cs_server_addr, –ss_server_addr, or –ss_client_addr
Impact: The specified address does not take effect, and no flow filtering occurs. Instead, all flows are returned.
Fix Text: bdt_cli now respects the address parameters for –cs_client_addr, –cs_server_addr, –ss_server_addr, or –ss_client_addr and returns desired matching flows.
2493309-2¶
Redis sentinel failover and DB restart duplicate some entries
Component: dssm
Symptoms: Duplicate entries with empty values present in the same aux list.
Conditions: After a Redis Sentinel failover, DNS46 sub-record entries can reference the same key multiple times in the aux-list—and transiently leave it with an empty value, because add_script unconditionally appends to KEYS[2] on every retry. If replication splits the paired SET/RPUSH between the old and new primary keys, the next extry resets the value and appends the key again, which grows the aux-list without bound across failovers.
Impact: Duplicate entries with empty values present in the same aux list.
Fix Text: We make the aux-list append idempotent by calling LREM KEYS[2] 0 KEYS[1] immediately before LINSERT (eviction path) and RPUSH (non-eviction path) in add_script’s sub-record branch. Because the Lua script runs atomically on the primary key, the LREM+append sequence ensures the key appears exactly once in the list and self-heals any residual duplicates from prior failovers.
2456769-2¶
Gradual increase in TMM memory usage
Component: Firewall (ACL)
Symptoms: TMM memory usage shows gradual increases and does not go down when traffic stops. Memory usage for ACL allocation type shows the growth.
Conditions: CNF Deployment with Firewall policy containing “Drop” action rules.
Impact: Traffic disruption after TMM memory reaches threshold level.
Fix Text: Do not initiate Hardware offload for non DPU deployments.
2241045-3¶
ICMP monitor triggers pool member DOWN alarm after three non-consecutive failures
Component: fsm
Symptoms: An ICMP health monitor can transition a pool member to DOWN even when probe failures are not consecutive. In environments with intermittent packet loss, the monitor can mark the endpoint down after a single failed probe, even if successful probes occur between failures. With the default down threshold of 3, the sequence FAIL → OK → FAIL → OK → FAIL triggers a DOWN state instead of requiring three consecutive failures.
Conditions: Issue occurs when the default value of monitor DOWN threshold is set to 3 and
An ICMP health monitor is configured for a pool member.
Probe failures occur intermittently (e.g., due to packet filtering, network instability, or packet loss).
The system counts failed probes cumulatively rather than resetting the counter after successful probes.
Impact: Pool members trigger DOWN status even when the endpoint is reachable. This leads to incorrect pool member health state reporting.
Fix Text: Add a fail_count field to tma_activity. Reset fail_count on each successful probe and increment it by 1 on each failed probe. Transition the pool member to DOWN only after 3 consecutive failed probes.
2399969-2¶
DSSM pod performance degradation with multiple pool members down
Component: fsm
Symptoms: When you create a pool with a pool member and a monitor, every TMM in a TMM pod sends status updates to the DSSM each time the pool member’s state changes. This behavior can degrade performance, especially when many TMM pods contain multiple TMMs, causing the problem to scale rapidly.
Impact: Multiple TMM pods and TMMs writing to DSSM at the same time can create performance bottlenecks in the DSSM pod.
Workaround: Increase the CPU allocation for the DSSM pod to prevent write operations from overloading it. Alternatively, reduce the number of TMM threads, TMM pods, or both.
Fix Text: Fixed the DSSM limits. DSSM now writes to a single TMM in a given TMM pod instead of writing to all TMMs.
2358997-1¶
After BGP routing re-convergence ECMP routes can be incorrect
Component: fsm-dynamic-routing
Symptoms: In CNF environments, Equal-Cost Multi-Path (ECMP) routes learned from BGP may not be properly installed after routing changes or BGP session resets. This issue can result in:
Missing next-hop gateways in multi-path routes.
Incorrect number of paths displayed for ECMP routes.
Incomplete routing information on some pods.
The problem typically occurs when BGP neighbors re-establish connections or when routing topology changes trigger route updates, particularly in complex environments with multiple BGP peering relationships (eBGP and iBGP).
Conditions: Occurs when:
BGP routes are updated during network convergence events.
Multipath ECMP routes are in use.
Impact: Incorrect ECMP routes cause traffic loss.
Fix Text: Fixed ECMP nexthops to install correctly when routes change.
2359009-2¶
While using bdt_cli incorrect routeECMP routes are displayed
Component: fsm-dynamic-routing
Symptoms: The bdt_cli route command may not properly display Equal-Cost Multi-Path (ECMP) routes learned from BGP in Cloud-Native Network Function (CNF) environments.
Conditions: Display ECMP routes using ‘bdt_cli route’ command.
Impact: Incorrect output.
Fix Text: The bdt_cli route command now correctly displays ECMP nexthops in CNF environments.
2460921-3¶
Malformed tmctl --csv output from embedded commas in text columns
Component: fsm-libtmstat
Symptoms: Malformed Tmctl –csv outputs due to data within the table containing columns that are comma separated.
For example, when printing the table without the csv option: /tmctl -d blade tmm/xnet/device_probed id available_drivers driver_selected driver_in_use
xeth0 sock, dpdk, sock Yes 0000:d8:0e.2 sock, dpdk, dpdk Yes 0000:d8:13.7 sock, dpdk, dpdk Yes
/tmctl -d blade tmm/xnet/device_probed –csv id,available_drivers,driver_selected,driver_in_use xeth0,sock, dpdk, ,sock,Yes 0000:d8:0e.2,sock, dpdk, ,dpdk,Yes 0000:d8:13.7,sock, dpdk, ,dpdk,Yes
Due to the available_drivers being comma separated, there are double commas that causes the csv issue.
Conditions Running the tmctl command with the --csv or -c flag on a table that contains comma-separated values in a column produces malformed output.
Impact: Output of tmstat table columns are malformed when using –csv option.
Fix Text: Wrap comma-separated strings in tmctl --csv output in double quotes (eg: “val1, val2”) to follow the CSV format.
root@tmm-gcalvert-20260820-203915-8:/config# tmctl -d blade -i tmm/xnet/device_probed –csv id,available_drivers,driver_selected,driver_in_use xeth0,”sock, “,sock,Yes 0000:b1:11.3,”dpdk_mlnx, dpdk, iavf, “,dpdk,Yes 0000:b1:12.3,”dpdk_mlnx, dpdk, iavf, “,dpdk,Yes 0000:b1:14.0,”dpdk_mlnx, dpdk, iavf, “,dpdk,Yes
2455165-7¶
BIG-IP may experience increased resource usage under certain traffic conditions.
Component: fsm-protocols
Symptoms: Under certain conditions, protocol interactions may lead to a minor increase in BIG-IP memory usage.
Conditions: The virtual server is configured to handle the affected traffic.
Impact: Over time, BIG-IP may experience resource constraints that could affect traffic processing.
Fix Text: Issue is fixed.
2501773-1¶
NAT46/DNS64 translation entries expire during active use, causing intermittent connection failures
Component: ingress
Symptoms: When you enable DNS64/NAT46 on a virtual server, clients intermittently fail to connect to synthesized IPv4 addresses with a TCP reset (“No route to host”), even while they continuously resolve the domain and actively use the connection. These failures recur in multi-second windows tied to the configured DNS64/NAT46 TTL; outside these windows, connections succeed normally. During the failure window, DNS responses still show the mapping as valid with a non-zero remaining TTL, even as new connections to the translated address reset.
Conditions
DNS64/NAT46 is enabled on the virtual server (dnsNat46Enabled: true).
A client resolves an AAAA-only hostname through the NAT46 resolver and receives a synthesized A record.
The client keeps using that synthesized address continuously (repeated DNS lookups and/or ongoing data connections) for longer than the configured maxDNS46TTL.
Impact: Client applications that maintain long-lived or frequent connections to a DNS64/NAT46-synthesized address periodically encounter intermittent “No route to host” failures, even while continuously using the mapping.
Fix Text: Perform a “touch” on DNS queries to update the DSSM entry timestamp and refresh the NAT46 record. This synchronizes expiration so the DNS entry and NAT record expire together, preventing the DNS entry from outliving the NAT record.
2560921-1¶
F5ngress Helm install fails with release names over 36 characters
Component: toda_spk
Symptoms: If you use a release name longer than 36 characters (e.g., spk-automation-spk-operator-app-destination), the chart generates volume names that exceed Kubernetes’ 63-character limit, causing the installation to fail.
Conditions Install the ingress chart with a release name longer than 36 characters (e.g., spk-automation-spk-operator-app-destination).
Impact: When you use a release name longer than 36 characters, the f5ngress Helm chart generates a volume name that exceeds Kubernetes’ 63-character limit, causing the installation to fail. Helm reports: “spec.template.spec.volumes[44].name: Invalid value: “spk-automation-spk-operator-app-destination-f5-tmm-fluentbit-config”: must be no more than 63 characters.” The observer ConfigMap encounters the same issue.
Workaround: Shorten the ingress Helm chart release name to ensure the generated volume names (-fluentbit-config, -observer-config, -logs-config) stay within the 63-character Kubernetes limit.
Fix Text: Build a config map/object name that fits within Kubernetes’ 63-character limit without collisions: truncate only the base (tmm.name), always preserve the descriptive suffix, and append a short deterministic hash of the full name for uniqueness when truncation is required.
Known Issues¶
IPAM issues¶
2284409-6¶
No automatic reassignment of freed IPs to failed gateways
Component: IPAM
Symptoms:
When the IP pool is exhausted, new Gateway resources fail to obtain an IP address.
When a Gateway is deleted and its IPs are freed, the IPs are not automatically reassigned to Gateways that previously failed due to IP exhaustion.
Conditions: Occurs when:
The IP pool is fully exhausted.
Multiple Gateway resources fail due to lack of available IPs.
An existing Gateway (with a successfully allocated IP) is deleted, freeing an IP.
Impact:
Gateways that failed due to IP exhaustion remain failed.
IP allocation isn’t automatically retried for affected Gateways.
Manual intervention is required to recover.
Workaround: To allocate an IP to a Gateway that failed due to IP exhaustion:
Delete the affected Gateway resource.
Recreate the Gateway resource.
This triggers a new IP allocation attempt, allowing the system to assign any available (freed) IP.
2284329-3¶
The F5BnkGateway CR does not support multi-tenancy when using Infoblox IPAM integration
Component: IPAM
Symptoms: Multi-tenancy is not supported with the current f5-bnkgateways CRD. Defining the same network in multiple NetViews within a single F5BnkGateway resource does not work as expected.
Conditions: The f5-bnkgateways CRD is configured with:
The same network (CIDR or subnet)
Multiple NetViews intended to represent different tenants.
Impact:
Gateway configuration can fail or act unpredictably.
IP allocation and network mapping across NetViews may not be resolved correctly.
Workaround:
Do not configure multiple NetViews for the same network in a single F5BnkGateway resource.
Use one NetView per network.
f5ingress issues¶
2288497-7¶
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.
2288133-2¶
Controller does not validate F5SPKEgress CR with incomplete PseudoCNI configuration
Component: ingress
Symptoms: F5SPKEgress CR status is set to true.
Conditions: F5SPKEgress CR applied with incomplete fields, or missing create: true in vxlan section.
pseudoCNIConfig:
vxlan:
vrf: red
Impact: As the CR status becomes true, user might be in an assumption that CR is valid.
Workaround: This can be mitigated by having a valid F5SPKEgress CR.
apiVersion: k8s.f5net.com/v3
kind: F5SPKEgress
metadata:
name: egress-cr-primary-vxlan-1000
spec:
dualStackEnabled: true
snatType: SRC_TRANS_SNATPOOL
egressSnatpool: egress-snat-vx1000
egressSnatpoolMode: SHARED_SNAT_ADDRESS_FLOW_FORWARD
egressSnatpoolFlowForwardVlan: f5-vlan-client-2002
egressSnatpoolProtectionEnabled: false
pseudoCNIConfig:
namespaces:
- spk-app-4
appPodInterface: eth0
vxlan:
create: true
tmmInterfaceName: f5-vlan-egress
nodeInterfaceName: spk-ms
mtu: 1460
port: 4789
key: 1000
vrf: red
2284989-3¶
CNE controller stuck in pending state due to lack of resources
Component: ingress
Symptoms: CNE controller is not deployed on primary node and remains in pending state due to lack of resources.
Conditions: BNK deployed on DPF where the primary nodes have less vCPUs available.
Impact: CNE controller is not deployed on primary node and remains in pending state due to lack of resources.
Workaround: The BNK non-dataplane components (CP, DSSM, and TODA) require approximately 12 vCPUs. The cluster must allocate sufficient resources to accommodate this requirement. Primary nodes should provide at least 12 vCPUs for BNK control plane components, in addition to the resources required for the DPF framework.
2289809-3¶
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.
2217709-3¶
Kernel routes are not displayed in OcNOS when the tmm-routing container has crashed
Component: ingress
Symptoms: Kernel routes are not displayed in OcNOS when the tmm-routing container has crashed.
Conditions: BNK is deployed with OcNOS. After BGP kernel routes are established, the tmm-routing container either restarts or crashes.
Impact: Traffic is affected following the restart of the tmm-routing container, which occurred due to the absence of BGP kernel routes.
Workaround: Restart the TMM pod when this condition is detected.
Egress issues¶
2390145-6¶
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.
2183833-6¶
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.
2035637-4¶
Traffic drops in egress traffic during upgrade from 2.0.2 to any higher version
Component: egress
Symptoms: During rolling upgrade of TMMs, some egress connections are dropped because the OVN routes to the old TMM are not removed as soon as old TMM is down. Whenever readiness gates are ready on the new TMM, the old TMM immediately goes down. But as the OVN route to old TMM still exists for 7-8 seconds, some connections are sent to the old TMM through the invalid route are dropped.
Conditions:
Rolling upgrade from BNK 2.0.2 to any higher version.
BFD is enabled on both ingress and egress.
Running both ingress and egress traffic.
Impact: Some traffic is disrupted during the rolling upgrade.
2188365-4¶
Egress packets dropped when forwarded to TMM after self IP removal
Component: egress
Symptoms: The device drops egress traffic when it forwards packets to TMM after removing the self IPs.
Conditions: Occurs when:
Traffic flows when packets go to TMMs that have self IPs.
The application pod sends egress traffic to the TMM.
Delete the existing vlan.yaml and update it to remove some internal VLAN self IPs.
Impact: Egress packets are distributed to TMMs whose self-IPs have been removed. Because those TMMs have no self-IP to source the traffic, the packets are silently dropped instead of being redirected to a TMM that can forward them. The expected behavior is that traffic is never steered to a TMM lacking a self-IP. The result is intermittent packet loss and connection failures on egress, with no error surfaced to explain the drops.
Workaround: Wait a few minutes until OVN deletes the routing entries to TMMs without self IPs.
2284437-6¶
Egress failure with multiple TMM pods in a single AZ
Component: egress
Symptoms: The application pod could not send the egress traffic to the outside cluster.
Conditions: Occurs when:
Create a 6-node cluster.
Enable the label on 5 nodes for f5-tmm and 1 node with app node label.
Create the CRs, such as snat, egress, and static route to the destination
Install the app pod and send the traffic.
Impact: Egress traffic does not work when multiple TMM pods are deployed in a single availability zone.
Workaround: None
GSLB issues¶
2130325-6¶
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.
2264981-4¶
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.
2277417-4¶
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-5¶
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-4¶
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¶
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-4¶
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-4¶
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-5¶
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
Other issues¶
2330929-1¶
ACL hardware stats 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.
2284337-4¶
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.
1823977-5¶
Logs for TMM container is unavailable through console output when fluentbit container is enabled in TMM pod
Component: toda_logging
Symptoms: When the fluentbit container is enabled for the f5-tmm pod, the f5-tmm container logs will not be outputted to the console. However, the f5-tmm container logs can still be found in the f5-toda-fluentd pod (located under /var/log/f5).
Conditions: fluentbit container is enabled and running in the f5-tmm pod.
Impact: F5-tmm container logs will not be outputted through console and can only be found in the f5-toda-fluentd pod.
Workaround: The f5-tmm container logs can still be found in the f5-toda-fluentd pod (located under /var/log/f5).
2201321-4¶
BGP EVPN Type-5 routes remain advertised after VXLAN CR deletion
Component: fsm-networking
Symptoms: BGP EVPN Type-5 routes continue to be advertised after VXLAN CR deletion.
Conditions: After a VXLAN CR is deleted (which removes the VTEP IP from TMM), OcNOS automatically re-establishes BGP EVPN neighborship after approximately 5 minutes and continues to advertise stale Type-5 EVPN routes using the last known MAC address. The routes reference a non-existent VTEP IP that no longer exists on TMM, even after clearing BGP sessions with clear bgp *.
Impact: Data path failure due to routes pointing to non-existent VTEP IPs, stale Type-5 EVPN routes remain advertised to peers and network traffic may be black-holed or misrouted.
Workaround: Delete and re-create the VRF (RoutingConfig) associated with the VXLAN. If the VXLAN has already been removed from the system, the Routing CR will not be applied because its dependent VXLAN CR no longer exists; therefore, the reported issue will not arise. Alternatively, you can remove the route-target configuration from the VRF to prevent route advertisement.
2277685-4¶
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.
2287989-4¶
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
2208493-4¶
BGP advertises denied VIP subnet to peer router when using route-map with deny prefix-list
Component: fsm-networking
Symptoms: When a virtual IP (VIP) that belongs to a subnet configured as “deny” in the BGP route-map prefix-list is used to bring up an app, the VIP /32 route is still advertised to the BGP peer router. As a result, the denied IPv4 prefix (for example, 192.168.17.0/24) is unexpectedly visible as a host route on the peer router, even though it is listed under an IP prefix-list with a deny rule on the TMM side.
Conditions: BNK/TMM running with BGP enabled and advertising routes through a route-map.
An IP prefix-list is configured to deny a subnet used for VIPs, for example:
ip prefix-list vipothernet seq 13 deny 192.168.17.0/24 le 32 ipv6 prefix-list denyipv6net seq 15 deny fd79::/64 le 128
The deny prefix-list is referenced in the outbound BGP route-map, for example:
route-map labnetroutemap permit 13 match ip address prefix-list vipothernet route-map labnetroutemap permit 15 match ipv6 address prefix-list denyipv6net
An application is configured with a VIP inside the denied prefix, for example:
destinationAddress: 192.168.17.10 ipv6destinationAddress: fd79::67
Impact: Routes for VIPs that should be excluded from BGP advertisement are still learned and installed on the peer router. Potential for unintended routing and traffic steering to VIPs that operators explicitly attempted to prevent from being advertised. May lead to policy and compliance violations in environments relying on BGP prefix-lists to enforce route advertisement boundaries.
2389713-2¶
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.
2389797-7¶
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.
2368573-7¶
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.
2391145-8¶
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.