Last Modified: Oct 16, 2023
Affected Product(s):
BIG-IP All
Known Affected Versions:
11.5.1, 11.5.2, 11.5.3, 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, 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, 13.0.0, 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, 13.1.3.2, 13.1.3.3, 13.1.3.4, 13.1.3.5, 13.1.3.6, 13.1.4, 13.1.4.1, 13.1.5, 13.1.5.1
Fixed In:
13.0.0 HF1, 12.1.2 HF1
Opened: Nov 19, 2015 Severity: 3-Major Related Article:
K48653096
High Speed Logging to specific destinations stops from individual TMMs. The flows appear to have very large idle times. Attempts to delete the flows sets the idle time to zero, but does not kill the flow.
Logs are silently lost.
This appears to be the result of a failure on the part of the log destination (for example, a log server) wherein the server's TCP stack ACKs a FIN request from the TMM, but does not follow through with a matching FIN or RST. The logging code expects another timeout (essentially a FIN-WAIT2 timeout), but never receives one because the flow has already been marked as expired. As a result, the flow goes into a state in which it appears to be viable but is not actually delivering.
Create an additional virtual server to act as a proxy for the log server, and sent the logs to this virtual server. This essentially uses the TMM itself as a sanitizing proxy.
The system now resets the expire timer when it initiates the close. If the server fails to reset or complete the close, the flow is aborted on the next expiration event.