[Solved] Dual WAN set-up, just need final piece of guidance

Hi all,

So I’ve followed along with https://www.youtube.com/watch?v=iA3yDMDZ-20, and transcribed to paper - hopefully correctly.

Right now I don’t have a DHCP fibre connection to test against, so I’m hoping someone will be able to help me by looking at my route config below.

But first, some background…

I’m testing this on a Chateau LTE6 device. I have removed ether1 from the bridge and assigned it as WAN (along with the existing lte1). I’ve also set up a DHCP client for ether1, and, because NZ providers insist on running vlan10 over WAN, I’ve also included that.

When an active LTE connection is present, it rightfully shows the provider’s public IP, but also adds another entry I’ve labelled ‘1’ on the pic above.

My concern is that this entry might conflict with what I’ve labelled ‘2’, because both have a distance of 2 and ‘1’s distance can’t be changed. I hope this makes sense.

‘1’ disappears when the LTE connection has been disabled (along with the public IP), but returns when re-enabled.

Thanks in advance.

You can try to increase the value of default-route-distance in your /interface lte apn profile, or turn off add-default-route on the profile.

  • add-default-route (yes no) Whether to add a default route to forward all traffic over the LTE interface.
  • default-route-distance (integer; Default: 2) Sets distance value applied to auto-created default route, if add-default-route is also selected. LTE route by default is with distance 2 to prefer wired routes over LTE

Thank you @CGGXANNX . Much appreciated. I’ll have a decent read of that document. I’ve raised it to 3 now. Should this now work once I plug into fibre on ether1? And then swap over to lte1 when ether1 is unplugged? Cheers.

If you intend to have your future WAN (on ether1) as the main internet connection, and lte1 is failover then you can set default-route-distance=3 or higher like 10 and it will be enough.

But these entries should be removed too:

Because lte1 is failover for when the main WAN fails, you don't need to setup checks with recursive routing for lte1.

Beside that, if your main WAN will be on vlan10 like you wrote, then the current route using ether1 is not correct. You will have to create a vlan10 VLAN interface on top of ether1, then in your static routes you should refer to vlan10 instead of ether1.

Does this make more sense…

I’m puzzled now. If the fibre on ether1 drops out, how will will the router know where to find lte1 now it’s IP 10.2.2.2 doesn’t exist? Or does it somehow know where else to find it?

> ip route/print
Flags: D - DYNAMIC; I - INACTIVE, A - ACTIVE; c - CONNECT, s - STATIC, m - MODEM
Columns: DST-ADDRESS, GATEWAY, ROUTING-TABLE, DISTANCE
#     DST-ADDRESS       GATEWAY   ROUTING-TABLE  DISTANCE
;;; Rule #1
0  Is 0.0.0.0/0         1.1.1.1   main                  1
;;; Rule #1
1  Is 0.0.0.0/0         8.8.8.8   main                  2
  DAm 0.0.0.0/0         lte1      main                  3
;;; Cloudflare DNS
2  As 1.1.1.1/32        10.1.1.1  main                  1
;;; Google DNS
3  As 8.8.8.8/32        10.1.1.1  main                  1
4  Is 10.1.1.0/24       vlan10    main                  1
  DAc 122.63.22.131/32  lte1      main                  0
  DAc 192.168.88.0/24   bridge    main                  0

Yes, like this. Of course in the future, once you have your fiber connection, you will need to adjust the 10.1.1.0/24 and 10.1.1.1 values in your static routes to match the gateway and subnet provided by the fiber ISP.

The 10.2.2.2 address is not needed for lte1 (and is probably also wrong). If you look at your old screenshot where you had the 10.2.2.2 recursive check, notice that the check didn't work anyway. The route has the I (inactive) flag:

Because 10.2.2.2 is not an address that you can reached via the lte1 interface (I assume you copied that from the video example?).

What currently really active, is the default route:

