Last Modified: Apr 28, 2025
Affected Product(s):
BIG-IP APM
Known Affected Versions:
11.2.1, 11.3.0, 11.4.0, 11.4.1, 11.5.0, 11.5.1, 11.5.1 HF1, 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.1 HF10, 11.5.1 HF11, 11.5.2, 11.5.2 HF1, 11.5.3, 11.5.3 HF1, 11.5.3 HF2, 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, 12.0.0
Fixed In:
12.1.0, 12.0.0 HF1, 11.6.1, 11.5.4
Opened: May 15, 2014 Severity: 3-Major Related Article:
K17184
When the APM Access renderer or renderer pool (used for serving internal pages) goes down for an unknown reason, tmm goes into retry loop and sod kills the tmm.
Traffic disrupted while tmm restarts.
For the problem to occur, at the very least, APM must be in use. The problem showed up in the past with a mangled iRule in place.
This has only been observed with an incorrectly formed iRule. So it is likely that fixing an associated iRule to operate as intended will resolve the problem. If this occurs without an associated iRule, there is no workaround.
Now when an APM renderer or renderer pool (used for serving internal pages) goes down, APM detects the unavailability and sends a TCP Reset to the client.