Last Modified: Aug 19, 2026
Affected Product(s):
BIG-IP LTM
Known Affected Versions:
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, 11.6.0 hf5, 11.6.0 hf6, 11.6.0 hf7, 11.6.0 hf8, 11.6.1, 11.6.1 hf1, 11.6.1 hf2, 11.6.2, 11.6.2 hf1, 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
Fixed In:
12.0.0, 11.5.3
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.