Release Notes

F5® BIG-IP® Next™ Cloud-Native Network Functions (CNFs) for OpenShift and Robin. CNF v1.3.2 is a bug fix release, and contains no new features.

Bug Fixes

Bug ID 1695801

Intel E810 physical function (PF) triggers Malicious Driver Detection (MDD) and disables virtual function (VF) queue if packets with more than eight fragments are passed in egress traffic for transmission.

Affected Product(s)

BIG-IP NEXT (CNF)

Known Affected Versions

1.3.0, 1.3.1

Fixed In

1.3.2

Impact

Traffic flow across a specific TMM queue drops as the E810 PF disables the associated VF queue. In the tmm/ndal_tx_stats stats, the sent counter associated with the corresponding queue stops incrementing and the drop_full_dq counter starts incrementing.

Symptoms

  • Intel E810 PF triggers MDD and disables the VF queue when the application tries to send packets with more than eight fragments.

  • The dmesg/kern.log file on the host contains the following message for the VF:

    kernel: ice <PCI coordinates of VF>: 1 Tx Malicious Driver Detection events detected on PF 1 VF 24 MAC <MAC address>.

Conditions

  • Intel E810 VF used for the data-plane traffic.
  • TCP Segmentation Offload (TSO) disabled.
  • Large receive offload (LRO) disabled.

Workaround

Once the VF queue is in disable state, restart the TMM application to reset the VF queues.

Fix Information

  1. TSO (TCP Segmentation Offload) is disabled as a default.
  2. Maximum fragments per packet value is set to 8, as per Intel E810 specification. Any packets receiving greater than 8 fragments will undergo packet compaction, which will reduce the fragment count to below 8 and avoids an MDD event.
  3. A new counter pkt_compact is added to ndal_tx_stats to determine the number of packets compacted on egress.
  4. After packet compaction, if the number of fragments still remains greater than 8, the packet is dropped with drop_too_many_frags counter in tmm/ndal_tx_stats incremented, and not sent out on egress avoiding the occurrence of an MDD event.

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.