Last Modified: Nov 07, 2022
Affected Product(s):
BIG-IP TMOS
Known Affected Versions:
11.5.1, 11.5.1 HF1, 11.5.1 HF10, 11.5.1 HF11, 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.10, 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.5.4 HF3, 11.5.4 HF4, 11.5.5, 11.5.6, 11.5.7, 11.5.8, 11.5.9, 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, 12.0.0, 12.0.0 HF1, 12.0.0 HF2, 12.0.0 HF3, 12.0.0 HF4, 12.1.0, 12.1.0 HF1, 12.1.0 HF2, 12.1.1, 12.1.1 HF1, 12.1.1 HF2, 12.1.2, 12.1.2 HF1, 12.1.2 HF2
Fixed In:
13.0.0, 12.1.3, 11.6.3
Opened: Jul 14, 2016 Severity: 2-Critical Related Article:
K50041125
There is a hard limit on messages sizes sent on the backplane on chassis platforms. Messages larger than the limit (~400K) are refused from being sent at a lower layer but buffered for resending at a higher layer. The messages are never sent which cases backplane communication to lockup.
The TMM becomes unresponsive to client traffic. If left running under load, the TMM might run out of memory from buffering SessionDB data and crash.
-- The BIG-IP system is a chassis with more than one blade. -- Client traffic triggers the creation of SessionDB data larger than ~400K.
The workaround is the avoid sending large SessionDB data. The TMM may be restarted in the event it does become unresponsive.
There is no longer a hard limit for sending SessionDB data on the backplane.
