Loading...
Loading...
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
TMM is unable to start
- First start after a reboot or upgrade - An F5OS tenant running on r2000 or r4000 series hardware
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
None
F5 Integration
Learn more about where this data comes from
BugZero Plan
Streamline upgrades with automated vendor bug scrubs
BugZero Prevent
Wish you caught this bug sooner? Get proactive today.