And I assume you currently have working internet connection through LTE? In your case lte1 (similarly to pppoe-out1 with PPPoE) is like a P2P link, the gateway is the other side of the link and doesn't need to be specified with an IP address like with DHCP. The gateway being lte1 (or pppoe-out1) is enough.

Thanks again, it makes sense now.

What if my ISP assigns fibre IP addresses dynamically?

You'd use a DHCP client script that uses the $"gateway-address" variable to set the [recursive] static routes. And set the default-route distance to higher number or just set add-default-route=no in the /ip/dhcp-client.

2 Likes

Any idea where I might find such a DHCP script please? I’m concerned if I start googling I’ll find many different iterations that don’t work. Lol.

Yes, like @Amm0 wrote, you'll write a script that update the route table. MikroTik has an example in the documentation (the variable name is gateway-address):

In your case it's best that you put unique comments on the routes (the same that currently have 10.1.1.1 and 10.1.1.0/24) and update them by looking for the comment [find].

1 Like

Thank you. Much appreciated!

At the risk of sounding lazy, I guess the other option would be a static IP from my fibre provider?

I’ve just checked that doc and my anxiety levels went up a notch or 3. There’s a lot to digest and no real explanation as to what each part of the script does, therefore it’s just a cut and paste and you don’t really learn anything.

Don’t get me wrong, I’m thankful for the example script. But without any understanding with what’s actually going on inside the script, I may as well just pay a little more each month to my ISP for a static IP, and live a slighlty more stress-free life.

Thanks for all your help guys. Very much appreciated!

You don't need the script when the gateway address of the ISP does not change (the IP address that they give you might change, but the gateway address is the same). It might be like that for some ISP, but it's more probable that the gateway address does change.

As for the script: You put it in the script property of the DHCP client entry, and the script will be executed both when you get a new leases, or when you lose the current lease. That's why there is first a check for $bound=1.

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.
Variables that are accessible for the event script:

  • 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

Because you only need to update the gateway when you get a new lease, not when $bound=0.

At the top of the script a variable is defined that contain the name of the route table that will be updated, but in your case, you only need to update the main table.

The line

:local count [/ip route print count-only where comment="WAN1"]

counts how many route in the table has the WAN1 comment and save the number in the $count variable.

Later you can see this value is compared to 0, if it's zero, then the route is added. In your case, you probably don't need this part, because you have already added the two routes manually by hand, these two routes:

So you won't need to check if $count=0 to add them anymore.

