# Thunderbolt Bridge bridge0 and STP fixes for RDMA mesh setup > 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 Parent: [Mac local LLMs: Clusters, RDMA, exo and ds4](https://llms-explorer.com/tree/mac-local-llms-clusters-rdma-exo-ds4/) · 2 facets · 12 facts · page: https://llms-explorer.com/tree/thunderbolt-bridge-bridge0-and-stp-fixes-for-rdm/ ## 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](https://developer.apple.com/documentation/technotes/tn3205-low-latency-communication-with-rdma-over-thunderbolt) - TN3205's example shows bridge0 members en2, en3 and en4 with flags LEARNING,DISCOVER and no STP configuration — [source](https://developer.apple.com/documentation/technotes/tn3205-low-latency-communication-with-rdma-over-thunderbolt) - 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](https://developer.apple.com/documentation/technotes/tn3205-low-latency-communication-with-rdma-over-thunderbolt) - IP over Thunderbolt runs in parallel with RDMA and the Thunderbolt hardware load-balances between the two protocols — [source](https://developer.apple.com/documentation/technotes/tn3205-low-latency-communication-with-rdma-over-thunderbolt) - That commenter measured 7.4 GB/s sustained across 3 nodes with bridge0 intact, matching the figure with bridge0 destroyed — [source](https://github.com/ml-explore/mlx/discussions/3481) - 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](https://github.com/ml-explore/mlx/discussions/3481) - The commenter's explanation is that libthunderboltrdma reaches rdma_enX devices through ibv_* calls that bypass the bridge's network stack — [source](https://github.com/ml-explore/mlx/discussions/3481) - 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](https://github.com/ml-explore/mlx/issues/3467) - 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](https://github.com/ml-explore/mlx/issues/3467) - 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](https://github.com/exo-explore/exo/issues/1847) - No fetched source describes an STP-specific configuration fix for Thunderbolt RDMA meshes beyond removing or bypassing bridge0 — source: `asserted` ## 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](https://github.com/ml-explore/mlx/discussions/3481)