Cloud-Native Network Functions on OpenShift 2.3.0 release notes

About this release

Introduction

These release notes describe the differences between CNFs on OpenShift 2.2.1 and 2.3.0.

Supported container-orchestration platforms

This release is officially supported on these container-orchestration platforms and versions:

Platform	Version	Recommended Helm version
OpenShift	4.14	3.15
OpenShift	4.16	3.17
OpenShift	4.18	3.19

Security updates

(No security updates)

New features

Crash Agent – RobinIO

This feature introduces a streaming-based ingestion model that enables pod-generated core files to be collected without host-level access.

Benefits

• Better customer experience and operational resilience.

• Reduced operational complexity and support for restricted clusters.

Subscriber Policy mgmt – Gx

The Gx interface serves as a vital connection between the PCRF (Policy and Charging Rules Function) and the CNF for enforcing network policies. The PEM CNF is designed specifically for mobile service providers to efficiently manage and control subscriber traffic. It achieves this by analyzing traffic patterns and subscriber behavior to provide actionable insights. The PEM CNF implements advanced traffic policing rules, such as blocking web traffic from specific IPs, applying QoS via DSCP marking, redirecting HTTP traffic to designated URLs, and optimizing video streams—all of which ensure improved network efficiency and enhanced user experience.

Benefits

This feature deliver scalability tailored for 5G and provide advanced capabilities to enhance traffic policing and optimized subscriber traffic management.

MRFDB and PEM Sessions

TODA infrastructure aggregates statistics across multiple pods, addressing the current per-pod stats limitation of PEM. This enables presentation of TMM POD statistics as a unified aggregate, enhancing visibility and simplifying monitoring for customers. Additionally, the CNF supports improved session and subscriber visibility, leveraging dSSM and sessionDB to provide detailed insights. With tools like the pem_sessiondump command, customers can efficiently query subscriber information using versatile options. This ensures streamlined data access and operational clarity.

Benefits

This feature provides improved reporting capabilities and operational efficiency, empowering customers to make informed decisions quickly. It simplifies the process of tracking and analysing network performance across multiple pods and environments through centralized metrics.

Subscriber-aware policy enforcement using NetSTAR URL filtering and Gx integration

This feature provides integration with NetSTAR, a leading provider of traffic categorization, enabling the CNF to analyze and classify network traffic effectively. Additionally, the CNF integrates seamlessly with PCRF over the Gx interface, enabling dynamic policy application for advanced network management.

Benefits

This feature creates new monetization opportunities for service providers while ensuring compliance with regulatory requirements. Additionally, the CNF provides robust content control and filtering capabilities, empowering service operators to enforce policies effectively. This enhances both operational efficiency and user satisfaction.

Add dig to netkvest for debugging using SNAT IP

This feature provides diagnostic capabilities by extending the netkvest utility to support dig commands for testing DNS connectivity on the egress path. Using SNAT IPs, the tool enables comprehensive testing of all DNS record types over both UDP and TCP protocols, ensuring reliable DNS troubleshooting. This enhancement complements the existing ping and traceroute utilities, providing a robust suite of network diagnostic tools.

Benefits

This feature empowers service providers with tools to simplify troubleshooting and reduce downtime and operational complexity, ensuring seamless network operations. As a result, service providers can deliver an enhanced user experience through reliable connectivity and optimized performance across dynamic network environments.

NX domain DDoS

This feature provides a configurable option in the DoS NXdomain Vector to address scenarios where external DNS proxies, like Google DNS resolvers, may misinterpret silent drops as health issues with the DNS server. Instead of silent drops, the mitigation action now sends NXdomain replies, ensuring backend server protection without forwarding requests to the origin server or pool. This feature is designed for the Global DoS Context.

Benefits

This feature enhances network security posture through effective DoS attack mitigation, maintaining reliability and safeguarding critical infrastructure during high-traffic scenarios.

Enhanced Load Balancing Capabilities

This feature provides load-balancing capabilities over IPv4 and IPv6, incorporating functionality such as iRules, SNAT configuration, persistence profiles, and protocols like TCP, UDP, FastL4, HTTP, and HTTP/2. Security and traffic optimization are further enhanced with ClientSSL, ServerSSL, and GenericMSG profiles, while monitoring capabilities include ICMP, TCP Half-Open, DNS, and HTTP checks. Additionally, BGP and Route Domains are supported.

