I get the general flow of what’s happening, however I hope someone can fill two blanks for me:
First thing - about the recursive routes themselves, are defined as following in the official tutorial:
# Now configure routes that will be resolved recursively, so they will only be active when they are reachable with ping:
/ip/route/
add distance=1 gateway=8.8.8.8 routing-table=to_ISP1 target-scope=11 check-gateway=ping
add distance=2 gateway=8.8.4.4 routing-table=to_ISP1 target-scope=11 check-gateway=ping
# Configure similar recursive routes for the second gateway:
/ip/route/
add distance=1 gateway=8.8.4.4 routing-table=to_ISP2 target-scope=11 check-gateway=ping
add distance=2 gateway=8.8.8.8 routing-table=to_ISP2 target-scope=11 check-gateway=ping
From what I see here, now we have two default gateways with distance 1 - 8.8.8.8 & 8.8.4.4 (and two other with distance 2 - 8.8.4.4 & 8.8.8.8 ) - why don’t we end up with ECMP (Equal-cost multi-path routing)? Also, why do we even set 4 default gateways? The Network Berg’s tutorial contains only 2 (one for primary, with distance=1, another for backup, with distance=2) (my suspicion is, that we do this, so we can still reach 8.8.8.8 on backup and 8.8.4.4 on primary, do I understand this correctly?)
Second thing - why do we need mangling and routing tables? Everything seems to work without them. The Network Berg’s tutorial didn’t include them as well.
Thank you for the link. Unfortunately, that topic doesn’t answer my questions. And it’s also filled with mixed-information with ROS6 & ROS7, some of those are outdated etc.
I did find another topic: http://forum.mikrotik.com/t/recursive-routing-not-wokring/161769/1 - over there, the author had a problem with the setup from official tutorial, and just went with the approach taken by The Network Berg. And it solved their issue. Is the official tutorial broken with ROS7?
Thank you! This is a really great source of knowledge! And it confirms my suspicion - all the solutions you posted there, including the ones described in the official tutorial (the “DUAL WAN - RECURSIVE” and the “USING TWO RECURSIVES - NESTED” approaches) use only one default gateway per ISP. They are quite clear to me (I’m using the NESTED one currently).
Also, unlike the official ones, those you mention don’t utilize mangling, nor the routing tables. Should I consider the official tutorial broken, or is there something I’m missing here?
Use what works, the documentation is generic and is not supposed to solve everyones personal setups.
I use the documentation to understand what commands are typically available and used and then forum experts to guide me through a config attempt.
The key is to show you are trying to do this on your own and ask for help when you get stuck…
As for the other concern… Why would I use two gateways per ISP???
I dont understand the use case so you have to explain what your scenario is, in greater detail to get assistance.
Do you mean your provider gives you two separate WAN connections on two separate gateways… in other words no clue what you mean??
I didn’t study it in detail, but @anav’s examples seem to be simple fixed-role primary/backup. So ISP1 is always primary and ISP2 is used only when ISP1 fails. One routing table is enough for that. Multiple routing tables would be needed if you’d want to have group of devices using ISP1 and ISP2 as backup, and another group of devices using ISP2 and ISP1 as backup. Also incoming traffic (forwarded ports) that uses not only primary ISP needs more than one routing table.
@Sob Concur, but your post is annoying, stop injecting requirements that were not expressed by the USER.
He never said he has two lans that need to go to WAN1 and two other lans that need to go to WAN2, nor did he say how fail over should work for those groupings if either wan1 or wan2 was not available. Nor was there any requirements detailed for port forwarding…
We can ducking come up with a gazillion scenarios, but I have no appetite for such a game.
Good luck Sob , Im outta this thread…
Please, don’t pay to much attention to the IPs I used since I set it up in a virtual environment to give it a go ( my physical Mikrotik device still runs ROS v6 in my real home LAN).
Everything seems to be working as expected, so if you don’t like tinkering with mangle, you could use this approach and call it a day.
Logically speaking I would not rely on pairs of DNS services from the SAME sources. Not saying im right but just a thought!!
If on my primary WAN cannot get through to DNS 8.8.8.8, Is it because my ISP or the DNS server, (that also runs 8.8.4.4…) is not working.
Hence,. the config goes then to opendns and that doesnt work, then we abandon ISP1 and go to ISP2 and check what… THE SAME sources,
What I want to understand is the use cases…
Are WAN1 and WAN2 used at the same time?
How do you decide which users/subnets go out which WAN
What happens when one WAN fails…
I do not see a preference for any WAN or any fail over setups…
Well, I’m considering 8.8.8.8 and 8.8.4.4 to be different sources. I rely on google keeping those two completely separated. But you’re right, I’ll consider reworking the setup into 4 different providers.
They are not.
pppoe-out1 is the main WAN, to be used almost always, and lte1 is the backup. I’ve set up different distances for them (pppoe is 1, lte is 2). That’s the failover.
I am still a little confused about RouterOS v7 and have some doubts. In this case, I couldn’t understand why virtual jumps are used in this configuration. I have a similar situation, which is two links, with WAN 01 as the primary and WAN 02 only functioning as a backup, and everything works fine. But I see many people using these virtual jumps like 10.111.111.111 and 10.222.222.222 in the example, so I’m unsure if I’m doing something wrong here. My configuration works fine, but is there something wrong with it?
I do not configure recursive route for WAN02, as it is the last route. If WAN01 and WAN02 go down, there will be no other WAN route available. If WAN01 comes back online, it will become the default route.
What you are calling jumps is NESTED recursive vice just flat recursive. Not something to lose sleep over. Stick with what you are comfortable understanding.
Your rules look fine, the TS of the further hop is greater by one of the TS of the resolved route, and the scope of the resolving route is equal to or less than the TS of the farther route.
I typically set ISP1 as Primary and ISP2 as Secondary because of efficiency.
If everyone is going out ISP1, then I only need to direct one group out another WAN vice directing two groups out two WANs.
Every scenario is different in terms of what is optimal.
Mine was just a quick note that no, official tutorial with multiple routing tables is not necessarily broken.