Bug ID 913829: i15000, i15800, i5000, i7000, i10000, i11000 and B4450 blades may lose efficiency when source ports form an arithmetic sequence

Last Modified: Jan 04, 2022

Bug Tracker

Affected Product:  See more info
BIG-IP TMOS(all modules)

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,,,,,,,, 12.1.4,, 12.1.5,,,, 12.1.6, 13.0.0, 13.0.0 HF1, 13.0.0 HF2, 13.0.0 HF3, 13.0.1, 13.1.0,,,,,,,,, 13.1.1,,,,, 13.1.3,,,,,,, 14.0.0,,,,,, 14.0.1,, 14.1.0,,,,,, 14.1.2,,,,,,,,, 14.1.3,, 15.0.0, 15.0.1,,,,, 15.1.0,,,,,, 15.1.1, 15.1.2,, 16.0.0,, 16.0.1,

Fixed In:
16.1.0,, 15.1.3, 14.1.4, 13.1.4

Opened: Jun 03, 2020
Severity: 3-Major


Traffic imbalance between tmm threads. You might see the traffic imbalance by running the following command: tmsh show sys tmm-traffic


Traffic imbalance may result in tmm threads on different CPU cores having imbalanced workloads. While this can sometimes impact on performance, an overloaded tmm thread can usually redistribute load to less loaded threads in a way that does not impact performance. However the loads on the CPU cores will appear imbalanced still.


Source ports used to connect to i15000, i15800, i5000, i7000, i10000, i11000 and B4450 blades form an arithmetic sequence. For example, some client devices always use even source port numbers for ephemeral connections they initiate. This means the 'stride' of the ports selected is '2'. Because a sorted list of the ports yields a list like 2, 4, 6, 8... 32002, 32004. It is 'striding' over the odd ports; thus, a port stride of 2.


Where possible, configure devices to draw from the largest possible pool of source ports when connecting via a BIG-IP system.

Fix Information


Behavior Change

This release introduces a new variable to mitigate this issue: dagv2.pu.table.size.multiplier. You must set the variable to 2 or 3 on the host, and then restart tmm on all host blades and then all guests to mitigate the issue. dag2.pu.table.size.multiplier.