BIG-IP Next for Kubernetes Known Issues¶
This list highlights the known issues for the current BIG-IP Next for Kubernetes release.
1855465-1¶
Deletion and re-creation of GatewayClass and HTTPRoute CRs results in associated Gateway CR get into an error state.
Component: Ingress
Symptoms:
When the GatewayClass and HTTPRoute CRs are deleted and re-created, the associated Gateway CR gets into an error state.
Conditions:
This issue is found when the GatewayClass, Gateway, and HTTPRoute CRS are initially applied, and later, the GatewayClass and HTTPRoute CRs are deleted and re-applied.
Impact:
Traffic will be disrupted because the data plane cannot be configured when the Gateway CR becomes non-functional.
Workaround:
Delete and re-apply the Gateway CR along with the GatewayClass and HTTPRoute CRs.
1856741-1¶
F5SPKVlan CRD has two separate name fields which leads to confusion.
Component: Ingress
Symptoms:
VLAN CRD has two name fields defined as:
metadata.name
spec.name
Conditions:
This issue occurs when the two name fields of the VLAN CRD metadata.name and spec.name are nested just under metadata.
Impact:
The presence of two separate name fields in the F5SPKVlan CRD can lead to confusion, as it is unclear for the user to know which field takes precedence. Additionally, if different names are provided in the two fields, it may result in failed configurations.
Workaround:
It is recommended to use the same value for both name fields to avoid confusion and ensure proper configuration.
1890057-1¶
Egress traffic gets disrupted when VLAN IPs are modified during runtime.
Component: Ingress
Symptoms:
When all internal and external self-IPs are modified in the VLAN CR while traffic is flowing, Ingress traffic resumed and Egress traffic did not.
Conditions:
This issue occurs when internal and external VLAN self-IPs are modified in a system where both Ingress and Egress traffic is flowing.
Impact:
The Ingress traffic resumed and the Egress traffic did not resume.
Workaround:
Delete and apply the Egress CR as modifying the VLAN IPs at runtime is disrupting the Egress traffic.
1849317-1¶
VXLAN key modification is not supported in the Egress CR.
Component: Egress
Symptoms:
Modifying the VXLAN key does not work, though the Egress CR accepts modification.
Conditions:
After applying the Egress CR, if the admin changes the VXLAN key, the changes will not take effect.
Impact:
Modifying the VXLAN key after applying the Egress CR does not work even if the Egress CR accepts.
Workaround:
Delete and re-apply the Egress CR when modifying or updating the VXLAN key in the Egress CR.
1854169-1¶
Internet Egress traffic from application pod out of cluster may route incorrectly through the TMM.
Component: Egress
Symptoms:
If the application pod is scheduled in a namespace with an egress CR, internet traffic from the application pod may go through the TMM eth0 interface.
Conditions:
This issue occurs when:
The application pod is running in the namespace, which has egress CR applied.
Internet traffic is allowed from the TMM eth0 interface.
Impact:
Internet traffic flows through the TMM, which may slightly degrade the performance of the TMM.
Workaround:
One of the work-arounds is to apply a default static route to a different destination. For example, an upstream router (in this case, the client) is allowed to access the internet through an upstream router, or set the destination to blackhole (or invalid destination).
1881269-1¶
Egress traffic does not work when the Virtual Function (VF) is configured after SPK deployment.
Component: Egress
Symptoms:
Egress traffic is not working when traffic is sent from the application pod.
Conditions:
The Egress traffic does not work when any of the following conditions are met:
The VF connecting to pf1vf0 is initially in DOW state.
When an FLO is deployed.
Egress, VLAN, and SNAT CRs are applied.
The VF is in UP state.
Impact:
Egress traffic will not work as the VXLAN tunnel is not created between the TMM and the host where the application pod has been deployed.
Workaround:
Restart the CSRC pod on the host where the VF state has been changed from DOWN state to UP state.
1889409-1¶
Irrelevant warning messages appear in the TMM logs during ingress traffic flow.
Component: fsm
Symptoms:
Irrelevant warning messages may be logged in the TMM logs when ingress traffic is flowing.
Conditions:
When a Gateway API HTTPRoute is applied while the ingress HTTP traffic is flowing.
Impact:
The warning log messages are harmless, but a few are generated for each HTTP request processed by the TMM. Under high traffic loads, this can result in a significant number of log messages being produced.
Workaround:
Set TMM_LOG_LEVEL custom environment to ERROR state.