Benefits

Cloud-native transformation for telecom and non-telecom workloads by making network load balancing seamless both inside and outside Kubernetes clusters. CNF enhances operational efficiency while supporting the evolving demands of modern telecommunications environments.

Limited Availability/Early Access

Note

F5 provides Early Access feature documentation on request; contact your F5 account team.

BBRV2 Congestion Control

BBRv2 TCP congestion control optimizes network performance in scenarios involving congestion, packet loss, and high latency, significantly enhancing user experience and overall network quality. It provides more balanced traffic management to improve network efficiency and fairness.

Benefits

It reduces network congestion, delivering greater customer satisfaction and retention through improved connectivity. This helps optimize network performance in dynamic mobility environments and empowers service providers to handle evolving demands efficiently while maintaining high-quality service delivery.

DNS Global Server Load Balancing (GSLB)

This feature introduces load-balancing capabilities to optimize traffic distribution across geographical server locations. Load balancing methods such as Round Robin, Ratio-Based Load Balancing, and Global Availability are supported. Monitoring supports HTTP, HTTPS, ICMP, TCP, UDP, and TCP-Half-Open protocols to check server health and performance, enabling precise and reliable traffic management across diverse network environments.

Benefits

This feature enables the ability to distribute and direct traffic across multiple locations, including data centers and cloud environments, based on user-defined parameters and traffic management rules.

DNS GSLB Sync Groups

The GSLB introduces a Sync Agent mechanism to streamline configuration management within sync groups. This feature handles all configuration operations, including create, read, update, and delete (CRUD) actions across group members. Non-sync agent instances actively reject configuration attempts, preventing “Sync storms” and ensuring operational stability within the system. Furthermore, the Sync Agent election is flexible and can be changed at any moment, providing adaptability and enhanced control for efficient traffic management in dynamic environments.

Benefits

The ability to create a sync group with two or more GSLB instances delivers significant business value to enhance reliability, scalability and efficiency of traffic management across distributed systems.

DNS GSLB Topology LB

The Topology Load Balancing (LB) method enables advanced DNS query distribution based on geographical information and weighted scores in topology records. The Topology LB method for a Wide IP or GSLB pool ensures optimized traffic routing by directing DNS queries to the closest virtual server, enhancing response times and user experience.

Benefits

This feature enables traffic to be directed to the closest server based on geographical proximity, improving response times and user satisfaction.

ACL and NAT policy for VRF

The CNF now supports VRF configuration through CRD. Firewall ACL policies and CGNAT policies can be configured for specific VRFs or across multiple VRFs, allowing granular control over traffic flows. Additionally, VRF-aware VLAN and Secure Context functionalities have been enhanced to use VRF-aware destination addresses.

Benefits

This feature enables more flexible network management within containerized environments, empowering administrators to dynamically control and optimize network configurations. This ensures seamless integration and provides robust support for multiple VRFs, making it ideal for handling complex networking scenarios in evolving environments.

MPLS Support

The CNF is designed to function as a Provider Edge (PE) to support MPLS in BGP-LU mode, enabling efficient label-switched routing for dynamic environments. The CNF handles MPLS VPN labels (inner) and transport labels (outer) for packet forwarding across the network. Security policies such as ACL, CGNAT, and DDoS mitigation can be applied based on VPN labels, enhancing protection at multiple layers. The CNF also addresses overlapping addresses in MPLS traffic using CGNAT.

Benefits

The CNF delivers increased network flexibility and improved management capabilities for complex network environments, empowering administrators to efficiently handle dynamic configurations. It provides optimized and secure data flow and offers a comprehensive solution for scalable and resilient network operations.

Model changes

(No model changes)

Fixed issues

2261045-2

CNE controller not using new certs after root CA update

Component: ingress

Symptoms: CNE controller fails to use the new certificates after the root CA is updated.

Conditions: After the Root CA update and reissued certs, TMM’s certificate chain uses a different root CA than the controller’s.

