I’m having a small issue with the routing on my Mikrotik LTAP Lr8 and the different connections I want to use. I could potentially “fudge” it using metrics, but unfortunately, that’s not an option because:
LTE1 and the DHCP client have fixed metrics that can’t be changed
LTE1 always has metric 2, and the DHCP client has metric 1, but it needs to be the other way around in my case.
The issue is that the metric won’t work because the gateway of the DHCP client is always available.
Netwatch isn’t an option either because I can’t specify a source interface.
What I want to achieve:
LTE1: Primary connection (O2 flat rate)
Fallback 1: DHCP client (another LTE router with a Vodafone volume plan, Mikrotik HAP)
Alternative to LTE1 (DHCP client): A GLI router is connected here, which connects to known Wi-Fi networks from businesses, campsites, etc., when they are nearby.
Explanation:
The router is installed in my motorhome. The LTE connection with O2 is an EU flat rate, but unfortunately, it frequently drops due to issues with O2. The HAP router is my travel router (without the motorhome), but with only 60GB of traffic – so I only want to switch to it when O2 isn’t working.
At the last connection, there’s a GLI router connected, which knows many networks from businesses, campsites, etc., where I often stay. If it detects such a Wi-Fi network nearby, it connects automatically – and only then does the GLI router have internet access.
So, the goal is to check which connection currently has internet access and switch accordingly.
I’ve tried routing via scripts, but it didn’t work because the DHCP client router only functions when it’s assigned an IP via DHCP – the same applies to LTE. Using metrics doesn’t work because the gateways of the other routers are always reachable.
Netwatch would be a solution if I could specify a source interface – then it would probably be perfect.
Has anyone come up with a way to solve this issue? Any advice would be greatly appreciated!
The usual term (useful if you want to search for related topics) is failover, not fallback.
I am not sure to understand the issue with the Netwatch, can you explain what do you mean by DHCP client?
Is the LTAP the DHCP client or is it the DHCP server?
If the other devices (the Vodafone LTE router and the GLI router) are under your control, surely they can also be made static, one way or the other, can’t they?
The LTAP LR8 router is configured to use two interfaces as DHCP clients, including active NAT. This means the router can access the internet through both connections (LTE1 and DHCP). The other routers I want to use for failover are connected behind this setup, so if one connection fails, it automatically switches to the other.
Regarding Netwatch: What I mean is that while the Netwatch mechanism works in general, it unfortunately doesn’t allow specifying a specific source interface. This means the router cannot distinguish from which interface it’s getting internet if multiple interfaces are available at the same time.
To clarify whether the LTAP is a DHCP client or server: The LTAP is acting as a DHCP client, obtaining IP addresses from the gateways of the other routers (like the Vodafone LTE router or the GLI router).
The other devices (Vodafone LTE router and GLI router) are under my control. However, I don’t want these routers to have static IPs because they often need dynamic IPs to connect to changing networks (e.g., when connecting to Wi-Fi networks in various campsites or businesses). That’s why it’s a challenge for me to set up efficient switching.
I hope this explains the setup better! If you have any questions or have another solution in mind, feel free to let me know.
You can just change the default-route-distance= in APN to 1 and change then in /ip/dhcp-client set the default-route-distance=2. That will make LTE 1st priority, and DHCP 2nd.
With just those settings, the DHCP will take over if the LTE interface if not in running state. Now that’s not quite same as all cases of “internet is down”. But first step here be getting the default-route-distance right.
While in DHCP client, you can now enable “check-gateway” – which adds a ping check of the provided gateway. You cannot do same with LTE APN. But you can enable a ping check of the gateway via a route filter rule that add it to “dynamic” route from LTE or DHCP using the following in 7.19+ :
Beyond that, you could add monitoring some host on internet to trigger failover. But this does get more complex with dynamic addresses. But two main ways of doing the netwatch and recursive routes. Both are discussed elsewhere in forum and somewhat in docs.
On using Netwatch… it does not let you directly pick an interface to test directly. So only way to do that is indirectly by using a routing table and rule to force the netwatch monitored hosts to always use a route table with only LTE in it.
I am not yet sure to have completely understood the issue, but if the Mikrotik is the DHCP client, besides being able to modify the distance of the (0.0.0.0/0) route provided by the DHCP server, you can have a DHCP client script that creates and adds to the routing table a new “narrow” route to a reliable DNS (let’s say 1.1.1.1/32) using the same gateway-address (provided by the server).
At this point any Netwatch will be able to distinguish the connection by dst-address (as opposed to source interface).
The suggested changes to the default-route-distance and DHCP client settings work well for prioritizing LTE and DHCP. This setup ensures LTE is the primary connection and DHCP is the fallback, which stabilizes the routing when the LTE connection fails. However, the issue remains that I can’t directly test the availability of the internet, as I’m always pinging the IP address 8.8.8.8. A ping to this address doesn’t prove that the internet is actually available, it only shows that there’s a connection to Google’s DNS, but not necessarily that the entire internet connection is functional.
The fact that the main router gets an IP address assigned by the DHCP client, and then performs NAT, is also important. So, if the GLI router connects to a known Wi-Fi network, it might think it has an active internet connection, even if that Wi-Fi network doesn’t actually provide full internet access. It would assume that the nearest gateway (the Wi-Fi) is available and route traffic, which in this case would be incorrect.
Regarding the Netwatch approach: It’s difficult to perform a reliable check since the gateway is dynamically assigned by the DHCP client and there is no static IP I can monitor. Netwatch doesn’t work because it can’t access a source interface, and there’s no way to reliably verify internet availability, since all gateways (even the ones from the GLI router) are always reachable when a Wi-Fi network is nearby.
The idea of adding a “narrow route” to a reliable DNS address like 1.1.1.1/32 might theoretically work, but since the routes are dynamic and change depending on the DHCP client, this approach wouldn’t be reliable enough either. As you mentioned, the “dynamic” routes assigned by the DHCP client cannot be manually adjusted, which makes the setup even more complex.
I think the biggest issue is that the router “thinks” a connection exists as long as the next gateway is reachable, even if it doesn’t offer a working internet connection.
Do you have any further suggestions, or is there a way to influence the routing table dynamically so that it only becomes active when the internet is genuinely available?
I’ll try explaining it again, hopefully in a clearer way this time:
In my motorhome, I have a fixed LR8 router installed. It has an LTE SIM card with a flat rate.
Internet Connections:
First Internet Option:
vlan9_dhcp_inet_master
Configuration in LR8: DHCP Client with NAT.
Here, I have a GLI router that searches for known Wi-Fi networks and connects to them as a client. If a ping is successful, the internet should switch over to this connection.
The GLI router is a DHCP server, and the default route is assigned via DHCP.
Second Internet Option (Usually Active):
LTE SIM card (built-in). This is the primary internet connection.
Third Option:
vlan10_dhcp_inet_failover
Configuration in LR8: DHCP Client with NAT.
Here, the LR8 gets an IP address from a HAP router, but this should only be used as a fallback since it uses a volume-based plan.
Problems:
Metric issue:
The metric doesn’t work because, in the first option, the GLI router is reachable even though it doesn’t actually have internet. This makes it appear as if the connection is active, but no internet is actually available.
Netwatch:
In order to check whether the first or second option has internet access, I would need to specify a source interface for the ping in the network settings. But this is not possible at the moment.
Check Gateway in Route:
Using “check gateway” in the routing table doesn’t work either because the route is dynamically assigned by the DHCP server and can’t be changed in the LR8.
I prefer to use DHCP to avoid IP conflicts, especially because some of the routers I use for failover are often leased by my employer, and they operate on different IP networks.
I hope this explanation makes the situation clearer!
We are still not understanding each other, let’s see if I can explain better the idea.
A DHCP client has two possible states:
not bound ( bound=0), the client has not received (yet) an IP address
bound (bound=1), the client has asked an IP to the server and obtained one, and at the same time received also a gateway address, a default route and its distance
The initial state Is obviously the first, when the state changes, the DHCP client can be set to run automatically a script.
At the time the script Is run besides the assigned IP the gateway is known, so this script could:
a. delete a (possible existing) route with dst-address=1.1.1.1/32
b. add a new route with dst-address=1.1.1.1/32 with the gateway address just received by the DHCP server.
Netwatch will use the route present in the routing table to attempt to reach 1.1.1.1, which will have the current gateway.
The first way to get internet is through DHCP, where the router receives an IP address from the DHCP server. Unfortunately, I don’t know which IP address the DHCP server assigns me, so I can’t control this via Netwatch.
Another issue I noticed yesterday: When the interface is active but not connected, the “Detect Internet” function still shows that internet is available on that interface. This causes the LTE connection to fail frequently, likely because the router tries to route through the DHCP interface with the lower metric. This results in the router not switching to the LTE connection, even though it should be the preferred option.
Additionally, there is no “Interface down” because both DHCP client ports are VLANs that are connected to a switch, and the router only has one LAN port.
Therefore, I actually need a failover mechanism that isn’t based on metrics, but instead ensures that real internet is available on the interface. Once that condition is met, I can prioritize in the order as initially described (LTE → Failover → other options).
Your device IP is only part of the data received by the DHCP server.
Your DHCP client gets:
IP address
default route (and gateway address)
distance of the default route
DNS address
BUT Netwatch DOES NOT need to know your IP address.
All it wants to know/have is a valid route to the destination (watched) IP.
This (narrow) route can be added on the fly to the route table by a DHCP script triggered by the bound condition, i.e. as soon as the DHCP client receives the data from the server, additional to the default 0.0.0.0/0 route provided by the DHCP server.
About using detect internet, it is a serious violation of Rule #5:
I now understand that Netwatch doesn’t need the device’s IP address, but rather a valid route to the monitored IP. If I add an IP like 8.8.8.8 (Google DNS) or 1.1.1.1 (Cloudflare DNS), Netwatch should be able to use this to monitor the connection and ensure that internet access is available.
The default route from the DHCP server tells me which gateway to use, but it doesn’t give me information about whether there’s an actual working internet connection on that interface. So, even if the gateway is reachable, the internet throughput might still not be working.
If I remove the DHCP server router, the connection will remain active until the lease expires, right? As long as the lease is active, the router will keep the assigned IP address. Once the lease expires, the router will need to contact the DHCP server again to obtain a new IP address.
Well, but the DHCP client (your LTAP) can remove its own address (release) and ask for a new one, like:
but I don’t understand, you should have (from what I have understood of your intended setup) two or more WAN ports, each one running its own DHCP client, and connected to a separate router and DHCP server.
So you have two (or more) DHCP clients:
running on ether1 connected to router1 and getting its IP address (as an example) 192.168.1.2 from the DHCP server 1 running on router1
running on ether2 connected to router2 and getting its IP address (as an example) 192.168.2.2 from the DHCP server 2 running on router2
running on …
Each of these DHCP client will have a DHCP script adding to the route table a “narrow” route to a DIFFERENT endpoint:
route through gateway address 1 (192.168.1.1) to 1.1.1.1/32
route through gateway address 2 (192.168.2.1) to (say) 9.9.9.9/32
route through …
Then you will have several netwatch scripts:
Netwatch probing 1.1.1.1/32
Netwatch probing 9.9.9.9/32
Netwatch probing …
Each Netwatch down script should with the “down” script “promote” the “next” route (or “demote” its own corresponding “wide” 0.0.0.0/0 route) and with the “up” script “promote” its own corresponding “wide” 0.0.0.0/0 route (or demote the “next” one).
With two routers/WAN ports you need only one of these, with three you need two, and so on (when you have reached the last one it makes no sense to probe it, as you have not any alternative left).
@jaclaz, Could be wrong here but I think OP’s primary is the LTE interface, not DHCP client. The DHCP client is on the backup internet So there is no DHCP script on the primary LTE address assignment in that case.
Yep, I was trying to explain the general mechanism, before going into the details of the specific implementation.
I am not familiar with what the LTE interface exposes, but I don’t see why one could not mix the recursive approach you suggested for the LTE to Netwatch for the other connections.
Actually, I thought this could be solved on MikroTik without scripting. Unfortunately, I can’t script, or rather, I’m just starting to learn. I would prefer a configuration that can be managed through Winbox, so even colleagues who aren’t familiar with scripting can understand the setup.
My motorhome is just a test – my personal playground, so to speak. For customer setups, we often deal with routers from providers, where a router is provided, and we simply connect a MikroTik behind it.
In these cases, the MikroTik should receive an IP on ether1, and on ether2, we connect an LTE router (again using DHCP client). We have a pool of routers which we send to customers via express delivery.
I’m honestly a bit disappointed that this isn’t a built-in feature. I’ve now ordered a GLI router just to check it out since I’m already quite impressed with my travel router, the MUDI. The GLI works the way I want it to right out of the box.
It would be really great if MikroTik could implement a script-free failover solution as well.
Thanks to everyone for your help, and I’m definitely a bit further along with my setup now. Scripts are cool, but they’re not ideal when even non-professionals need to understand the configuration.
MikroTik remains my favorite for this project. Let’s see, maybe MikroTik will come up with a proper solution in the future!
Which translated in plain language equates to:
Whenever a new IP address is provided by the DHCP (bound=1) find the route (if any) with that comment “ether1_canary” that also has a different gateway (from the one that the DHCP server just gave you) set, and if you find it (gateway"!=$gw) replace the gateway in the route with the gateway just sent by the DHCP.
You go in Winbox and in your IP DHCP settings select the interfacem double click to open the settings, then ADVANCED and you can paste in the “Script” textbox the above.
of Rule