Recipe: LTE as a backup line

The goal: when your fixed line fails, traffic moves to LTE within half a minute and moves back on its own afterwards. The hard part of failover is not the configuring, it is the testing: you want to know it works before you need it, rather than find out it does not at the moment you are counting on it.

What you need

• A device with a built-in modem (Chateau, LtAP, SXT LTE) or a USB modem.
• A SIM with data and your carrier's APN. Usually internet; business plans sometimes have their own, with a username and password.
• Somewhere the antenna has signal. A modem in a meter cupboard behind concrete is not a backup line.

Step 1: the device

If the model you picked has a modem, lte1 is in the port list already. For a USB modem in a router without one, choose Other device when picking your hardware, fill in the ports and switch on LTE modem. Then lte1 is offered there too; that is the name RouterOS gives the first modem.

Step 2: the second uplink

1. Go to WAN / internet. The first row under Uplinks is your fixed line: leave Route distance at 1.
2. Add an uplink. Set Port to lte1 and Type to LTE / 5G modem.
3. Fill in the APN, and only if your carrier asks for them also APN user, APN password and APN authentication.
4. Set Route distance to 2. Higher is less attractive, so that route is only used once the first one is gone.
5. Leave Use ISP DNS on for at least one uplink, otherwise during an outage you have a route but no name resolution.

The tool writes an APN profile for the modem and binds it to the LTE interface, with allow-roaming=no. That avoids accidental roaming charges, but it also means you have to switch roaming on yourself on the router if you want that SIM to work abroad.

Step 3: pick a failover method

Failover method appears as soon as there are two uplinks.

• Distance + gateway check. Two default routes with distance 1 and 2, and a Gateway check per uplink (ping or arp). Simple and predictable. Its weak spot: it only asks whether your ISP's gateway answers. If that still answers while the internet behind it is gone, nothing switches.
• Recursive. The tool writes a route to a probe address through each uplink's gateway, plus a default route that runs via that probe address. When the probe stops answering the default route disappears and the next one takes over. That tests the whole path out instead of only the first hop.
• Load balancing (PCC). Spreads traffic over both lines at once. That is a different thing from a backup line, and rarely what you want with a metered SIM.

For recursive, fill in Probe address uplink 1 and Probe address uplink 2; 1.1.1.1 and 9.9.9.9 by default. Use two different addresses run by different parties. Pick the same one twice and you are testing nothing.

Recursive failover needs each uplink's gateway address, and on a DHCP uplink that is not known while generating. The tool warns about it and puts a placeholder in the route. Replace it with the real gateway address after pasting, or use the distance method.

Step 4: keeping an eye on the data

Honestly: the tool has no counter, no quota and no data limit field. Once LTE takes over, everything on your network uses it, cloud backups and updates included. What you can do:

• Under High availability, add a host to Netwatch, for instance your probe address, with Interval 30s and a Script on down such as /log warning "primary WAN down, LTE active". Then the log tells you when it happened and how long it lasted.
• Switch on e-mail under Services & tools if you want a message rather than a log line.
• On the router, use /interface lte monitor lte1 for signal and status, and /interface print stats for the bytes over lte1.
• Arrange the hard ceiling with your carrier, not on the router. A bundle that slows down when it runs out beats an invoice.

Step 5: testing without locking yourself out

Do not pull the cable on a router you can only reach through that same cable. Do it like this:

1. Log in over the LAN, not from the WAN side, and certainly not through a VPN that runs over the line you are about to switch off.
2. Put a safety net in place first, so a mistake undoes itself: /system scheduler add name=restore-wan interval=5m on-event={/interface enable ether1}
3. Disable the primary uplink: /interface disable ether1. With PPPoE, that is the PPPoE interface.
4. Check /ip route print to see which default route is active. The LTE route should now be there without the inactive flag.
5. Run /ping 1.1.1.1 from the router and open a website from a laptop on the LAN.
6. Bring the uplink back with /interface enable ether1 and confirm the route falls back to the fixed line. Then remove the safety net from the scheduler.

Test the LTE line on its own once, before all of this: give it distance 1 temporarily, or switch the fixed line off, and see whether the SIM gives you internet at all. A failover to a line that never worked is not a failover.

What to watch out for

• CGNAT. Most mobile plans hand out an address behind carrier-grade NAT. During an outage your VPN endpoint will not work, and neither will port forwards: incoming connections do not arrive. IP Cloud DDNS follows the address but does nothing about CGNAT. If you need incoming traffic during an outage, ask your carrier for a public address on that SIM.
• Existing connections break. Switching over changes your outgoing address, so sessions in progress drop. That is normal and not avoidable.
• NAT comes along. The masquerade rule applies to the whole WAN interface list, and both uplinks are in it, so traffic over LTE is translated as usual.
• QoS does not fully follow the failover. With the priorities method (queue tree) the upload queue hangs on the first WAN interface; the second one is not shaped. The tool warns about this.
• Setting the gateway check to none means the route stays active forever and nothing ever switches. Leave it on ping.

Related: Multi-WAN, WAN / internet and Netwatch.