How to Reset Device Trust – F5 LTM Load Balancing Methods Troubleshooting ConfigSync and Device Clustering
Chris Spillane provides a quick guide to troubleshooting device clustering or config sync for version 11.x.
Notice: This blog post was originally published on Indeni before its acquisition by BlueCat.
The content reflects the expertise and perspectives of the Indeni team at the time of writing. While some references may be outdated, the insights remain valuable. For the latest updates and solutions, explore the rest of our blog
Key takeawaysKey takeaways are generated with AI assistance. Because automated summaries can occasionally contain errors or miss important context, always refer to the full blog post for complete information.This article is a concise troubleshooting reference for F5 device clustering and configuration synchronization, summarizing how F5 BIG-IP devices communicate to form a device cluster and where common failures occur. It explains the technical communication flow between processes: the local mcpd connects to the local tmm on port 6699, tmm contacts the peer's config sync IP on port 4353, and then the peer's tmm contacts its local mcpd on port 6699, with failures retried every five seconds. The guide points operators to the Device Management > Devices > [device] > Device Connectivity > Config Sync page to verify the config sync self IP used in these connections and serves as a quick reference alternative to the longer SOL13946 documentation.
What sequence of process-to-process connections establishes F5 device clustering and config sync?
The cluster forms when the local mcpd process connects to the local tmm process on port 6699. The local tmm then contacts the peer’s config sync IP on port 4353. When the peer receives that contact, its tmm uses that peer device’s local connection to contact its own mcpd on port 6699. If these steps complete, a mesh between peer mcpd processes is established enabling config synchronization.
Which ports must be open and reachable for successful config sync between F5 devices?
Successful configuration sync requires connectivity on port 6699 between each device’s mcpd and its local tmm process, and on port 4353 from a device’s tmm to the peer’s config sync IP. Specifically, the local mcpd connects to local tmm on 6699, tmm contacts the peer’s config sync IP on 4353, and then the peer’s tmm contacts its local mcpd on 6699. If any of these ports or paths fail, the sync attempt will be retried every five seconds.
Where in the BIG-IP GUI can I confirm which self IP is used for config sync?
You can verify the self IP used for config sync in the GUI by navigating to Device Management > Devices, selecting the device, and then opening Device Connectivity > Config Sync. The article notes that ‘local machine’ refers to that self IP configured for config sync, and confirming this setting helps ensure the mcpd-to-tmm and tmm-to-peer communication use the correct IP addresses during the synchronization process.
F5 LTM Load Balancing Methods: How to Reset Device Trust.
The official F5 SOL13946 provides information on troubleshooting device clustering and configuration sync for 11v F5 load balancers and other products, however it is rather long winded. This guide is designed as a quick reference when troubleshooting device clustering or config sync. An overview of the config sync process for version 9.x and 10.x units can be found in F5 SOL7024
Version 11.x
- Communication between machines occurs in the following manner to form a device cluster:
mcpd process on the local machine connects to the tmm process on the local machine on port 6699
- tmm process then contacts the peer’s config sync IP on port 4353
- Once the peer receives, they use tmm to contact mcpd over port 6699 on their local device.
- If this process fails, it is re-attempted every 5 seconds.
- If this process succeeds, there is a mesh between peer mcpd processes.
* local machine here refers to the self IP configured for config sync. Check it under Device Management > Devices > click on device > Device Connectivity > Config Sync, for example.
Related content
Get answers from the LiveNX data you already have with LiveAssist
Learn how LiveAssist, the AI-powered add-on for LiveNX, turns your network data into fast, guided answers, with value you can see in days.
LiveWire GEN3 device offerings
BlueCat LiveWire is a packet capture and network forensics platform that provides deep packet-level visibility across hybrid enterprise environments to help…
Get total control of your DDI infrastructure with Micetro’s unified API
Stop juggling between network tools and use Micetro’s RESTful API for complete control over your DDI infrastructure and cloud environment.
BlueCat MCP servers bring network intelligence to your AI assistant
Our MCP servers provide a standard integration layer that makes it easy to connect the AI tools you already use to BlueCat products.