Impact: GRPC communication fails, TMM is not configured.

Workaround: Restart the controller.

Fix Text: Improve TLS error handling, to refresh certs in cases where Root CA mismatch is the reason for failed communication.

2201925-2

Unable to use pre-created ServiceAccount: f5ingress missing controller.serviceAccount.create override

Component: ingress

Symptoms: The f5ingress chart does not support the controller.serviceAccount.create override. As a result, pre-created ServiceAccounts cannot be used with helm install.

Conditions: Pre-created ServiceAccounts with helm install.

Impact: ServiceAccounts not configured as needed.

Fix Text: To use pre created service account set create flag in override file to false and give name of pre created SA.

For example:

        ```yaml
        serviceAccount:
        create: false
        name: f5ingress-sa
        ```

2196869-1

Configuration updates to spec.snat and spec.loadBalancingMethod in F5SPKIngressTCP CR are not reflected in virtual server

Component: ingress

Symptoms: Change spec.snat or spec.loadBalancingMethod by editing the F5SPKIngressTCP CR (using) does not reflect in the virtual server configuration.

Conditions: Using oc/kubectl edit the F5SPKIngressTCP CR fields:

• spec.snat

• spec.loadBalancingMethod

Impact: Changing the existing F5SPKIngressTCP CR spec.snat or spec.loadBalancingMethod does not take effect.

Workaround: Completely delete the existing resource and create a new resource with the updated parameter values.

2217405-2

F5SPKIngressHTTP2 allows multiple custom resources with duplicate destinationAddress:destinationPort combinations

Component: ingress

Symptoms: Multiple virtual servers created via different F5SPKIngressHTTP2 CRs exist with the same destination IP:port pair Different TMM instances may enable different virtual servers from the duplicate configurations, resulting in inconsistent responses.

Conditions:

• Multiple F5SPKIngressHTTP2 Custom Resources (CRs) are configured with identical destinationAddress and destinationPort values.

• Each CR points to a different Kubernetes service with different pool member counts.

• The controller creates separate TMC (traffic_matching_criteria), address_list, and port_list objects for each CR.

• Both CRs use the same traffic matching criteria (ip_proto:6 TCP, same destination IP and port).

Impact:

• Unpredictable behavior: Requests to the same virtual IP:port may be handled by different virtual servers depending on which TMM instance processes the traffic.

• Inconsistent application responses due to different backend pool members being selected.

• Race condition during TMM startup determines which virtual server becomes active on each TMM instance.

Workaround:

• If duplicate CRs are discovered, delete one of the conflicting CRs and verify that the associated TMM configuration is properly cleaned up.

• Monitor TMM configuration using tmctl commands to identify duplicate virtual servers: kubectl exec -it -c debug – tmctl -d blade virtual_server_stat -s name,destination,conf_status.

• Check for duplicate address_list and port_list entries using configview show address_list and configview show port_list.

2263137-2

Path-slice extraction on long URIs may cause TMM exit

Component: fsm-hudfilters

Symptoms: TMM can crash when a request’s URI path exceeds the xbuf MSS and a rule compares a path slice (a subsection of the URI path).

Conditions: When an administrator configures an iRule, ServiceBasedInterface static route, or TDR filter to compare a URI path “slice” (subsection) and the path exceeds the MSS, issues can occur. A slice is specified with the Path pseudo-header (:p) plus the slash-delimited segment range; for example, :p:s3-5 selects the 3rd–5th path segments.

Impact: Incorrect code branch causes TMM termination.

Fix Text: Path-slice comparisons behave correctly for any URI path length.

2260901-1

Prehook job fails on all-tainted-node clusters during BIG-IP install

Component: fsm-networking

Symptoms: When running kubectl get jobs -n <namespace>, the prehook job is stuck in a running state with no containers launching. The tolerations property on TMM does not work as expected for the prehook job.

Conditions: Installing BNK on a cluster with tainted nodes and with add_k8s_routes.

Impact: Installation may fail on clusters with tainted nodes. The tolerations property on TMM does not work as expected for the prehook job.

Fix Text: The TMM tolerations are now correctly applied to the TMM prehook job.

2199489-1

