Bug ID 660895: TMM can crash if TMM count is greater than licensed throughput

Last Modified: Mar 29, 2024

Affected Product(s):
BIG-IP All(all modules)

Known Affected Versions:
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.0.0, 12.0.0 HF1, 12.1.0 HF1, 12.0.0 HF2, 12.1.0 HF2, 12.0.0 HF3, 12.0.0 HF4, 12.1.1 HF1, 12.1.1 HF2, 12.1.2 HF1, 12.1.2 HF2, 12.1.0, 12.1.1, 12.1.2, 12.1.3, 12.1.3.1, 12.1.3.2, 12.1.3.3, 12.1.3.4, 12.1.3.5, 12.1.3.6, 12.1.3.7, 12.1.4, 12.1.4.1, 12.1.5, 12.1.5.1, 12.1.5.2, 12.1.5.3, 12.1.6, 13.0.0, 13.0.0 HF1, 13.0.0 HF2, 13.0.0 HF3, 13.0.1

Fixed In:
13.1.0

Opened: Apr 26, 2017

Severity: 3-Major

Symptoms

The rate shaper used for BIG-IP virtual Edition (VE) divides the total licensed throughput amongst the running TMMs to determine a per-TMM throughput. If the TMM count is greater than the licensed throughput, then this causes a 0-per-tmm throughput limit, which is unfortunately used as a divisor later in rate shaper operations, and which might result in an eventual divide-by-zero error and a crash. This might repeat indefinitely.

Impact

Traffic is disrupted while TMM restarts, potentially repeatedly.

Conditions

Install a license on a VE with a bandwidth limit where the number of megabits per second (Mbps) is less than the number of TMM instances (typically, the number of CPU cores), for example, Use a 2 Mbps license and configure 4 CPUs on a VE system. Note: This has been observed on evaluation licenses, but might be possible in other circumstances.

Workaround

Change the number of vCPUs available to the BIG-IP guest to be less than the licensed throughput.

Fix Information

Rate shaper now enforces a minimum, per-TMM throughput to avoid dividing by zero and crashing when the TMM count is greater than the licensed throughput in Mbps.

Behavior Change

Guides & references

K10134038: F5 Bug Tracker Filter Names and Tips