Last Modified: Sep 13, 2023
Affected Product(s):
BIG-IP TMOS
Known Affected Versions:
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, 12.1.4.1, 12.1.5, 12.1.5.1, 12.1.5.2, 12.1.5.3, 12.1.6, 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, 13.1.1.4, 13.1.1.5, 13.1.3, 13.1.3.1, 14.0.0, 14.0.0.1, 14.0.0.2, 14.0.0.3, 14.0.0.4, 14.0.0.5, 14.0.1, 14.0.1.1, 14.1.0, 14.1.0.1, 14.1.0.2, 14.1.0.3, 14.1.0.5, 14.1.0.6, 14.1.2, 14.1.2.1, 14.1.2.2, 14.1.2.3, 14.1.2.4, 14.1.2.5, 14.1.2.6, 14.1.2.7, 14.1.2.8, 14.1.3, 14.1.3.1, 14.1.4, 14.1.4.1, 15.0.0, 15.0.1, 15.0.1.1, 15.0.1.2
Fixed In:
15.1.0, 15.0.1.3, 14.1.4.2, 13.1.3.2
Opened: Mar 25, 2019 Severity: 3-Major
Normally, when a pool member becomes unavailable, the flow is redirected towards another available pool member. However, an accelerated flow can continue to send traffic to the unavailable pool member rather than the updated one.
The flow's traffic continues to be targeted to a pool member that has become unavailable, resulting in a failure of service.
-- Using virtual servers configured for ePVA hardware acceleration via ePVA. -- A flow changes the pool member it should go to, while the flow is accelerated.
You can use either of the following workarounds: -- Disable HW acceleration. -- On BIG-IP v14.1.0 and later, if a pool member goes away, run the following command to flush all accelerated flows to be handled correctly by software: tmsh modify sys conn flow-accel-type software-only
None