Fixed and Known Issues

This page lists the issues resolved in this release as well as known issues that have not yet been resolved.

Fixed Issues

2389165-4

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: 1. Usage of show running-config should be restricted or reduced (e.g., avoid frequent/scripted polling). 2. Frequent restarts of the imish process should be performed to reclaim the leaked memory. 3. Restart TMM pod or only the tmm-routing container.

Fix Text Fixed a memory leak in the imi configuration module by releasing the internal patricia-tree structure allocated for each configuration mode when the mode is freed. The updated cleanup path now properly frees this structure, preventing leaks during repeated “show running-config” and related config-mode operations.

2377749-5

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.

2330525-6

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.

2368565-3

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.

Known Issues

2331757

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, 1. A Kubernetes service (ClusterIP: None) is configured. 2. The service has no pod selector (Selector: none), and endpoints are managed manually via an Endpoints object (external service pattern). 3. An F5 SPK CR (UDP, TCP, HTTP2, etc.) references this service as a backend.

Impact F5ingress does not program the virtual server configuration into TMM. As a result, TMM does not forward traffic to the intended pool member. The CR status incorrectly reports SUCCESS, obscuring the failure.

Fix Text The fix checks whether the Kubernetes Service referenced by the F5SPKIngress CR is selector-less because if it has selector then Kubernetes is managing the backend endpoints automatically. If the Service has no selector, f5ingress treats its endpoints as manually managed and skips the call that generates pool member ARPs and static routes. This prevents creation of a static_route for external endpoint IPs that do not map to any Kubernetes node. The remaining TMM configuration is generated and sent normally.

2295433

Title CR status update failure under high queue load and slow event handlers

Symptoms CR status remains stuck at DEPLOYING even after TMM is configured.

Conditions When event handlers are slow and has high queue load, the informer cache becomes outdated relative to the API server state. As a result, CR status updates frequently encounter version conflicts and eventually fail after exhausting retries, causing CR status to remain stuck in the DEPLOYING state.

Impact The status update has failed; the CR status remains stuck at DEPLOYING indefinitely, despite the configuration being successfully deployed to TMM.

Workaround Delete and reapply CR.

2368573-3

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.