Misconfigured hslpool prevents static routes on scaled-up TMM pods

Component: HSL

Symptoms: A misconfigured F5BigLogHslpub CR—syslog pointing to a non-existent pool—was accepted by the controller and saved to the gRPC replay cache. When a new TMM pod started, the replay included this invalid HSL, halting the config batch and leaving the pod without static routes, iRules, and other configurations.

Conditions: A misconfigured F5BigLogHslpub CR.

Impact: Static routes are not populated to scaled-up TMM pods.

Fix Text:

• Implemented CEL-based x-kubernetes-validations at the spec level in f5-hslpub_v2.tmpl.yaml.

• Set maxItems: 64 for the pool[], syslog[], and ipfix[] arrays to stay within the CEL cost budget.

• Invalid HSL CRs are now rejected by the API server admission controller, preventing them from entering the gRPC replay cache and avoiding config batch halts on new TMM pods.

Known issues

DSSM issues

2130325-1

Title: GSLB virtual server health monitors don’t recover after GSLB Engine pod restart in Sync Group with a large number of monitor instances

Component: dssm

Symptoms: In GSLB Sync Groups with a high volume of health monitor instances (approximately 2,000 or more), certain virtual servers may persistently display a “no reply from probe-agent: timed out” health status following a GSLB Engine pod restart. These virtual servers do not recover to their correct health status, despite the underlying servers and monitors operating as expected.

Conditions: A GSLB Sync Group comprising three or more members is configured with a significant number of health monitor instances (for example, 50 HTTP and 50 ICMP monitors per generic host, with 10 or more virtual servers—totaling approximately 2,000 monitor instances). Subsequently, one or more GSLB Engine pods within the Sync Group are restarted (that is, scaled down and then back up).

Impact: Following a GSLB Engine pod restart, some virtual servers consistently report an incorrect health status (“no reply from probe-agent: timed out”), despite the monitors functioning as expected. As a result, GSLB DNS load balancing excludes healthy virtual servers from DNS responses, leading to suboptimal traffic distribution.

Workaround: To resolve this issue, simultaneously restart all GSLB Engine pods across every member of the Sync Group by scaling all GSLB Engine deployments down to zero replicas. Wait for all pods to fully terminate before scaling the deployments back up to one replica. If the problem persists after restarting the engines, re-create the GSLB Sync Group. To do this, remove all GSLB custom resources (CRs), beginning with the GSLB Local Instance CRs at each deployment, and then reapply them.

2287989-1

Title: DSSM Pod may restart if you add over 250k subscribers with GX at 1k rate

Component: dssm

Symptoms: Adding over 250k known subscribers with GX at a 1k rate may cause DSSM Pod restarts if the dssm-db container lacks enough resources.

Conditions: DSSM db container is not allocated with enough resources.

Impact: The DSSM Pod restarts and will impact the subscriber addition.

Workaround: Allocate at least 8 CPUs and 45GB memory for the DSSM DB container and set PVC to 45G for dssm-db pods. When deploying dssm-db pods, please specify these values in overrides file :

```yaml
db:
persistent_storage_gb: 45
resources:
    limits:
        cpu: "8"
        memory: 45Gi
    requests:
        cpu: "8"
        memory: 45Gi
```

2264981-1

Title: Cross-cluster MDSSM communication fails if network routing is not set up for MDSSM pods

Component: dssm

Symptoms: When GSLB Sync Group is deployed with MDSSM enabled across two or more clusters, MDSSM pods in one cluster are unable to communicate with MDSSM pods or GSLB pods in the other cluster. The cross-cluster MDSSM connectivity fails due to missing network routing configuration for MDSSM pods.

Conditions: GSLB Sync Group is deployed on OpenShift with MDSSM enabled across two or more clusters. The f5ingress controller does not include MDSSM pod information in the initial egress routing configuration sent to the Cluster Static Route Controller (CSRC). As a result, no routing rules are created for MDSSM pod traffic to reach the shim interface.

Impact: MDSSM cross-cluster replication does not function. GSLB resource status data stored in MDSSM cannot be synchronized between clusters, preventing distributed session state sharing across sites.

