Last Modified: Jul 15, 2026
Affected Product(s):
BIG_IP_NEXT(BNK) BNK
Known Affected Versions:
2.1.0, 2.1.1
Opened: Jul 21, 2025 Severity: 3-Major
UUID Fails To Restore After f5-tmm Container Kill Run the following command on debug container of the TMM pod 'configview uuid <pod name>' The output should display the device name, TMM count information if it is an active TMM and VLAN CRs are configured. An active TMM means a TMM with VLAN and self-IP configurations. All TMMs are considered active if the minimum number of self-IPs across all VLAN CRs matches the number of TMM pods. If the number of TMMs exceeds the minimum number of self-IPs across all VLAN CRs, the additional TMMs will be identified as standby TMMs.
No Impact Scenario If only one TMM has a missing UUID and all TMMs are active, there is no impact. Possible Error Scenarios If multiple TMMs have missing UUIDs or there are standby TMMs, followed by an F5Ingress controller restart, there is a potential risk of duplicate self-IP
Set-1 1. TMM process crashes, leading to a restart of the TMM container. 2. This is immediately followed by a restart of a non-TMM container. Set-2 Network issues or the TMM rejecting the UUID configuration because it is busy when the controller attempts to send the UUID config.
If the SPK watchdog is deployed, it can monitor TMMs for missing UUIDs and restart the affected TMM. If no watchdog is present, manually restart the TMM that is missing its UUID when it is expected have it. In cases of duplicate self-IPs, restart the TMMs having duplicate self-IPs.
None