Last Modified: Apr 28, 2025
Affected Product(s):
BIG-IP LTM
Known Affected Versions:
10.0.0, 10.0.1, 10.1.0, 10.2.0, 10.2.1, 10.2.2, 10.2.3, 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.6.0, 11.6.0 HF1, 11.6.0 HF2, 11.6.0 HF3, 11.6.0 HF4
Fixed In:
12.0.0, 11.6.0 HF5, 11.5.3, 11.4.1 HF9
Opened: Nov 22, 2013 Severity: 3-Major Related Article:
K14918
If persistence is used, and a node is marked down and then up in quick succession (less than about 7 seconds), then persistence may act inconsistently (meaning, not all connections expected to persist to a server will do so). Further requests in certain circumstances may hang (the client will be left waiting for a response).
Inconsistent persistence behaviors. If persistence records are examined, you might find multiple, conflicting entries. This is an intermittent issue.
Persistence, rapid node flapping, new connection (via a TMM with an existing connection) after node has been re-marked as up.
Add an iRule command to the PERSIST_DOWN event that deletes the persistence entry for this connection. One example might be: when PERSIST_DOWN { persist delete source_addr [IP::client_addr] } For more information, see SOL14918: Node flapping may cause inconsistent persistence records, available here: http://support.f5.com/kb/en-us/solutions/public/14000/900/sol14918.html.
The system now deletes a persist entry from all peer TMMs when it is deleted in any TMM, so no conflicts occur.