Bug ID 2298633: TMM May Fail To Start, Rendering The Device Inoperative

Last Modified: Jun 30, 2026

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

Known Affected Versions:
17.5.1.6

Opened: May 22, 2026

Severity: 3-Major

Symptoms

In very rare circumstances, tmm may fail to start after a reboot and log a message similar to the following: /var/log/tmm: notice vmxnet3(1.3)[1b:00.0]: Waiting for tmm1 to reach state 1... /var/log/tmm1: notice Failed to connect to TMROUTED: ERR_INPROGRESS. Try again in 10 seconds. notice MCP connection expired early in startup; retrying While the issue is occurring, there may be some ARP entries for tmm. # arp -an | grep 127.1.1.? (127.1.1.8) at 00:01:23:45:67:07 [ether] on tmm ? (127.1.1.5) at 00:01:23:45:67:04 [ether] on tmm ? (127.1.1.2) at <incomplete> on tmm ? (127.1.1.4) at 00:01:23:45:67:03 [ether] on tmm ? (127.1.1.7) at 00:01:23:45:67:06 [ether] on tmm ? (127.1.1.6) at <incomplete> on tmm ? (127.1.1.1) at 00:01:23:45:67:00 [ether] on tmm ? (127.1.1.3) at 00:01:23:45:67:02 [ether] on tmm

Impact

TMM is unable to start

Conditions

- First start after a reboot or upgrade - An F5OS tenant running on r2000 or r4000 series hardware

Workaround

Restart tmm manually with bigstart restart tmm Or enable tmm.mcp.disconnect.core, which will restart tmm automatically during this situation. Alternatively, set up a static ARP mapping on the Linux host: arp -s 127.1.1.2 00:01:23:45:67:01 arp -s 127.1.1.3 00:01:23:45:67:02 arp -s 127.1.1.4 00:01:23:45:67:03 arp -s 127.1.1.5 00:01:23:45:67:04 arp -s 127.1.1.6 00:01:23:45:67:05 arp -s 127.1.1.7 00:01:23:45:67:06 arp -s 127.1.1.8 00:01:23:45:67:07 If there are more than 8 tmms, the following script can be used: for y in $(seq $(/usr/bin/getdb Provision.tmmCountActual)); do arp -s 127.1.1.$(($y+1)) 00:01:23:45:67:$(printf "%02g" $y); done

Fix Information

None

Behavior Change

Guides & references

K10134038: F5 Bug Tracker Filter Names and Tips