Workaround: Restart both the f5ingress pod and the CSRC pod. After the restart, f5ingress will include MDSSM pods in the egress routing configuration, and CSRC will install the correct routing rules for MDSSM pod traffic. In some cases, restarting f5ingress alone may be sufficient, but if MDSSM communication still fails, delete and restart both the f5ingress and CSRC pods.

FSM issues

2284337-1

Title: WIPs config not pushed to GTM after correcting invalid GTM password in CIS

Component: fsm

Symptoms: If the GTM password in CIS is wrong, the WIPs configuration does not push to GTM for the related gateways. The issue continues even after you fix the password.

Conditions: Negative test when the GTM password in CIS is incorrect.

Impact: The WIPs configuration is not being pushed to GTM for the associated gateways even after correcting the password.

Workaround: Restart the CIS pod.

2277685-1

Title: When applying VRF and VLAN CRs before routing CRs, connected routes for non-default VRFs are incorrectly added to the default VRF routing table

Component: fsm-dynamic-routing

Symptoms: When VRF and VLAN custom resources (CRs) are applied before routing CRs, connected routes that belong to non-default VRFs (red, blue, green) are incorrectly installed in the default VRF routing table instead of their respective VRF routing tables. The per-VRF routing tables remain empty.

Conditions: VRF and VLAN custom resources (CRs) are applied before routing CRs.

Impact: Connected routes that belong to non-default VRFs are incorrectly installed in the default VRF routing table instead of their respective VRF routing tables.

Workaround: If the routing CRs are applied first and then the VRF/VLAN CRs are applied, the routes are correctly placed in their respective VRF tables.

f5ingress issues

2289809-1

The CNE controller does not remove SNAT pool translation addresses for non-default route domains after deleting two VLANs in a row

Component: ingress

Symptoms: TMM contains outdated SNAT pool addresses.

Conditions: The issue occurs under the following scenarios:

• Scenario 1:

  • The configuration consists of one Egress, one Snatpool, one VRF, and two VLANs. One VLAN is VRF-aware and referenced by the Egress; the other is non-VRF and not referenced by the Egress.

  • The non-VRF VLAN is deleted.

  • The VRF-aware VLAN (referenced by the Egress) is subsequently deleted. As a result, a stale custom RD Snatpool remains.

• Scenario 2:

  • The configuration consists of one Egress, one Snatpool, one VRF, and one VLAN that is VRF-aware and referenced by the Egress.

  • When the VLAN is deleted, a stale custom RD Snatpool persists.

Impact: TMM has stale snatpool addresses on TMM that may could interfere with any new snat configuration.

Workaround:

• Scenario 1:

  • Reapply both VLANs.

  • Delete the VRF-aware VLAN first.

  • Delete the non-VRF VLAN.

• Scenario 2:

  • Reapply the VRF-aware VLAN together with the non-VRF VLAN.

  • Delete the VRF-aware VLAN first.

  • Delete the non-VRF VLAN.

GSLB issues

2277417-1

Title: GSLB Sync Group cannot have Sync Agent role changed when deployment with such role is down

Component: dns-gslb sync group

Symptoms: When GSLB instance with current Sync Agent role is down, due to GSLB Engine failure or an entire CNF deployment failure, then the GSLB Sync Group cannot reassign the Sync Agent role to another active GSLB instance.

Conditions: The GSLB deployment with the current Sync Agent role is down due to either a GSLB Engine failure or a complete CNF deployment failure. An attempt is made to apply the GSLB Sync Agent Custom Resource (CR) with a different GSLB instance name to another CNF deployment.

Impact: The GSLB Sync Agent CR cannot be applied with a different GSLB Instance Name because current GSLB Sync Agent CR is not removed.

Workaround: All CNF deployments must be removed from GSLB Custom Resources (CRs) by deleting the GSLB Local Instance CRs for each deployment individually. This action will initiate the internal cleanup process on the GSLB Engines, removing both their internal configurations and the associated GSLB CRs from their respective local Kubernetes servers. If the GSLB Engines are unable to communicate with their local Kubernetes servers to delete the GSLB CRs, manual removal is possible. To do so, set the GSLB_FORCE_DELETE_ENABLED environment variable to true in f5ingress. Afterward, restart all GSLB Engines and all TMMs to ensure the configurations are fully cleared.

