Example1:
We will lead into this topic using a generic example that covers the majority of situations. We have four WAN connections and need a method to determine when a primary connection is down. When primary is deemed down, the router should switch the environment over to another WAN network. Because we have multiple WAN connections, some traffic is configured to use a specific WAN. Static, DHCP, PPPoE, and LTE style WAN types are shown. Remove or rearrange assignments that don't apply to you.
Example1.png
Are we down?
Finding out if a network is down is tricky. The absolute best way would be an application inside your network that makes connections to resources outside your network for every type of application you deem important. That would be a very special application. Lacking that, a low cost, easy to use, and
included with RouterOS option, is to use a technique called
recursive nexthop lookup (aka recursive routing). This just means that we validate the
entire path to a host, instead of just the one connected to our router directly. This way, your WAN's connection to the internet and thus outside of your ISP network, can be verified.
A caveat of course is that the host you are checking is outside your ISP and is itself
not down. Because a single host could be down it is therefore highly recommended to check two separate hosts. You could check as many as you feel warrant a decision. Here we show two.
Gateway Ping
Route verification is performed with ping checks. Every ten seconds a ping is sent to a remote Host. Failing that, another ping is attempted. Two failed ping replies will set the route as invalid and unreachable. The
check-gateway parameter helps us to accomplish this but not on its own. It is necessary to link two route commands with each other.
Scope and Target Scope
To validate a path to a remote host, we use route entries that are connected to each other over a
Scope and
Target Scope arrangement. These two parameters are an unfortunate abstraction that we as network administrators must deal with. I'll attempt an explanation. Think of
scope as the area of your concern. How much of an area, how far, how deep, and how wide of an area do you care about? This is your scope size.
Scope.png
Target Scope would then be the
next area you care about. Since we are only concerned with next hop paths, the way we tell RouterOS to use a particular route as a
next hop to be validated, is to set the
Target-Scope higher than the
Scope, effectively increasing the size of your standard scope. It takes two command lines to show this awkward representation and linking.
Forum member
anav has beautifully hacked this concept by always setting the default
Scope to 10 and using the
Target Scope parameter to change the
relationship. Note that two linked route entries is enough for validation as shown in the simplified diagram. But in our examples, you will note that we also add one more route for return traffic. This is because we want the ability to use the other ISP connections even when primary is up.
If we are up
When both networks are up, we show other networks being utilized instead of leaving them always idle. We also enable traffic to connect remotely into the network from any available WAN. Also shown is having certain traffic always leave out of a specific WAN.
TypesOfWAN.png
DHCP WAN Type
If you have a DHCP connection to your ISP, you will note that we use a static route in the example. Attached to your DHCP client, is a curious script provided by
rextended (who is author?). With a static route, the script becomes necessary if the ISP changes the IP Address or gateway for any reason. The script keeps your dhcp client and manually added route in sync.
When this event occurs, the script will fire and compare the client gateway value with any route that has a comment of
ISP2_Monitor. The script reads like so:
if this dhcp client has an ip address, search through all routes for a route in which the gateway does not match our own and which has a comment of "ISP2_Monitor". If both conditions are true, change the gateway value.
LTE WAN Type
If you have LTE availability in your area, the best way to utilize this service is with an LTE enabled MikroTik router running ROS v7 which has better support for modems and behavior. To us, these hockey pucks are radios and that's about all. To that end, enable the
passthrough interface feature in the APN configuration. However, if the LTE hardware only has one ethernet interface (or you only want to use one interface), you'll loose the ability to manage the LTE unit. This is not a problem, however with a simple VLAN between the two devices. Our example shows this arrangement. See the
LTE Router Example linked below.
MultiWAN Router Example1
Example1.rsc
LTE Router Example
LTE_Router.rsc
You do not have the required permissions to view the files attached to this post.