Starlink with failover to LTE - best practice?

RouterOS General
1

hEX S running 7.22.3
Starlink on ether1, LHG LTE with passthrough on ether2
SL uses CGNAT, LTE sometimes gives me an RFC1918 address, at other times it is substituted for a public IP (here it is RFC1918).
As IPs and routes are semi static I use DHCP scripts to insert the received gateways into the routes.

I have been playing with AI, and per now this is my solution.
Dual probe routes and then recursive default routes.
Although I haven't tested it, it appears to work well.

Would you guys do something different?

/ip dhcp-client
add add-default-route=no default-route-tables=main interface=ether1 name=
client1 script=":log info "Executing DHCP script for SL"\r
\n:local gw $"gateway-address"
\n\r
\n:log info "Gateway=$gw"\r
\n/ip route set [find comment="SL Probe Google"] gateway=$gw\r
\n/ip route set [find comment="SL Probe OpenDNS"] gateway=$gw
\n\r
\n:log info "SL DHCP script done"\r
\n" use-peer-dns=no use-peer-ntp=no

add add-default-route=no default-route-tables=main interface=ether2 name=
client2 script="
\n:log info "Executing DHCP script for LTE"\r
\n:local gw $"gateway-address"
\n\r
\n:log info "Gateway=$gw"\r
\n/ip route set [find comment="LTE Probe Cloudflare"] gateway=$gw\r
\n/ip route set [find comment="LTE Probe Quad9"] gateway=$gw
\n\r
\n:log info "LTE DHCP script done"\r
\n" use-peer-dns=no use-peer-ntp=no

/ip dns
set servers=8.8.8.8,8.8.4.4

/ip route
add check-gateway=ping comment="SL default via Google" disabled=no distance=1
dst-address=0.0.0.0/0 gateway=8.8.8.8 routing-table=main scope=30
target-scope=11

add check-gateway=ping comment="SL default via OpenDNS" disabled=no distance=1
dst-address=0.0.0.0/0 gateway=208.67.222.222 routing-table=main scope=30
target-scope=11

add check-gateway=ping comment="LTE default via Cloudflare" disabled=no
distance=2 dst-address=0.0.0.0/0 gateway=1.1.1.1 routing-table=main scope=
30 target-scope=11

add check-gateway=ping comment="LTE default via Quad9" disabled=no distance=2
dst-address=0.0.0.0/0 gateway=9.9.9.9 routing-table=main scope=30
target-scope=11

add comment="SL Probe Google" disabled=no distance=1 dst-address=8.8.8.8/32
gateway=100.64.0.1 routing-table=main scope=10 target-scope=10

add comment="SL Probe OpenDNS" disabled=no distance=1 dst-address=
208.67.222.222/32 gateway=100.64.0.1 routing-table=main scope=10
target-scope=10

add comment="LTE Probe Cloudflare" disabled=no distance=1 dst-address=
1.1.1.1/32 gateway=10.13.198.85 routing-table=main scope=10 target-scope=10

add comment="LTE Probe Quad9" disabled=no distance=1 dst-address=9.9.9.9/32
gateway=10.13.198.85 routing-table=main scope=10 target-scope=10

2

Check these two as a reference:
Simpler Failover for two Gateways I found working - #18 by Filo

Simple recursive failover for bears of little brain

Particularly the second one to have formally correct scope and target-scope.

If the Starlink has some "dynamic" behaviour, then IMHO using netwatch Is more "flexible" than recursive.

3

Assuming you're using "Bypass" mode, the far end of starlink is some [Google/etc] data center, so just a plain check-gateway without recursive routing may be enough since it's the satellite link that the more common problem. Only if you using the 192.168.1.0/24 from the starlink router would you need recursive routing and/or netwatch.

Since both starlink and LTE are likely dynamic, if want to use recursive routing, I believe using an interface route would work (but cannot say I've tried it recently). But my recommendation be to use just check-gateway=ping on the DHCP client for starlink, along with a netwatch for DNS query and/or HTTP check as a double-check "everything" is working. I'm a bigger fan of using routing tables, one for starlink and one for LTE, so that you can you control which path netwatch is using (so with routing table you can validate both paths work via netwatch and/or using rules to steer traffic explictly if needed).