2186801-2

Title: A GSLB object can be created with a reference to a GSLB monitor, even if the monitor itself has not yet been created

Component: dns-gslb general

Symptoms: Currently, the GSLB configuration object such as GSLB Server, GSLB Virtual Server, a GSLB Pool, or a GSLB Pool Member, can be created and referencing the name of a GSLB Monitor that does not exist. In these cases, the configuration objects are still created, even though the referenced GSLB Monitor is missing.

Conditions: GSLB configuration objects with referencing to a monitor are created while the monitor does not exist.

Impact: GSLB objects will remain in the blue state; however, based on the configured load balancing options, they may still be selected in response to DNS queries.

Workaround: GSLB configuration objects and corresponding monitors must be created regardless of order to ensure accurate reflection of object states.

2261089-1

Title: GSLB Sync Group fails inter-cluster communication due to SSL/TLS certificate issues. Configuration does not sync after connection

Component: dns-gslb engine

Symptoms: When deploying two CNF instances with GSLB enabled across separate Kubernetes clusters, the GSLB stream to the remote peer remains in a reconnecting state and reports a “Failed to establish connection” error. The status of the remote GSLB server displays as “Checking” rather than “Available.” Furthermore, even after successful inter-cluster communication is established through the configuration of shared certificates, the remote GSLB member may still fail to synchronize configurations from the Sync Agent.

Conditions: The GSLB Sync Group is deployed across multiple CNF instances in separate Kubernetes clusters. While basic network connectivity between clusters is established (ICMP ping is successful), each cluster utilizes SSL/TLS certificates issued by distinct Certificate Authorities, rather than a shared common CA. To enable GSLB traffic across clusters, TMM tunnels are required. This necessitates proper configuration of the GSLB Packet Path, including CSRC routing rules and the use of shared TLS certificates.

Impact: Inter-cluster communication within the GSLB Sync Group is currently non-functional. Remote GSLB instances remain in a “Checking” state and are unreachable, which prevents configuration synchronization and disrupts GSLB availability across sites. Although the certificate issue has been resolved and communication has been established, configuration synchronization from the Sync Agent to remote members may still fail to complete. As a result, remote GSLB instances do not receive the expected configuration updates.

Workaround: All clusters participating in the GSLB Sync Group must use SSL/TLS certificates issued by a common Certificate Authority (CA). Distribute the root and intermediate CA certificates to every cluster prior to deploying cert-manager and f5ingress. Strictly adhere to the GSLB Packet Path documentation when configuring CSRC routing rules to ensure GSLB gRPC traffic traverses the TMM shim interface. Note that a successful ICMP ping between GSLB instances does not guarantee the functionality of the GSLB gRPC communication path, as ICMP and gRPC traffic may follow different network routes. If configuration synchronization remains incomplete after establishing connectivity, remove all GSLB Custom Resources (beginning with the GSLB Local Instance CRs) from each deployment and reapply them to reset the synchronization state.

2265957-1

Title: GSLB Engine unable to establish TCP connections on OpenShift clusters with OVN-Kubernetes networking

Component: dns-gslb engine

Symptoms: On OpenShift clusters using OVN-Kubernetes networking, GSLB Engine is unable to establish TCP connections for inter-cluster communication. The initial connection handshake begins successfully, but subsequent packets are dropped by the network layer, causing connection failures. GSLB streams between clusters remain in a reconnecting state, and GSLB servers report “No enabled virtual server available” with monitor timeouts.

Conditions: OpenShift 4.14 or later cluster using OVN-Kubernetes as the networking plugin. GSLB Sync Group configured with multiple clusters requiring inter-cluster communication.

Impact: GSLB synchronization between clusters fails. Health monitors cannot reach remote virtual servers, causing GSLB to mark all servers as unavailable. DNS load balancing across clusters does not function correctly.

Workaround: Adjust the network routing rule priority configuration.

2283789-1

Title: GSLB Sync Group Communication Issues on OpenShift with OVN-Kubernetes Networking

Component: dns-gslb sync group

