Bug ID 667257: CPU Usage Reaches 100% With High FastL4 Traffic

Last Modified: Sep 13, 2023

Affected Product(s):
BIG-IP AFM, CGN, Link Controller, LTM(all modules)

Known Affected Versions:
11.5.4, 11.5.5, 11.5.6, 11.5.7, 11.5.8, 11.5.9, 11.5.10, 11.6.0, 11.6.1, 11.6.2, 11.6.3, 11.6.3.1, 11.6.3.2, 11.6.3.3, 11.6.3.4, 12.0.0, 12.0.0 HF1, 12.1.0 HF1, 12.0.0 HF2, 12.1.0 HF2, 12.0.0 HF3, 12.0.0 HF4, 12.1.1 HF1, 12.1.1 HF2, 12.1.2 HF1, 12.1.2 HF2, 12.1.0, 12.1.1, 12.1.2, 12.1.3, 12.1.3.1, 12.1.3.2, 12.1.3.3, 12.1.3.4, 12.1.3.5, 12.1.3.6, 12.1.3.7, 12.1.4, 13.0.0, 13.0.0 HF1, 13.0.0 HF2, 13.0.0 HF3, 13.0.1, 13.1.0, 13.1.0.1, 13.1.0.2, 13.1.0.3, 13.1.0.4, 13.1.0.5, 13.1.0.6, 13.1.0.7, 13.1.0.8, 13.1.1, 13.1.1.2, 13.1.1.3

Fixed In:
14.0.0, 13.1.1.4, 12.1.4.1, 11.6.4

Opened: May 31, 2017

Severity: 3-Major

Symptoms

CPU usage reaches 100% with high FastL4 traffic. Issue with re-offloading evicted FastL4 traffic to ePVA. Typically observed on systems handling a lot of FastL4 traffic that have been upgraded to a version that has re-offload behavior implemented by Bug ID 563475: ePVA dynamic offloading can result in immediate eviction and re-offloading of flows.

Impact

Default configurations may suddenly show higher CPU performance profile usage after upgrade.

Conditions

-- Most traffic is FastL4 forwarding deterministic LDNS. -- ePVA hardware is in use.

Workaround

None.

Fix Information

The following db variables have been added to control re-offload behavior: sys db pva.reoffload.delay { value "5" } sys db pva.reoffload.exponential { value "true" } pva.reoffload.delay is in seconds. This is the amount of time that needs to expire before TMM attempts to re-offload the flow to the ePVA. If pva.reoffload.exponential is 'true', then if there is a collision, there is an exponential backoff (5 seconds, 10 seconds, 20 seconds, and so on), before the flow is re-offloaded). If pva.reoffload.exponential is 'false', then there is no backoff, and the flow is re-offloaded after the pva.reoffload.delay expires.

Behavior Change

The following db variables have been added to control re-offload behavior: sys db pva.reoffload.delay { value "5" } sys db pva.reoffload.exponential { value "true" } pva.reoffload.delay is in seconds. This is the amount of time that needs to expire before TMM attempts to re-offload the flow to the ePVA. If pva.reoffload.exponential is 'true', then if there is a collision, there is an exponential backoff (5 seconds, 10 seconds, 20 seconds, and so on), before the flow is re-offloaded). If pva.reoffload.exponential is 'false', then there is no backoff, and the flow is re-offloaded after the pva.reoffload.delay expires.

Guides & references

K10134038: F5 Bug Tracker Filter Names and Tips