Sanity Check / recursive Routing config

RouterOS Beginner Basics
1

Hi Guys,

wow what an emotion to create my first thread on the new forum :slight_smile:

the config seems to be working perfectly, I chose 8.8.4.4 & 1.1.1.1 as check route.

take a look at the config i created on the L009 Router , for test.

this config will be replicated on my RB5009.

this is working fine , hjust wanted an expert sanity check to make sure all is at the state of the art!

# 2025-06-13 17:41:59 by RouterOS 7.19.1
# software id = **ELIDED**
#
# model = L009UiGS
# serial number = 
/interface bridge
add admin-mac=xxxxxxxxxxxx auto-mac=no comment=defconf name=bridgeLocal
/interface ethernet
set [ find default-name=ether1 ] name=ether1_WAN_1
set [ find default-name=ether2 ] name=ether2_WAN_2
set [ find default-name=ether8 ] name=ether8_MGMNT
/ip pool
add name=dhcp_pool0 ranges=10.10.10.20-10.10.10.200
add name=dhcp_pool1 ranges=172.20.3.20-172.20.3.200
/ip dhcp-server
add address-pool=dhcp_pool0 interface=ether8_MGMNT lease-time=1d name=dhcp1
add address-pool=dhcp_pool1 interface=bridgeLocal lease-time=1d name=dhcp2
/port
set 0 name=serial0
/interface bridge port
add bridge=bridgeLocal comment=defconf interface=ether3
add bridge=bridgeLocal comment=defconf interface=ether4
add bridge=bridgeLocal comment=defconf interface=ether5
add bridge=bridgeLocal comment=defconf interface=ether6
add bridge=bridgeLocal comment=defconf interface=ether7
add bridge=bridgeLocal comment=defconf interface=sfp1
/ip address
add address=172.22.2.10/24 interface=ether1_WAN_1 network=172.22.2.0
add address=192.168.1.10/24 interface=ether2_WAN_2 network=192.168.1.0
add address=10.10.10.1/24 interface=ether8_MGMNT network=10.10.10.0
add address=172.20.3.1/24 interface=bridgeLocal network=172.20.3.0
/ip dhcp-client
add comment=defconf interface=bridgeLocal
/ip dhcp-server network
add address=10.10.10.0/24 dns-server=8.8.8.8,1.1.1.1 gateway=10.10.10.1
add address=172.20.3.0/24 dns-server=8.8.8.8,1.1.1.1 gateway=172.20.3.1
/ip firewall nat
add action=masquerade chain=srcnat log=yes
/ip route
add disabled=no distance=1 dst-address=8.8.4.4/32 gateway=172.22.2.1 \
    routing-table=main scope=10 suppress-hw-offload=no target-scope=10
add disabled=no distance=1 dst-address=1.1.1.1/32 gateway=192.168.1.1 \
    routing-table=main scope=10 suppress-hw-offload=no target-scope=10
add check-gateway=ping disabled=no distance=1 dst-address=0.0.0.0/0 gateway=\
    8.8.4.4 routing-table=main scope=30 suppress-hw-offload=no target-scope=\
    11
add check-gateway=ping disabled=no distance=2 dst-address=0.0.0.0/0 gateway=\
    1.1.1.1 routing-table=main scope=30 suppress-hw-offload=no target-scope=\
    11
/system clock
set time-zone-autodetect=no time-zone-name=Europe/Rome
/system ntp client servers
add address=pool.ntp.org
add address=it.pool.ntp.org
/system routerboard settings
set enter-setup-on=delete-key
2

Couple of things:

  • Where is your firewall?
  • Why do you have a DHCP client on your bridge?
  • Sure you want all masquerade logged?
3

the bridge has DHCP server bound to it as does the port 8 for management..

no i didn’t create any Firewall rule as i’m using actually next generation firewalls as protection.

should io create a firewall rule anyway? can you help?

Agree i don’t need all masquerade logged!!

4

This is the part I was referring to:

Up to you to decide wether you need firewall rules or not. Perhaps you can explain what you are trying to accomplish with the Tik?

5

Yes, saw that not sure how that client got there.. I don’t remember configuring it.. :slight_smile:

as mentione, I’m trying to accomplish recursive routing based on the two routes, and seems to be working , but thanks for the heads up of that client

I will completely reset now the config of the L009 as this was just a test to make sure it was working and will configure on the RB5009.

6

Ok I think I figured out how that clienbt got on the bridge!!

I had factory reset the L009 and in fact the Bridge was already configured but didnt check d%eeply the other configs , therefore there must have been the Client DHCP configured on the bridge after the factory reset, and i missed it..

thanks again for this heads up this is a reminder to always check deeply the configs after any reset!

7

My take on recursive setup:
/ip route
add check-gateway=ping dst-address=0.0.0.0/0 gateway=8.8.4.4 routing-table=main scope=10 target-scope=12
add check-gateway=ping distance=2 dst-address=0.0.0.0/0 gateway=1.1.1.1 routing-table=main scope=10 target-scope=12
add dst-address=8.8.4.4/32 gateway=172.22.2.1 routing-table=main scope=10 target-scope=11
add distance=2 dst-address=1.1.1.1/32 gateway=192.168.1.1 routing-table=main scope=10 target-scope=11

