Last Modified: Apr 28, 2025
Affected Product(s):
BIG-IP All
Known Affected Versions:
10.2.4, 11.0.0, 11.1.0, 11.2.0, 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.5.4, 11.5.4 HF1, 11.5.4 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, 12.0.0 HF1, 12.0.0 HF2
Fixed In:
13.0.0, 12.1.0, 12.0.0 HF3, 11.6.1, 11.5.4 HF3
Opened: Oct 28, 2015 Severity: 3-Major Related Article:
K53433830
The BIG-IP system experiences intermittent packet drops. Despite being negotiated during TCP handshake, the BIG-IP system fails to present timestamp option in subsequent segments. The BIG-IP system calculates invalid round trip time immediately after handshake, which might result in delayed retransmissions.
Connection might be reset by remote TCP stack (e.g., NetBSD and FreeBSD), which requires timestamps to be maintained once negotiated. Retransmission timeout (RTO) value may be skewed. Segments that are subject to RTO might take up to 64 segments to retransmit.
This occurs when the following conditions are met: - Virtual server configured with a TCP profile with timestamps enabled. - The syncookie mode has been activated. - Clients that support timestamps.
Choose or create a TCP profile that has timestamps disabled.
TCP Timestamps are now maintained on all negotiated flows.