When $count is not 0 then the code in the else branch is executed. Here if $count=1 then:

  • The current route entry with the comment is load into the variable $test:

     :local test [/ip route find where comment="WAN1"]
    
  • Its current gateway value is read and compared to the value of the $"gateway-address" variable passed down by the DHCP client:

    :if ([/ip route get $test gateway] != $"gateway-address") do={
    
  • When they are not the same (the != check) the comment that set the gateway is executed:

    /ip route set $test gateway=$"gateway-address"
    

The script assumes only one route exists with the comment (then the check for $count=1) if there are more, then it raises the error with:

:error "Multiple routes found"

However, in your case, you do have two routes to update, so the whole check with $count=1 is not suitable. Instead you can update all the routes that match the comment, without the need to check for $count=1.

If you put the comment "Fiber recursive" on the two routes with dst-address=8.8.8.8/32 and dst-address=1.1.1.1/32 that I quoted above, then your whole lease script can be simplified to this:

:if ($bound=1) do={
    /ip route set [find where comment="Fiber recursive"] gateway=$"gateway-address"
}
1 Like

as an example I do the above for both one of my wan connections.......
here I have two recursives for the primary WAN.
Location script area under advanced in IP DHCP client.

:if ($bound=1) do={
:local gw $"gateway-address"
/ip route set [ find comment="PrimaryRecursive" gateway!=$gw ] gateway=$gw
/ip route set [ find comment="SecondaryRecursive" gateway!=$gw ] gateway=$gw

What they dont tell you is in IP DHCP client say yes to add default route, but on the advanced page to put the distance to 254 ( in other words, due to distance the default route will never be used but we dont care as the important part is that the router installs the new values as per the script, when the gatewayIP changes).

/ip route
add check-gateway=ping disabled=no distance=3 dst-address=0.0.0.0/0 gateway=1.0.0.1 routing-table=main scope=10 target-scope=12
add check-gateway=ping disabled=no distance=4 dst-address=0.0.0.0/0 gateway=9.9.9.9 routing-table=main scope=10 target-scope=12
add comment=PrimaryRecursive disabled=no distance=3 dst-address=1.0.0.1/32 gateway=current-gateway-ip routing-table=main scope=10 target-scope=11
add comment=SecondaryRecursive disabled=no distance=4 dst-address=9.9.9.9/32 gateway=current-gateway-ip routing-table=main scope=10 target-scope=11
add disabled=no distance=10 dst-address=0.0.0.0/0 gateway=ISP2-gateway-IP routing-table=eastlink_direct scope=30 target-scope=10

1 Like

Good point on using gateway!=$"gateway-address" so it does not update it with the same value since it's unclear if does re-write configure to flash for updates.

@anav, you could also get by with using same comment as @CGGXANNX suggests on both in one /ip/route/set since the [find] can return a list of routes, and the set gateway will be applied to all found routes at same time.

1 Like

Yup. The DHCP client does add yet another step, and the config does become more bespoke. The config is more "readable" if you have a static IP, since that appears in export, etc and no chance of scripting error.

One thought is if you have multiple routers, homelab, or otherwise "fiddle" with networks, some providers offer /29 (5 useable IPs) so you get multiple public IPs and typically those are statically defined.

1 Like

Concur AMMO, its what I would do, up to the OP if he wants to have two script rules or just one.
The only reason to use two names would be if applying a script to each WAN.

1 Like

Thanks guys! I really appreciate the effort to help me here. I look forward to digesting it all when I have a little more uninterrupted time at home. There’s a bit to take in. Again, much appreciated!

One more question.

So I paid the prepaid meter and connected the chateau to the internet via LTE (remember it’s the failover when fibre drops out, and I don’t have fibre yet so not connected). It works fine. But when I check the route table, I note that lte1 is not alone…

> ip route print
Flags: D - DYNAMIC; I - INACTIVE, A - ACTIVE; c - CONNECT, s - STATIC, m - MODEM
Columns: DST-ADDRESS, GATEWAY, ROUTING-TABLE, DISTANCE
#     DST-ADDRESS      GATEWAY   ROUTING-TABLE  DISTANCE
;;; Rule #1
0  As 0.0.0.0/0        1.1.1.1   main                  1
  D m 0.0.0.0/0        lte1      main                  3
;;; Rule #1
1   s 0.0.0.0/0        8.8.8.8   main                  2
;;; Cloudflare DNS
2  As 1.1.1.1/32       10.1.1.1  main                  1
;;; Google DNS
3  As 8.8.8.8/32       10.1.1.1  main                  1
4  Is 10.1.1.0/24      vlan10    main                  1
  DAc 122.63.25.16/32  lte1      main                  0
  DAc 192.168.88.0/24  bridge    main                  0

Is the 0.0.0.0/0 8.8.8.8 part supposed to be working? Or is that just monitoring for when the fibre is reconnected? Am I wrong in assuming blue text indicates a working route?

Cheers.

Hmm. Maybe need the full config to say for sure... Since you don't have fiber, it's routing via vlan10, not the eventual ether1 which may still be going out LTE since it may still be NAT masquerade'd. But need to config to say anything definatively.

You can look at /ip/firewall/connections while pinging something other than google/cloudflare. That will show the connection and IPs involved.

Also using /routing/route print is more accurate than a WinBox4 screenshot (since it does not always update state quickly). You might want to post the output of /routing/route print and make sure the terminal window is wide, so all the field like intermediate gateway is show

No, it means it's inactive route, so blue means not working