Last Modified: Sep 13, 2023
Affected Product(s):
BIG-IP APM, LTM
Known Affected Versions:
11.2.1, 11.3.0, 11.4.0, 11.4.1, 11.5.0, 11.5.1, 11.5.2, 11.5.3, 11.5.4, 11.5.5, 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, 11.6.4, 11.6.5, 11.6.5.1, 11.6.5.2, 11.6.5.3, 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
Fixed In:
13.0.0, 12.1.3.4, 11.5.6
Opened: Jan 28, 2016 Severity: 3-Major
Previously, if a crypto accelerator encountered a failure, the default action was "none" or "failover". Now, the default behavior is "go-offline-downlinks". (Note: You can find information on crypto accelerator fail-safe behavior in K16951: Overview of SSL hardware acceleration fail-safe :: https://support.f5.com/csp/article/K16951.)
If a hardware accelerator failed on a blade in a chassis, the system would failover, but if there was a second failover back to the chassis with the failed blade, SSL traffic might get dropped.
Crypto accelerator encounters a failure and crypto.ha.action has not been changed from its default.
Set the db variable crypto.ha.action to your desired value.
Previously, if a crypto accelerator encountered a failure, the default action was either 'none' or 'failover'. Now, the default behavior is 'go-offline-downlinks'.
The default value of the db variable crypto.ha.action has changed to 'go-offline-downlinks'. The only time this has an effect on the system is when a crypto accelerator fails. For a chassis, this value will cause the blade that had the failed crypto device to go offline, leaving the other blades to handle the load, while an appliance will failover to its standby peer. See https://support.f5.com/csp/article/K16951 for more details.