CNF Fixes and Known Issues¶

This list highlights fixes and known issues for this CNF release.

Fixed issues¶

2368509-6¶

Title: Coremond may write core files to ‘unknown’ when pod or container names mismatch

Component: toda_coremon

Symptoms: Renaming a pod causes coremond to write the pod’s core files under /var/cores/<node>/unknown/ instead of the expected namespace directory because the configuration file mis-maps the pod and container names. This is a known issue in CNF 2.2.0. In CNF 2.3.0 and later, coremond no longer uses that configuration file, so the issue does not occur.

Conditions: This occurs when the pod name or Helm release name differs from the actual container name and the configuration file cannot accurately map the renamed pod name and the container name.

Impact: The core files generated by a pod are written under /var/cores/<node>/unknown/ instead of the expected namespace directory.

Workaround: Customize the configuration file to explicitly provide the process-to-container mapping, for example:

pods:
  l1s6svcgtm:
    containers:
      tmm.0: f5-tmm

Fix Text: Customize the configuration file to explicitly provide the process-to-container mapping, for example:

pods:
  l1s6svcgtm:
    containers:
      tmm.0: f5-tmm

2330525-5¶

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.

2368565-4¶

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.

2389165-3¶

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

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

2440693-1¶

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.

Known issues¶

2302053-3¶

Title: Core File Streaming Supported from CNF 2.3.0 and higher

Component: toda_coremon

Symptoms: Initially core files were written to host volume. hostPath presents limitations in security, and flexibility, especially in cloud-native environments. In CNF 2.3.0 we introduced the streaming functionality to address this. For full feature documentation, see https://clouddocs.f5.com/cnfs/robin/latest/cnf-coremond.html. This feature is not supported in releases CNF 2.2.0 and lower.

Conditions: Streaming=false

Impact: 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-4¶

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.

Previous Next