ZT "stuck" on less preferred outbound route?

Hey guys. I have been testing ZT for a roaming mobile device use case and it’s been working really well. Have one weird issue though.

These mobile devices are running Ubuntu, and have both a wired (eth0) and an LTE (wwan0) connection. When eth0 is up, there is a default route in the table with a 425 metric, and all outbound traffic goes that way. There is also a default route out the wwan0 interface with a 700 metric.

If eth0 is not available, ZT works fine on the wwan0 interface. And, if eth0 was available and gets disconnected, it seems to fail over after some time. However, if ZT is running on wwan0 and eth0 comes online, it never seems to start using that route, despite the global routing table preferring eth0 at that point. Restarting the zerotier-one service immediately bumps it back over.

Anything I can do to make this automatic?

Hello,
thanks for asking.

I don’t think it knows anything about route metrics. It chooses based on latency, basically.
It might take 5 minutes to realize the new path.

Does anything change if you have the far end try to talk to your local machine, like just ping?

There will be some improvements to this kind of thing in the future.

Maybe ubuntu has some kind of thing to detect network changes that you can script to kick zerotier?

Thanks. Of course shortly after I posted that it did finally switch over to the eth0 connection, but seems to take a while. I had a ping running the whole time.

Just was hoping there was a way to make ZT a bit more aggressive choosing the best path. I’ve played with the multipath settings as well and they never seem to work.

Appreciate it!

Is there any more info on what causes this to take 5 minutes? What process determines latency on each interface? Can we speed it up?