Last Modified: Sep 13, 2023
Affected Product(s):
BIG-IP TMOS
Known Affected Versions:
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, 13.0.0, 13.0.0 HF1, 13.0.0 HF2, 13.0.0 HF3, 13.0.1, 13.1.0, 13.1.0.1, 13.1.0.2, 13.1.0.3, 13.1.0.4, 13.1.0.5, 13.1.0.6, 13.1.0.7, 13.1.0.8, 13.1.1, 13.1.1.2, 13.1.1.3, 14.0.0, 14.0.0.1, 14.0.0.2, 14.0.0.3, 14.0.0.4
Fixed In:
14.1.0, 14.0.0.5, 13.1.1.4, 12.1.4
Opened: Jan 04, 2018 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 between tmm threads may result in sub-optimal performance.
Source ports used to connect to B2250 blade form an arithmetic sequence. For example, some servers always use randomly selected even source port numbers. 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.
Randomize source ports when connecting via a BIG-IP system.
This release introduces a new variable you can use to mitigate the issue: mhdag.pu.table.size.multiplier 1. Set the variable to to 2 or 3 as appropriate on the vCMP host. 2. Restart tmm on all blades of vCMP host 3. Restart tmm on all blades of all vCMP guests. The following command will restart tmm on all blades of a system: clsh bigstart restart tmm Note: Restarting tmm on the guests only does nothing; restarting on the host only means that the guests still use old DAG settings and have high inter-TMM forwarding traffic, resulting in a worse condition than originally experienced.
This release introduces a new variable to mitigate this issue: mhdag.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.