8

Thanks for the heads up for the clean config!

will test on the RB5009 in the following weeks!!

9

The problem with the simplistic approach is that you make the entire routing reliant on the specific IP address being up and supporting ping forever.
It is possible to use 2 levels of recursive routing so you are checking 2 addresses on each ISP (e.g. 8.8.4.4 and 1.0.0.1 on one ISP and 8.8.8.8 and 1.1.1.1 on the other) and as long as 1 of the 2 is reachable the route is used.
It is described somewhere here on the forum, hopefully it is still possible to find it.

10

this sounds interesting but isn’t it too much to have two checks per route? I mean it’s google and cloudflare.. if they go down the internet is down :slight_smile:

11

I highly doubt that.
Factory reset on L009 puts DHCP client on ether 1. NOT bridge.

12

heey my friend…

here we are on this clunky new forum, well let’s get used to it and help them fix any bugs..

back to topic, after the factory reset the bridge was configured with all the ports already on it, I actually thought that it was going to wipe clean the config.

anyhow , I have already reset the config from the internal system and configured as normal router.

13

Well, what I encountered before is that one of them suddenly did not reply to ping at least via one ISP (probably some routing problem in the ISP) and then this entire ISP was not used, while other destinations were reachable. Then I found and implemented that 2-level approach, although I am not completely sure if it was on the (old) forum or on the manual site (help.mikrotik)
It has since worked well, also for IPv6, even when there was another failure at the ISP where Google wasn’t working but Cloudflare was.

14

thanks for this information,

I guess it’s a risk to take with such an implementation?

15

FLAT APPROACH to having to DNS sites checked per WAN.

/ip route
add check-gateway=ping dst-address=0.0.0.0/0 gateway=8.8.4.4 routing-table=main scope=10 target-scope=12
add check-gateway=ping distance=2 dst-address=0.0.0.0/0 gateway=1.1.1.1 routing-table=main scope=10 target-scope=12
add distance=3 check-gateway=ping dst-address=0.0.0.0/0 gateway=9.9.9.9 routing-table=main scope=10 target-scope=12
add distance=4 check-gateway=ping dst-address=0.0.0.0/0 gateway=208.67.222.222 routing-table=main scope=10 target-scope=12
+++++++++++++++++++++++++++++
add dst-address=8.8.4.4/32 gateway=172.22.2.1 routing-table=main scope=10 target-scope=11
add distance=2 dst-address=1.1.1.1/32 gateway=172.22.2.1 routing-table=main scope=10 target-scope=11
add distance=3 dst-address=9.9.9.9/32 gateway=192.168.1.1 routing-table=main scope=10 target-scope=11
add distance=4 dst-address=208.67.222.222/32 gateway=192.168.1.1 routing-table=main scope=10 target-scope=11

NESTED APPROACH
( need a faux not used address in the mix )
admins can accomplish the same effect as the “flat” approach above by layering or nesting the recursive routes with each other with the same outcome. This is a more complex setup but is deemed to be more efficient overall especially if using multiple routing tables (academic and not required for new users). It is included for those interested. The tricky part is that we will use an address that really doesn’t exist to force the router to look for a routing, in this case randomly choose 10.10.10.10/32. Thus we create a top rule with no apparent path and then recursively look for a path through both DNS addresses which then are resolved by the direct route through the ISP gateway. So although it appears we are using three Other addresses in nested recursive routing we are still only using 2 KNOWN DNS addresses and one 'BOGUS" address. The bogus address is used to force the router to be recursive for both the KNOWN Dns addresses. In other words, the flat approach is Recursive to Resolving (two steps), nested is Recursive to Recursive to Resolving (three steps).

/ip route
{ faux address }
add dst-address=0.0.0.0/0 gateway=10.10.10.10 scope=10 target-scope=13
++++++++++++++++
{ WAN1 }
add distance=2 check-gateway=ping dst-address=10.10.10.10/32 gateway=8.8.4.4 scope=10 target-scope=12
add distance=2 dst-address=8.8.4.4/32 gateway=172.22.2.1 scope=10 target-scope=11
+++++++++++++++
add distance=3 check-gateway=ping dst-address=10.10.10.10/32 gateway=1.1.1.1 scope=10 target-scope=12
add distance=3 dst-address=1.1.1.1.1/32 gateway=172.22.2.1 scope=10 target-scope=11
++++++++++++++++
{ WAN2 }
add distance=4 check-gateway=ping dst-address=10.10.10.10/32 gateway=9.9.9.9 scope=10 target-scope=12
add distance=4 dst-address=9.9.9.9/32 gateway=192.168.1.1 scope=10 target-scope=11
++++++++++++++
add distance=5 check-gateway=ping dst-address=10.10.10.10/32 gateway=208.67.222.222 scope=10 target-scope=12
add distance=5 dst-address=208.67.222.222/32 gateway=192.168.1.1 scope=10 target-scope=11

16

so basically the Flat approach is checking 2 DNS per each WAN, and so I’m actually not losing the ISP(WAN1) if 8.8.4.4 stops getting pinged because i then default to 1.1.1.1 on the same WAN 1 and so on and so forth. so If I lose both DNS then surely the ISP is down!a nd we swiotch to WAN 2!

I think I will keep the FLAT approach for now!