RB5009UG with latest software. Have followed setup in link below, but is not right. Instead of primary Starlink ISP with failover, it is allowing both Verizon and Starlink at same time. Links to 8.8.8.8 and 8.8.4.4 as well as secondary DNS pings are listed as unreachable. Both ISP are using dynamic IP assignment and are being automatically configured with distance of 0. I’ve tried manually creating this but the both get created again still with the distance set to 0. Any help would be appreciated thanks.
/interface bridge
jaclaz
March 13, 2026, 11:36pm
2
Scope 11 and target scope 11?
Recursive routing and failover setup making use of it is one among the many commonly needed features of a router that is - BTW like most useful things possible in RouterOS - either mis-documented or documented in such a complex and convolute way that bears of little brain like myself simply cannot grasp in their entirety.
By applying a (rest assured moderate) amount of torture to knowledgeable member CGGXANNX (whom I want to thank for the patience and the will to discuss and explain the matter)…
I went a head and made the changes you suggested but they made no difference. None of the recursive connections work. And is still using both ISPs not in failover mode.
/interface bridge
Thank you for the help but it does raise some issues.
Firstly, I can’t change the DHCP clients default distance as these two are created by router and don’t allow me to edit them.
Secondly, the Starlink ISP is dynamic generated by Starlink equipment running in bypass mode so there is no guarantee the IP address for the gateway will stay the same.
I went ahead and made the changes you suggested (at least the ones I could) and although the Wide routes are now active, the setup is still running in load balance not failover.
/interface bridge
jaclaz
March 15, 2026, 5:51pm
6
Yes, you have the two DAD routes (actually DAD+ as they become PCC ECMP ).PCC ECMP )client on Mikrotik:
/ip dhcp-clientdefault-route-distance=100 default-route-distance=101
This will make the two top rules "out of the way".
Then, you have only two ISP's, so you need recursive and gateway check on only one of them, there is no difference between
check if main is down, if it is use secondary, as soon as primary resumes go back to primary
check if secondary is down, if it is do nothing, as soon as it resumes, do nothing
And:
check if main is down, if it is use secondary, as soon as primary resumes go back to primary
do nothing
So, IF your "main" is Verizon and secondary is Starlink you can still use recursive.
Otherwise, you can use Netwatch, simplest approach here:
Only to keep things as together as possible I just “sold” this Filo’s approach to a new user, with a few changes.
I got rid of the separate routing table and of the mangle by adding a “narrow” /32 route to the “canary” ip address in “main” table.
And I didn’t use the “comment” as selector in the Netwatch script (this is a pet peeve of mine, comments may be changed accidentally six months or a year later, the setup would stop working and finding out what happened would be more difficult).
Be…
Hello Jaclaz,
As I already stated, I cannot edit the two DHCP-clients as there are automatically created by the RB5009UG and it will not allow me to change them in any way. I have tried deleting them and creating ones manually but the router just creates it’s own again and they become the default. Is there a way to stop the router from creating the automatically? Also is this even possible with dynamic ISP addresses?
Thanks
Andrew
Znevna
March 15, 2026, 10:21pm
8
Just a guess, but you did figure out how to add starlink and verizon to those two dhcp clients.
jaclaz
March 15, 2026, 10:32pm
9
It's not possible AFAIK.
You have two DHCP clients in your configuration, they are configuration lines like any other.
Try disabling one of them.
Or try removing one of them.
Is It re-enabled or re-added automagically?
If yes, something is recreating them, but It Is not the normal behaviour.
Detect-internet may do that, but It doesn't seem to be enabled in your configuration.
Or maybe It doesn't show on your export?
Try also disabling the two separate Nat rules and re-enable the single defconf out-interface-list=WAN one, but I doubt that those Nat rules have anything to do with the automatic recreating of DHCP clients.
I originally had the single NAT rule and they were created then too.
I only remove them, there is no disable option as it’s greyed out.
I’ve looked in the settings and detect-internet settings are set to none. I’ve seen a reference for older router software where you could add a line to manually disable this but don’t know if that is still a viable option?
You don't change the distance for those route in the IP -> Routes table, but change it by modifying the Default Route Distance property of the DHCP clients:
(this is what I wrote in the 1st bullet point of my previous post).
As for this issue, you'll need to do some scripting in the DHCP client (notice that in the screenshot above, there is a Script field where you can input the script content). Here is the documentation with the available variables:
script (script ; Default: ) Execute script when DHCP client obtains a new lease or loses an existing one, received gateway address or DNS server list is changed.
bound - 1 - lease is added/changed; 0 - lease is removed
server-address - server address
lease-address - lease address provided by a server
interface - name of the interface on which the client is configured
gateway-address - gateway address provided by a server
vendor-specific - stores value of option 43 received from DHCP server
lease-options - an array of received options
And below that you have the Lease script example
You can use that script or use this simplified version adapted to your configuration (this content is to be put inside the Script textbox of the Starlink DHCP client):
:if ($bound=1) do={
/ip route set [find dst-address=8.8.8.8/32] gateway=$"gateway-address";
/ip route set [find dst-address=208.67.222.222/32] gateway=$"gateway-address";
}
This simplified version assumes that you've already have the two routes in the table (no need for the script part that tries to create them new).
jaclaz
March 16, 2026, 9:37am
12
Ahh, now I see
Hopefully:
“We are now cruising at a level of two to the power of twenty-five thousand to one against and falling, and we will be restoring normality just as soon as we are sure what is normal anyway.”
pe1chl
March 16, 2026, 9:46am
13
Actually, there is also a situation where RouterOS dynamically creates DHCP clients that you cannot change and for which only some parameters can be overridden at a difficult to find place.
But that is not for ethernet ports, that is for LTE interfaces. So not what he is facing here.
CGGXANNX
Okay I found the correct location and made the change to the default DHCP distance for Verizon ISP but unfortunately this failover does not work when Starlink ISP goes down. I can ping the 8.8.4.4 from the RB5009UG terminal but PCs connected the router are not getting routed through to the Verizon ISP link even if I reset the router.
As for the other issue I just went ahead and turned off bypass mode for the Starlink router (what a pain that was for the older 2nd gen Starlink). But this way it always gives the 192.168.1.1 address. Of course then had to change my Verizon ISP to 192.168.10.1 instead.
jaclaz
March 16, 2026, 2:10pm
15
The Starlink DHCP client is still with distance 1, and it creates the top DAD+ route, you need to put its distance to 101 (or 99, whatever) so that only the narrow and wide routes get into play (and without the +).
Setting the Starlink DHCP client to 99 did the trick. Failover works perfectly now and recovers correctly too.
Thank you everyone for all the help.
Regards
Andrew
jaclaz
March 16, 2026, 9:23pm
17
Good, now you might want to re-think about the futility of checking connectivity on the secondary (to be used as failover) route.
I will repeat how, given n connections, you only need to check the first n-1 ones as nothing changes whether the last one Is working or not with this "plain" recursive approach.
Makes sense, no need for the extra ping traffic bouncing around if it can’t actually cause any change. So I can get rid of both the 8.8.4.4 and 208.67.220.220 ping checking associated with the Verizon ISP failover Wide routes?
Thanks again,
Andrew
jaclaz
March 18, 2026, 10:45am
19
Yep, as a matter of fact, you can (should) re-join the narrow and wide routes for Verizon into a single one, i.e. from:
/ip route
add comment="Narrow Route" disabled=no distance=1 dst-address=8.8.4.4/32 gateway=192.168.10.1 routing-table=main scope=11 target-scope=10
add check-gateway=ping comment="Wide Route" disabled=no distance=2 dst-address=0.0.0.0/0 gateway=8.8.4.4 routing-table=main scope=30 target-scope=11
to:
/ip route
add comment="Single Route" disabled=no distance=2 dst-address=0.0.0.0/0 gateway=192.168.10.1 routing-table=main scope=30 target-scope=10
I tried this setup and the new route showed up as just S and not AS. In addition the failover was not as seamless as previous setup. It took several minutes before the Verizon ISP route became available for PCs connected to the router.
, we were referring to the DHCP clients, but OP attempted to change the routes generated by the DHCP clients (which being Dynamically created cannot be edited).
