Thunderbolt Bridge bridge0 and STP fixes for RDMA mesh setup
Parent: Mac local LLMs: Clusters, RDMA, exo and ds4 · Published reference · snapshot 2026-10-05
↓ Facts as markdownall context files
TN3205 says the default Thunderbolt Bridge forwards frames among all member ports like a hub, and a loop between ports can make frames travel indefinitely, consuming CPU and degrading performance
These notes link each claim to its source. Some citations identify archived research reports that are no longer hosted on this site. A published reference means the content is available; it does not certify independent review or accuracy.Read the editorial policy and follow the sources before relying on a claim.
Facts
- TN3205 says the default Thunderbolt Bridge forwards frames among all member ports like a hub, and a loop between ports can make frames travel indefinitely, consuming CPU and degrading performance [source]
- TN3205's example shows bridge0 members en2, en3 and en4 with flags LEARNING,DISCOVER and no STP configuration [source]
- An RDMA GID corresponds to an IP address on the paired Thunderbolt IP interface, giving a table such as ::ffff:169.254.205.255 and fe80:: entries for rdma_en2 [source]
- IP over Thunderbolt runs in parallel with RDMA and the Thunderbolt hardware load-balances between the two protocols [source]
- That commenter measured 7.4 GB/s sustained across 3 nodes with bridge0 intact, matching the figure with bridge0 destroyed [source]
- That commenter reports that destroying bridge0 on Mac minis with USB 2.5 GbE adapters makes the adapter disappear from ifconfig until replug or reboot [source]
- The commenter's explanation is that libthunderboltrdma reaches rdma_enX devices through ibv_* calls that bypass the bridge's network stack [source]
- The commenter attributes errno 22 to a device matrix pointing at the bridge, while issue 3467 shows a GID-selection regression in JACCL also yields errno 22 with the bridge disabled [source]
- Issue 3467 reproduced with macOS 26.x, rdma_ctl status enabled, Thunderbolt Bridge disabled and per-port EXO Thunderbolt services, so errno 22 is not proof the bridge is still present [source]
- An exo user on a 4x M3 Ultra mesh ran with Thunderbolt Bridge disabled and per-port link-local services yet still saw errno 22 and 60 after daemon kills until a JACCL race fix was applied [source]
- No fetched source describes an STP-specific configuration fix for Thunderbolt RDMA meshes beyond removing or bypassing bridge0 [source]
Corrections and disagreements
- CONTRADICTS distributed-inference-across-macs.md (step 4, bridge0 must be disabled): a 2026-04-03 commenter on macOS 26.4 with MLX 0.31.1 reports JACCL init works across 3 nodes with bridge0 present and active once each Thunderbolt interface has its own IP [source]
Children
- No children recorded.