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 takeawaysThis key takeaway was generated through LLMs crawling the page and coming up with an overview of the content.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
How to map your network with user-defined links in Integrity X
Map your network with user-defined links in Integrity X to define and manage custom relationships, such as dual-stack and NAT environments.
Automate your DDI modernization path by migrating with Micetro
Automate cross-platform DNS and DHCP migration with Micetro to reduce risk, eliminate manual effort, and modernize infrastructure faster.
Your journey to intelligent NetOps begins at Cisco Live
Visit BlueCat’s booth or book a meeting now to learn more about how our solutions can help you build a network that supports constant change.
Replace BIND and ISC with Micetro DNS/DHCP Server (MDDS)
Tired of patching and manually configuring BIND DNS and ISC DHCP? Discover how Micetro MDDS appliances can replace them for modern DDI.