Last Modified: Apr 19, 2021
See more info
Known Affected Versions:
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, 12.1.3, 220.127.116.11, 18.104.22.168, 22.214.171.124, 126.96.36.199, 188.8.131.52, 184.108.40.206, 220.127.116.11, 12.1.4, 18.104.22.168, 12.1.5, 22.214.171.124, 126.96.36.199, 188.8.131.52, 12.1.6, 13.0.0, 13.0.0 HF1, 13.0.0 HF2, 13.0.0 HF3, 13.0.1
Opened: Apr 23, 2018
Related AskF5 Article: K59332523
If a TCP Segmentation Offload (TSO) packet length exceeds the rateshaper's max ceiling, it causes the flow to stall.
The flow stalls. Subsequent flows cannot go to the rateshaper from that particular tmm.
TSO packet length exceeds the rateshaper's configured max ceiling.
If you are running BIG-IP software v184.108.40.206 (or later) or v13.1.0(.x), you can use the following workaround: There is a sys db variable called 'rateshaper.cmpdivide', which is enabled by default. When enabled, the system internally divides the bandwidth (rate/ceiling/burst) between the available tmm cores. If this issue occurs, set 'rateshaper.cmpdivide' to enabled. There is no workaround for other versions.
Rateshaper no longer stalls when TSO packet length exceeds max ceiling.