Last Modified: Nov 07, 2022
Affected Product(s):
BIG-IP AFM, CGN, Link Controller, LTM
Known Affected Versions:
11.5.1, 11.5.1 HF1, 11.5.1 HF10, 11.5.1 HF11, 11.5.1 HF2, 11.5.1 HF3, 11.5.1 HF4, 11.5.1 HF5, 11.5.1 HF6, 11.5.1 HF7, 11.5.1 HF8, 11.5.1 HF9, 11.5.10, 11.5.2, 11.5.2 HF1, 11.5.3, 11.5.3 HF1, 11.5.3 HF2, 11.5.4, 11.5.4 HF1, 11.5.4 HF2, 11.5.4 HF3, 11.5.4 HF4, 11.5.5, 11.5.6, 11.5.7, 11.5.8, 11.5.9, 11.6.0, 11.6.0 HF1, 11.6.0 HF2, 11.6.0 HF3, 11.6.0 HF4, 11.6.0 HF5, 11.6.0 HF6, 11.6.0 HF7, 11.6.0 HF8, 11.6.1, 11.6.1 HF1, 11.6.1 HF2, 11.6.2, 11.6.2 HF1, 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.0.0 HF2, 12.0.0 HF3, 12.0.0 HF4, 12.1.0, 12.1.0 HF1, 12.1.0 HF2, 12.1.1, 12.1.1 HF1, 12.1.1 HF2, 12.1.2, 12.1.2 HF1, 12.1.2 HF2, 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
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.
Default configurations may suddenly show higher CPU performance profile usage after upgrade.
-- Most traffic is FastL4 forwarding deterministic LDNS. -- ePVA hardware is in use.
None.
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.
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.