Release Notes¶

F5 BIG-IP Next Cloud-Native Network Functions (CNFs) for OpenShift. CNF v1.3.3 is a maintenance release with the following bug fixes and known issues. This release contains no new features.

Bug Fixes¶

Bug ID 1753029-4¶

ICMP Monitor probes can flap when there is a slight delay in the response.

Affected Product(s)

BIG-IP Next (CNF)

Fixed In

1.3.3

Component

FSM

Symptoms

ICMP Connection flow timeout has been set at 1 second irrespective of the monitor timeout.
When the ICMP probes are sent to pool members, if there is a slight delay in the response, the connection flow may be cleared even before the response is received.
This condition causes the probe to fail and thereby marking the pool member as down.

Impact

Monitor probes fail causing the pool member to be marked down intermittently even when the actual pool member is healthy and alive.

Conditions

ICMP Connection flow timeout has been set to 1 second. If the ICMP response takes more than 1 second, the probes are marked as down.

Workaround

None

Fix Information

This issue is fixed by modifying the ICMP Connection flow timeout based on the ICMP monitor timeout.

Bug ID 1711109-2¶

Log throttling is non-deterministic.

Affected Product(s)

BIG-IP Next (CNF)

Fixed In

CNF 1.3.3

Component

FSM

Symptoms

Log throttling is non-deterministic, when large number of logs are being generated

Impact

May lose some logs when throttling is happening.

Conditions

Logs can be throttled, and users have no configuration mechanism to control this behavior.
When a pool member, which is common to all pools (For example, 8 pools) changes state, each of the TMM threads will produce logs. Thus, a large number of logs are generated within a one-second interval.
This results in mismatch condition of set/clear causing problem for alert monitoring.

Workaround

None

Fix Information

TMM allows a configuration variable sys db, which can be configured to the desired value. The newly introduced sys db variable is log.tmm.global.throttle.rate and the default value for this variable is 5.

Bug ID 1756313-2¶

TMM crashes with LTM monitor configured.

Affected Product(s)

BIG-IP Next (CNF)

Fixed In

1.3.3

Component

FSM

Symptoms

The TMM pod crashes periodically with the LTM monitor configured.

Impact

Traffic is disrupted as the TMM pod restarts.

Conditions

DNS, ICMP, or TCP LTM monitor is configured.
The VLAN used by the monitor traffic has a non-default value cmp-hash configured.

Workaround

Set the VLAN cmp-hash property value to default.

Fix Information

The TMM pod no longer crashes and traffic is not disrupted.

Bug ID 1756549-1¶

TMM Core dump while ACL logging for Hairpin connections.

Affected Product(s)

BIG-IP Next (CNF)

Fixed In

1.3.3

Component

AFM

Symptoms

TMM Core dump while ACL logging for Hairpin connections. Traffic is disrupted and the existing connections are dropped on the cored TMM pod.

Impact

Traffic is disrupted and the existing connections are dropped on the cored TMM pod.

Conditions

Dynamic-Pat NAT policy with Hairpin mode enabled.
Firewall policy with logging enabled and the Log profile has translation field logging enabled.
Both NAT and Firewall policy are attached to the secure context.
Hairpin connections matching the secure context.

Workaround

In the Global Context CR, apply a proper logging profile configured to log ACL action.

To apply the log profile, add the following to the values yaml file of F5BigContextGlobal CR.

apiVersion: k8s.f5net.com/v1
kind: F5BigContextGlobal
metadata:
  name: global-context
spec:
  firewall:
    defaultAction: "drop"
    defaultActionLog: false
  logProfile: "log-profile"

Fix Information

TMM pod no longer crashes while ACL logging for Hairpin connections and traffic is not disrupted.

Bug ID 1632313-2¶

The virtual servers are not configured when an FTP CR/Secure Context configuration contains zero rating iRule for scaled TMMs.

Affected Product(s)

BIG-IP Next (CNF)

Fixed In

1.3.3

Component

Ingress

Symptoms

F5 ingress sends partial configurations to the scaled up TMMs.
Virtual server configurations are missing in the scaled up TMMs for FTP CR or a Secure Context CR with zero-rating iRule CR.

Impact

The new TMMs are not configured properly as they miss virtual servers. This happens as partial configuration is being sent to the scaled up TMMs.
The bug has an impact on the data plane. Traffic meant for specific virtual servers will be impacted.

Conditions

FTP CR/Secure Context CR has been configured with iRule CR.
When the TMMs are scaled up.

Workaround

Delete all the virtual server profile CRs and virtual-server CR.
Re-apply them once again.

Fix Information

When a custom resource (CR) is deployed, F5ingress controllers cache the configurations meant for TMMs and use this cache to send full configuration to the newly scaled up TMMs. The cache was not being updated for FTP CR or Secure Context CRs with zero-rating iRule. The F5ingress controller has been fixed to update the cache correctly.

Known Issues¶

Bug ID 1757485¶

TCP Monitor properties are not taken into affect.

Affected Product(s):

BIG-IP NEXT (CNF)

Known Affected Versions:

1.3.3

Component

DNS

Symptoms

The TCP monitor operates with default values even after modifying or configuring the TCP Monitor timeout and interval values.

Impact

The monitor continues to use the default values even after changing the TCP interval and timeout settings.

Conditions

Changing the TCP monitor timeout and interval.

Workaround

The TCP monitor in DNSapp CRD uses the ICMP interval and timeout settings. If the ICMP monitor is not enabled, configure the ICMP interval and timeout to pass these attributes as TCP interval and timeout.

Fix Information

None.

Software upgrades¶

For assistance with software upgrades, refer to the Upgrading CNFs overview.

CNFs can be upgraded from v1.3.1 to v1.3.2. CNFs 1.3.2 version contains an updated version of the TMM pod. Hence, upgrading the F5ingress helm chart will update the TMM pod, allowing a smooth transition from version 1.3.1 to version 1.3.2.

To upgrade from CNF v1.3.1 to v1.3.2, please follow the steps below.
- Upgrade the f5ingress Pod using the newer version Helm chart of CNFs v1.3.2:
```
helm upgrade <release> tar/<helm-chart>.tgz -n <namespace> -f <values>.yaml
```
- In this example, the Helm chart new version of CNFs v1.3.2 is v150.480.0-0.1.52.
```
helm upgrade f5ingress tar/f5ingress-v150.480.0-0.1.52.tgz -n cnf-gateway -f f5ingress_overrides.yaml
```
  Now, the CNF is upgraded from v1.3.1 to v1.3.2.
CNFs can be upgraded from v1.3.0 to v1.3.1. Refer to Upgrading CNFs from v1.3.0 to v1.3.1 section.
CNFs can be upgraded from v1.2.1 to v1.3.0. Refer to Upgrading CNFs from v1.2.1 to v1.3.0 section.

Next step¶

Continue to the Cluster Requirements guide to ensure the cluster has the required software components.

Previous Next