Fixed and Known Issues¶
Fixed Issues¶
Bug ID: 2162233
Title: DNS46 Egress iRule duplicate entries
Symptoms: In DSSM, while mapping IPv6 to IPv4 multiple entries exist for the same ipv4 address.
For example, DSSM may have the following entries:
- IPv4->IPv6 1.1.1.1 ==> 2001:db8::2 (New mapping for 2001:db8::2, overwrites existing 1.1.1.1 ==> 2001:db8::1 entry)
- IPv6->IPv4
2001:db8::1 ==> 1.1.1.1
2001:db8::2 ==> 1.1.1.1 (Multiple entries of IPv6 to same IPv4 address. In future traffic originating from 2001:db8::1 goes to 2001:db8::1)
Conditions: Rapid concurrent DNS queries resulting in simultaneous IPv4 to IPv6 allocations in DSSM can trigger race condition where the same IPv4 address is allocated for multiple IPv6 to IPv4 mappings.
Impact: Network traffic will be routed back to the wrong client.
Mitigation / Workaround: Creating static mappings avoid dynamic allocation entirely, or an automation script to manually remove duplicate entries.
Fix Text: Resolves collision of allocation, with an atomic test and set to verify that the IPv4 address has not been allocated for a mapping already.
Bug ID: 1781893
Title: F5SPKIngressTCP custom resource status remains unchanged when referenced VLAN custom resource is deleted
Symptoms: F5SPKIngressTCP custom resource does not change its status to ‘WAITING’ when the referenced VLAN custom resource is deleted.
Conditions: When you configure the F5SPKIngressTCP custom resource with one or more VLANs and their corresponding VLAN custom resources, the status of the F5SPKIngressTCP custom resource should change to “WAITING” if:
- Any of the specified VLAN custom resources are missing.
- Any of the VLAN custom resources that were initially set up are later removed.
However, in the second scenario, the status remains incorrectly reflected as “SUCCESS” instead of switching to “WAITING.”
Impact: You do not receive appropriate feedback regarding the missing child custom resource; however, there is no traffic disruption once the VLAN custom resource is restored.
Mitigation / Workaround: None
Fix Text: The status of the F5SPKIngressTCP CR must be updated to reflect changes in the statuses of its referenced CRs.
Known Issues¶
Bug ID: 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.
Mitigation / Workaround: Delete and reapply CR.