Symptoms: On OpenShift clusters with OVN-Kubernetes networking, GSLB Sync Group inter-cluster communication fails unless specific Linux kernel networking parameters are manually changed on the worker nodes where GSLB Engine and Probe Agent pods are running. Without these changes, traffic from GSLB pods is not forwarded correctly, and GSLB instances in the Sync Group cannot reach each other.

Conditions: GSLB Sync Group is deployed on OpenShift 4.14 or 4.16 with OVN-Kubernetes as the cluster networking plugin. The worker nodes are using default OVN-Kubernetes sysctl settings (IP forwarding disabled, strict reverse path filtering).

Impact: GSLB Sync Group functionality does not work with default OpenShift node settings. Inter-cluster GSLB communication is broken, preventing configuration synchronization and probe data exchange between GSLB instances. The required workaround involves host-level changes to OpenShift worker nodes, which may conflict with your security policies or operational constraints.

Workaround: On each OpenShift worker node where GSLB Engine or Probe Agent pods are scheduled, apply the following sysctl settings:

set net.ipv4.ip_forward to 1
set net.ipv4.conf.all.rp_filter to 2
set net.ipv4.conf.default.rp_filter to 2.

These settings enable IP forwarding and relax reverse path filtering to loose mode. They can be applied at runtime using sysctl -w or persisted via sysctl configuration files or an OpenShift MachineConfig.

Note

These are node-level changes and must be applied on every worker node hosting GSLB pods.

2279717-1

Title:GSLB Sync Group traffic between instances fails on OpenShift without manually added static routes

Component: dns-gslb sync group

Symptoms: On OpenShift environments, GSLB Engine and GSLB Probe Agent pods are unable to communicate with remote GSLB instances. Traffic destined for remote GSLB instance addresses is not correctly forwarded through the expected network path, causing GSLB Sync Group connectivity failures.

Conditions: GSLB Sync Group is deployed on an OpenShift 4.14 environment with OVN-Kubernetes networking. Multiple GSLB instances are configured across different CNF deployments that need to communicate with each other.

Impact: GSLB Sync Group functionality does not work out of the box on OpenShift. Without manual intervention, GSLB instances cannot synchronize configuration or exchange probe data with remote instances, effectively preventing multi-site GSLB operation. The required manual workaround must be reapplied after every pod restart.

Workaround: After each GSLB Engine or GSLB Probe Agent pod starts (or restarts), manually add a static route inside the pod to direct traffic for remote GSLB instance subnets through the OVN management port gateway. For example: ip route add <remote-gslb-instance-subnet> via <ovn-management-port-gateway-ip> dev eth0. This route must be re-added whenever the affected pods are restarted.

2285413-1

Title: GSLB inter-instance traffic on non-Sync Agent member is routed through the Kubernetes pod network instead of the TMM internal VLAN

Component: dns-gslb sync group

Symptoms: On the non-Sync Agent member of a GSLB Sync Group deployed on OpenShift, incoming GSLB traffic from the Sync Agent is received by TMM but is forwarded to the GSLB Engine via the Kubernetes pod network interface (eth0) instead of the TMM internal VLAN (shim interface). This causes GSLB inter-engine communication to use an incorrect network path, with ingress traffic not following the same data plane path as egress traffic.

Conditions: A GSLB Sync Group with two or more CNF deployments is configured on OpenShift. The non-Sync Agent member receives GSLB traffic from the Sync Agent. The f5ingress controller does not add the required static route on TMM to direct GSLB traffic through the internal VLAN interface.

Impact: GSLB traffic between Sync Group members on the non-Sync Agent side flows through the Kubernetes pod network instead of the TMM data plane. This results in asymmetric routing where egress GSLB traffic uses the correct internal VLAN path but ingress GSLB traffic bypasses it. This may cause GSLB health monitoring (e.g., HTTPS monitors) and probe traffic to fail or behave unexpectedly.

Upgrade considerations

• Upgrade CNFs from 2.2.1 to 2.3.0 using Helm

• Upgrade CNFs from 2.2.1 to 2.3.0 using FLO

Rollback considerations

• Roll Back CNFs 2.3.0 to an Earlier Version