Last Modified: Sep 13, 2023
Affected Product(s):
BIG-IP LTM
Known Affected Versions:
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 HF1, 11.5.3 HF1, 11.5.3 HF2, 11.5.4 HF1, 11.5.4 HF2, 11.5.4 HF3, 11.5.4 HF4, 11.3.0, 11.4.0, 11.4.1, 11.5.0, 11.5.1, 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.1.0 HF1, 12.1.0 HF2, 12.1.1 HF1, 12.1.1 HF2, 12.1.2 HF1, 12.1.2 HF2
Fixed In:
12.0.0, 12.0.0, 11.6.0 HF5, 11.5.2, 11.4.1 HF9
Opened: Feb 21, 2014 Severity: 3-Major Related Article:
K16363
The existing source persistence record is not used as fallback for a second SSL request from the same source. The second request may be load balanced to a different pool member than the first one. Sometimes multiple source persistence records may be created pointing to different pool members.
Requests are load balanced to different pool members instead of the same one. In other words, source fallback persistence does not work.
SSL persistence configured as primary persistence method on a SSL VIP. Source persistence configured as fallback persistence method. The same client sends a second SSL request, but sends a different session ID so that SSL persistence look up fails.
There is no workaround for this issue.
Fallback source persistence entry is now used when primary SSL persistence fails.