Thunderbolt DHCP leases from LAN and bad routing tables

[GandalfTea]

When setting up a local ring cluster over TB with devices on macOS 14, 15 or later, the Thunderbolt Bridge interface (bridge0) sends DHCP discover packets that sometimes reach the local LAN DHCP server (via Ethernet/Wi-Fi), even though the server is not present on the Thunderbolt peer-to-peer link. The bridge interface then receives a lease in the same subnet as the primary network (e.g. 192.168.1.x) which causes macOS to:

• install a high-priority default route pointing to the Thunderbolt Bridge interface that it thinks it can then uses to reach LAN/WAN:

default -> 192.168.1.1 via bridge0

• route internet traffic through the TB cable to peers and either drop it or forwarded it in the ring

This results in severe network slowdowns, timeouts, unreachable hosts, and broken mDNS. In my case none of the HTTP server requests from the TUI or between the nodes reached its destination and the entire computer effectively lost internet access.

To solve this I had to:

• Manually configure the IPv4 of the bridge0 interface of each device (by going into macOS Settings > Network > Thunderbolt Bridge > Details and assigning it a separate subnet like 10.10.0.1)
• Manually change the routing table to prioritize Ethernet/WiFi (again in Settings > Network > Triple Dots (...) > Set Service Order)

Reproduce:
This can be reproduced by setting the DHCP lease back to Automatic and replugging the cables until the interface receives an IPv4 address in the LAN subnet. Check the IP with:

ifconfig bridge0 | grep inet

Not sure this is within our scope but we might be able to at least give a warning?