Community discussions

MUM Europe 2020
 
sporkman
newbie
Topic Author
Posts: 26
Joined: Thu May 02, 2013 4:37 am

enhance "check-gateway" feature - use arbitrary check IP

Fri Jan 24, 2014 10:41 am

I'm new to Mikrotik, and I was happy to see so many ways to load-balance and failover traffic when there are multiple upstream connections. However it seems like performing a real check beyond "is the upstream router powered up" involves delving into scripting, which is a real pain, especially if you're trying to use more than two upstream connections.

Many DSL, cable, EoC, T1, etc. connections will have a separate LAN block, so simply pinging the upstream router's IP that you use as a default gateway tells you nothing about whether you have connectivity. Being able to specify say, the first hop IP beyond your upstream router, or a server upstream would be much more "real world" friendly.

For example, how much easier would this be:
ip route add dst-address=0.0.0.0/0 gateway=10.111.0.1 check-gateway=ping check-address=10.110.0.99
No scripting, no netwatch, just enter the IP you wish to monitor to confirm connectivity via that IP.
 
lunchboxrts
Member Candidate
Member Candidate
Posts: 144
Joined: Sat Aug 19, 2006 6:40 am
Location: United States

Re: enhance "check-gateway" feature - use arbitrary check IP

Fri Jan 24, 2014 8:18 pm

I'm new to Mikrotik, and I was happy to see so many ways to load-balance and failover traffic when there are multiple upstream connections. However it seems like performing a real check beyond "is the upstream router powered up" involves delving into scripting, which is a real pain, especially if you're trying to use more than two upstream connections.

Many DSL, cable, EoC, T1, etc. connections will have a separate LAN block, so simply pinging the upstream router's IP that you use as a default gateway tells you nothing about whether you have connectivity. Being able to specify say, the first hop IP beyond your upstream router, or a server upstream would be much more "real world" friendly.

For example, how much easier would this be:
ip route add dst-address=0.0.0.0/0 gateway=10.111.0.1 check-gateway=ping check-address=10.110.0.99
No scripting, no netwatch, just enter the IP you wish to monitor to confirm connectivity via that IP.
+10
 
nkourtzis
Member Candidate
Member Candidate
Posts: 207
Joined: Tue Dec 11, 2012 12:56 am
Location: Greece

Re: enhance "check-gateway" feature - use arbitrary check IP

Fri Jan 24, 2014 8:25 pm

+100
Passionate about networks
Enthusiastic about Mikrotik
MTCNA | MTCRE | MTCINE

No trees were killed to send this message,
but a large number of electrons were terribly inconvenienced.
 
lambert
Long time Member
Long time Member
Posts: 537
Joined: Fri Jul 23, 2010 1:09 am

Re: enhance "check-gateway" feature - use arbitrary check IP

Fri Jan 24, 2014 8:48 pm

It really would be nice if we could do that per route.

Dreaming, and applying to one of my real situations, that might look like:
/ip route
add check-gateway=ping check-address=A.B.C.1 comment=Wireless distance=10 dst-address=0.0.0.0/1 gateway=\
    H.I.J.225
add check-gateway=ping comment=DSL distance=20 dst-address=0.0.0.0/1 gateway=\
    H.I.K.237
add distance=1 dst-address=A.B.C.1/32 gateway=H.I.J.225
add comment="open vpn server" distance=1 dst-address=D.E.F.9/32 gateway=pppoe-out1
add comment="make sure open vpn server is unreachable when pppoe-out1 is dead" \
    distance=200 dst-address=D.E.F.9/32 type=unreachable
add check-gateway=ping check-address=A.B.C.1 comment=Wireless distance=10 dst-address=128.0.0.0/1 gateway=\
    H.I.J.225
add check-gateway=ping comment=DSL distance=20 dst-address=128.0.0.0/1 gateway=\
    H.I.K.237
Maybe behind the scenes, MikroTik would be creating netwatch entries to disable the routes automagically like the mangle rules which get created to set MSS for tunnel interfaces.

Until then we have to settle for netwatch.

So, I have all of the above plus :
/tool netwatch
add comment="If reachable via wireless prefer wireless for default routes.  If not, prefer DSL for default routes." \
    host=A.B.C.1 \
    down-script="/ip route set [/ip route find comment=\"DSL\"] distance=5" \
    up-script="/ip route set [/ip route find comment=\"DSL\"] distance=20"
Which means there are more places to forget dependencies and generally make more mistakes. Netwatch would still have lots of other uses.
 
User avatar
rmmccann
Member Candidate
Member Candidate
Posts: 182
Joined: Tue Sep 25, 2012 11:15 pm
Location: USA

Re: enhance "check-gateway" feature - use arbitrary check IP

Mon Jan 27, 2014 4:00 am

Maybe I'm misunderstanding your request, but this type of check exists already using recursive routing. I'm monitoring my upstreams DNS servers as a connection check. If I can't ping my upstream DNS, the routes are marked as offline/down and use the next available route.

Basically, create a route with the IP you want to use to check connectivity and set the gateway as your default gateway/next hop. Then, for your default route, specify the IP you are checking as the default route.

Here's an example based off my config. 1.2.3.4 would be my "gateway" while 2.3.4.5 is the upstream device I am checking to verify connectivity. 3.4.5.6 would be a secondary route if your primary is down.

/ip route
add check-gateway=ping comment="Primary Default Route - Midco" distance=1 gateway=2.3.4.5
add check-gateway=ping comment="Backup Default Route - Midco" distance=2 gateway=3.4.5.6
add comment="Validate Route" distance=1 dst-address=2.3.4.5/32 gateway=1.2.3.4 scope=10

If you are unable to reach 2.3.4.5 via 1.2.3.4, the route is disabled and it uses 3.4.5.6 for connectivity.
A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools. --Douglas Adams
 
User avatar
Chupaka
Forum Guru
Forum Guru
Posts: 8346
Joined: Mon Jun 19, 2006 11:15 pm
Location: Minsk, Belarus
Contact:

Re: enhance "check-gateway" feature - use arbitrary check IP

Wed Jan 29, 2014 4:05 pm

Russian-speaking forum: https://forum.mikrotik.by/. Welcome!

For every complex problem, there is a solution that is simple, neat, and wrong.

MikroTik. Your life. Your routing.
 
esanbr
just joined
Posts: 14
Joined: Tue Mar 01, 2011 7:00 pm
Contact:

Re: enhance "check-gateway" feature - use arbitrary check IP

Sun Nov 22, 2015 1:50 am

The bug is when you have a problem after your gateway, ie, your gateway answer normally, but link is down 2/3/etc routers after. Only through a script to check if a option like "check-address=10.110.0.99" is not created!
 
User avatar
Chupaka
Forum Guru
Forum Guru
Posts: 8346
Joined: Mon Jun 19, 2006 11:15 pm
Location: Minsk, Belarus
Contact:

Re: enhance "check-gateway" feature - use arbitrary check IP

Mon Nov 23, 2015 1:25 am

Bwhaha, 5 years xD

Have you read that article?
Russian-speaking forum: https://forum.mikrotik.by/. Welcome!

For every complex problem, there is a solution that is simple, neat, and wrong.

MikroTik. Your life. Your routing.
 
blazej44800
newbie
Posts: 40
Joined: Thu Feb 20, 2014 6:16 pm

Re: enhance "check-gateway" feature - use arbitrary check IP

Sat Feb 06, 2016 11:29 pm

+10 for feature request!
CCNA R&S
 
dcosta
just joined
Posts: 8
Joined: Mon Mar 28, 2016 7:42 pm

Re: enhance "check-gateway" feature - use arbitrary check IP

Tue Dec 20, 2016 5:25 pm

Hello,
On my point of view this feature enhancement would simplify configuration of route checking removing many configuration lines and making configuration easier to do and read.
Very similar to what already happens with "ARP IP targets" on ARP bond checking.

Thanks
David
 
telepro
Frequent Visitor
Frequent Visitor
Posts: 64
Joined: Sun Apr 03, 2011 7:50 pm

Re: enhance "check-gateway" feature - use arbitrary check IP

Mon May 15, 2017 3:42 pm

+1 for this feature request. would be quite useful.
 
nathan1
Member Candidate
Member Candidate
Posts: 151
Joined: Sat Jan 16, 2016 7:05 pm

Re: enhance "check-gateway" feature - use arbitrary check IP

Tue May 16, 2017 1:13 am

I wrote some code a few years ago that I have been running to do per-route checking along with distance adjustments (weighting for different lines).

You can use any RouterOS command for the route check by creating a comment on the route that starts with "ROUTE_CHECK:". This allows you to use specific routing tables and have compound statements. On my systems, I ping two addresses and sum their status (which gives either a 0, 1, or 2) and anything other than 0 will be success. If it returns 0, it will either be disabled or have the distance adjusted depending on the variables minDistance/maxDistance being there. All of this can be tied together to give "priorities" for lines that are up, such that there can always be a last resort available.

This is all run via the scheduler every 5s.
add check-gateway=ping comment="ROUTE_CHECK: :global minDistance 5; :global maxDistance 55; return ([/ping PUBLICIP1 count=1 interface=OutsideComcast routing-table=Comcast]+[/ping PUBLICIP2 count=1 interface=OutsideComcast routing-table=Comcast])" distance=5 gateway=GATEWAYMASKED routing-mark=PhoneInternet
add check-gateway=ping comment="ROUTE_CHECK: :global minDistance 10; :global maxDistance 50; return ([/ping PUBLICIP1 count=1 interface=OutsideVerizon routing-table=Verizon]+[/ping PUBLICIP2 count=1 interface=OutsideVerizon routing-table=Verizon])" distance=10 gateway=GATEWAYMASKED routing-mark=PhoneInternet
add check-gateway=ping comment="ROUTE_CHECK: :global minDistance 5; :global maxDistance 50; return ([/ping PUBLICIP1 count=1 interface=OutsideVerizon routing-table=Verizon]+[/ping PUBLICIP2 count=1 interface=OutsideVerizon routing-table=Verizon])" distance=5 gateway=GATEWAYMASKED pref-src=SRCMASKED
add check-gateway=ping comment="ROUTE_CHECK: :global minDistance 10; :global maxDistance 55; return ([/ping PUBLICIP1 count=1 interface=OutsideComcast routing-table=Comcast]+[/ping PUBLICIP2 count=1 interface=OutsideComcast routing-table=Comcast])" distance=10 gateway=GATEWAYMASKED
If anyone wants to try it - add this scheduler/script. I'm pasting a more readable version below as well.
/system script add name=route_check owner=admin policy=ftp,reboot,read,write,policy,test,password,sniff,sensitive source=":foreach k in [/ip route find comment~\"ROUTE_CHECK\"] do={\
    \n:local actualroute [:tostr [/ip route get \$k]]\
    \n:local disabled [/ip route get \$k disabled]\
    \n:local comment [/ip route get \$k comment]\
    \n:local distance [/ip route get \$k distance]\
    \n:local cmd [:pick \$comment 13 [:len \$comment]]\
    \n:local parsedcmd [:parse \"\$cmd\"]\
    \n:global minDistance \"\"\
    \n:global maxDistance \"\"\
    \n:global stepDistance 5\
    \n:local status [\$parsedcmd]\
    \n:set minDistance [:tonum \$minDistance]\
    \n:set maxDistance [:tonum \$maxDistance]\
    \n#:put \"STATUS: \$status \$[:type \$status]\"\
    \n:if ([:type \$status] != \"num\") do={\
    \n\t:error \"\$comment returned non-number type (need return on expression\?)\"\
    \n}\
    \nif ([:type \$minDistance] != \"nil\" && [:type \$maxDistance] != \"nil\") do={\
    \n\tif (\$minDistance >= \$maxDistance) do={\
    \n\t\t:error \"minDistance >= maxDistance\"\
    \n\t}\
    \n\t:local newDistance \$distance\
    \n\tif (\$status = 0) do={\
    \n\t\t:set newDistance (\$distance + \$stepDistance)\
    \n\t}\
    \n\tif (\$status != 0) do={\
    \n\t\t:set newDistance (\$distance - \$stepDistance)\
    \n\t}\
    \n\tif (\$newDistance < \$minDistance) do={ :set newDistance \$minDistance; }\
    \n\tif (\$newDistance > \$maxDistance) do={ :set newDistance \$maxDistance; }\
    \n\tif (\$newDistance != \$distance) do={\
    \n\t\t/log warning \"distance (\$status): \$distance [\$minDistance, \$maxDistance] -> \$newDistance - \$actualroute\"\
    \n\t\t/ip route set \$k distance=\$newDistance\
    \n\t}\
    \n} else {\
    \n\t:if (\$status = 0 && !\$disabled) do {\
    \n   \t\t/ip route disable \$k\
    \n\t\t/log warning \"Command: \$cmd status=\$status\"\
    \n\t\t/log warning \"distance (\$status): \$distance DISABLE - \$actualroute\"\
    \n\t} else {\
    \n\t\t:if (\$status != 0 && \$disabled) do {\
    \n\t\t\t/ip route enable \$k\
    \n\t\t\t/log warning \"distance (\$status): \$distance ENABLE - \$actualroute\"\
    \n\t\t}\
    \n\t}\
    \n}\
    \n}"
    
/system scheduler add interval=5s name=route_check on-event=route_check policy=ftp,reboot,read,write,policy,test,password,sniff,sensitive start-date=feb/09/2016 start-time=03:39:20

:foreach k in [/ip route find comment~"ROUTE_CHECK"] do={
:local actualroute [:tostr [/ip route get $k]]
:local disabled [/ip route get $k disabled]
:local comment [/ip route get $k comment]
:local distance [/ip route get $k distance]
:local cmd [:pick $comment 13 [:len $comment]]
:local parsedcmd [:parse "$cmd"]
:global minDistance ""
:global maxDistance ""
:global stepDistance 5
:local status [$parsedcmd]
:set minDistance [:tonum $minDistance]
:set maxDistance [:tonum $maxDistance]
#:put "STATUS: $status $[:type $status]"
:if ([:type $status] != "num") do={
	:error "$comment returned non-number type (need return on expression?)"
}
if ([:type $minDistance] != "nil" && [:type $maxDistance] != "nil") do={
	if ($minDistance >= $maxDistance) do={
		:error "minDistance >= maxDistance"
	}
	:local newDistance $distance
	if ($status = 0) do={
		:set newDistance ($distance + $stepDistance)
	}
	if ($status != 0) do={
		:set newDistance ($distance - $stepDistance)
	}
	if ($newDistance < $minDistance) do={ :set newDistance $minDistance; }
	if ($newDistance > $maxDistance) do={ :set newDistance $maxDistance; }
	if ($newDistance != $distance) do={
		/log warning "distance ($status): $distance [$minDistance, $maxDistance] -> $newDistance - $actualroute"
		/ip route set $k distance=$newDistance
	}
} else {
	:if ($status = 0 && !$disabled) do {
   		/ip route disable $k
		/log warning "Command: $cmd status=$status"
		/log warning "distance ($status): $distance DISABLE - $actualroute"
	} else {
		:if ($status != 0 && $disabled) do {
			/ip route enable $k
			/log warning "distance ($status): $distance ENABLE - $actualroute"
		}
	}
}
}
 
telepro
Frequent Visitor
Frequent Visitor
Posts: 64
Joined: Sun Apr 03, 2011 7:50 pm

Re: enhance "check-gateway" feature - use arbitrary check IP

Wed May 24, 2017 11:26 pm

Does anyone know: is there any way to control the rate at which pings are issued when Check-gateway features is turned on in a route definition? By default, it now looks to be about 1 ping every 10 seconds. i would like to slow this rate down.
thanks in advance.
 
User avatar
mrz
MikroTik Support
MikroTik Support
Posts: 5972
Joined: Wed Feb 07, 2007 12:45 pm
Location: Latvia
Contact:

Re: enhance "check-gateway" feature - use arbitrary check IP

Thu May 25, 2017 11:26 am

Currently there is no way to control this.
 
jarda
Forum Guru
Forum Guru
Posts: 7602
Joined: Mon Oct 22, 2012 4:46 pm

Re: enhance "check-gateway" feature - use arbitrary check IP

Thu May 25, 2017 1:34 pm

Strange. I could imagine that I would need it only faster, what is the reason to slow it down?
 
telepro
Frequent Visitor
Frequent Visitor
Posts: 64
Joined: Sun Apr 03, 2011 7:50 pm

Re: enhance "check-gateway" feature - use arbitrary check IP

Thu May 25, 2017 2:31 pm

Out situation:

The Mikrotik device receives status data from local sensors connected to it via ethernet. This data needs to be reliably sent to a data center.
The Mikrotik router has two available connections to the data center
1. a primary, ISP land based, hard wired connection, with no reasonable data transfer cost implications
2. a backup cellular connection to be used in the event of a failure of the ISP connection. Cellular data is billed by data bytes transferred per month
We use recursive routes to verify both are available, and report to the data center if either datapath fails. This is to expedite repair in the event of a failure.
Considering the backup, cellular connection, the recursive routing sends a 70 byte ping and gets a response every 10 seconds.
70 bytes/datagram * 2 (ping + response) * 6 (pings / minute) * 1440 (minutes / day) * 30 (days/month) = 36 megabytes/month

This merely provides status information to allow us to initiate repairs if a failure occurs

The ability to shorten the ping to a minimum size and slow down the ping frequency would reduce the cost of providing this status information. Thus my question/request....
 
jarda
Forum Guru
Forum Guru
Posts: 7602
Joined: Mon Oct 22, 2012 4:46 pm

Re: enhance "check-gateway" feature - use arbitrary check IP

Thu May 25, 2017 2:49 pm

Ok. Switch off the gateway ping and use netwatch instead.
 
cypa
just joined
Posts: 18
Joined: Mon Apr 01, 2013 11:20 am

Re: enhance "check-gateway" feature - use arbitrary check IP

Wed Jun 21, 2017 10:08 am

nowadays in Russia many home and SMB provider's gateways answer arp-ping with losses close to 50% so it is reasonible to add some smoothing and packet loss thresholds for check-gateway=arp
 
jarda
Forum Guru
Forum Guru
Posts: 7602
Joined: Mon Oct 22, 2012 4:46 pm

Re: enhance "check-gateway" feature - use arbitrary check IP

Wed Jun 21, 2017 7:49 pm

How anyone who looses pings inside his network could be isp?
 
idlemind
Forum Guru
Forum Guru
Posts: 1115
Joined: Fri Mar 24, 2017 11:15 pm
Location: USA

Re: enhance "check-gateway" feature - use arbitrary check IP

Thu Jun 22, 2017 12:28 am

In soviet russia, Internet surfs you. That's how.
 
ajack46
newbie
Posts: 38
Joined: Tue Mar 28, 2017 9:08 am

Re: enhance "check-gateway" feature - use arbitrary check IP

Thu Jun 22, 2017 3:15 pm

And how does internet does that.
 
cmgver
just joined
Posts: 2
Joined: Tue Feb 20, 2018 2:41 pm

Re: enhance "check-gateway" feature - use arbitrary check IP

Tue Feb 20, 2018 2:45 pm

I wrote some code a few years ago that I have been running to do per-route checking along with distance adjustments (weighting for different lines).

You can use any RouterOS command for the route check by creating a comment on the route that starts with "ROUTE_CHECK:". This allows you to use specific routing tables and have compound statements. On my systems, I ping two addresses and sum their status (which gives either a 0, 1, or 2) and anything other than 0 will be success. If it returns 0, it will either be disabled or have the distance adjusted depending on the variables minDistance/maxDistance being there. All of this can be tied together to give "priorities" for lines that are up, such that there can always be a last resort available.

This is all run via the scheduler every 5s.
add check-gateway=ping comment="ROUTE_CHECK: :global minDistance 5; :global maxDistance 55; return ([/ping PUBLICIP1 count=1 interface=OutsideComcast routing-table=Comcast]+[/ping PUBLICIP2 count=1 interface=OutsideComcast routing-table=Comcast])" distance=5 gateway=GATEWAYMASKED routing-mark=PhoneInternet
add check-gateway=ping comment="ROUTE_CHECK: :global minDistance 10; :global maxDistance 50; return ([/ping PUBLICIP1 count=1 interface=OutsideVerizon routing-table=Verizon]+[/ping PUBLICIP2 count=1 interface=OutsideVerizon routing-table=Verizon])" distance=10 gateway=GATEWAYMASKED routing-mark=PhoneInternet
add check-gateway=ping comment="ROUTE_CHECK: :global minDistance 5; :global maxDistance 50; return ([/ping PUBLICIP1 count=1 interface=OutsideVerizon routing-table=Verizon]+[/ping PUBLICIP2 count=1 interface=OutsideVerizon routing-table=Verizon])" distance=5 gateway=GATEWAYMASKED pref-src=SRCMASKED
add check-gateway=ping comment="ROUTE_CHECK: :global minDistance 10; :global maxDistance 55; return ([/ping PUBLICIP1 count=1 interface=OutsideComcast routing-table=Comcast]+[/ping PUBLICIP2 count=1 interface=OutsideComcast routing-table=Comcast])" distance=10 gateway=GATEWAYMASKED
If anyone wants to try it - add this scheduler/script. I'm pasting a more readable version below as well.
/system script add name=route_check owner=admin policy=ftp,reboot,read,write,policy,test,password,sniff,sensitive source=":foreach k in [/ip route find comment~\"ROUTE_CHECK\"] do={\
    \n:local actualroute [:tostr [/ip route get \$k]]\
    \n:local disabled [/ip route get \$k disabled]\
    \n:local comment [/ip route get \$k comment]\
    \n:local distance [/ip route get \$k distance]\
    \n:local cmd [:pick \$comment 13 [:len \$comment]]\
    \n:local parsedcmd [:parse \"\$cmd\"]\
    \n:global minDistance \"\"\
    \n:global maxDistance \"\"\
    \n:global stepDistance 5\
    \n:local status [\$parsedcmd]\
    \n:set minDistance [:tonum \$minDistance]\
    \n:set maxDistance [:tonum \$maxDistance]\
    \n#:put \"STATUS: \$status \$[:type \$status]\"\
    \n:if ([:type \$status] != \"num\") do={\
    \n\t:error \"\$comment returned non-number type (need return on expression\?)\"\
    \n}\
    \nif ([:type \$minDistance] != \"nil\" && [:type \$maxDistance] != \"nil\") do={\
    \n\tif (\$minDistance >= \$maxDistance) do={\
    \n\t\t:error \"minDistance >= maxDistance\"\
    \n\t}\
    \n\t:local newDistance \$distance\
    \n\tif (\$status = 0) do={\
    \n\t\t:set newDistance (\$distance + \$stepDistance)\
    \n\t}\
    \n\tif (\$status != 0) do={\
    \n\t\t:set newDistance (\$distance - \$stepDistance)\
    \n\t}\
    \n\tif (\$newDistance < \$minDistance) do={ :set newDistance \$minDistance; }\
    \n\tif (\$newDistance > \$maxDistance) do={ :set newDistance \$maxDistance; }\
    \n\tif (\$newDistance != \$distance) do={\
    \n\t\t/log warning \"distance (\$status): \$distance [\$minDistance, \$maxDistance] -> \$newDistance - \$actualroute\"\
    \n\t\t/ip route set \$k distance=\$newDistance\
    \n\t}\
    \n} else {\
    \n\t:if (\$status = 0 && !\$disabled) do {\
    \n   \t\t/ip route disable \$k\
    \n\t\t/log warning \"Command: \$cmd status=\$status\"\
    \n\t\t/log warning \"distance (\$status): \$distance DISABLE - \$actualroute\"\
    \n\t} else {\
    \n\t\t:if (\$status != 0 && \$disabled) do {\
    \n\t\t\t/ip route enable \$k\
    \n\t\t\t/log warning \"distance (\$status): \$distance ENABLE - \$actualroute\"\
    \n\t\t}\
    \n\t}\
    \n}\
    \n}"
    
/system scheduler add interval=5s name=route_check on-event=route_check policy=ftp,reboot,read,write,policy,test,password,sniff,sensitive start-date=feb/09/2016 start-time=03:39:20

:foreach k in [/ip route find comment~"ROUTE_CHECK"] do={
:local actualroute [:tostr [/ip route get $k]]
:local disabled [/ip route get $k disabled]
:local comment [/ip route get $k comment]
:local distance [/ip route get $k distance]
:local cmd [:pick $comment 13 [:len $comment]]
:local parsedcmd [:parse "$cmd"]
:global minDistance ""
:global maxDistance ""
:global stepDistance 5
:local status [$parsedcmd]
:set minDistance [:tonum $minDistance]
:set maxDistance [:tonum $maxDistance]
#:put "STATUS: $status $[:type $status]"
:if ([:type $status] != "num") do={
	:error "$comment returned non-number type (need return on expression?)"
}
if ([:type $minDistance] != "nil" && [:type $maxDistance] != "nil") do={
	if ($minDistance >= $maxDistance) do={
		:error "minDistance >= maxDistance"
	}
	:local newDistance $distance
	if ($status = 0) do={
		:set newDistance ($distance + $stepDistance)
	}
	if ($status != 0) do={
		:set newDistance ($distance - $stepDistance)
	}
	if ($newDistance < $minDistance) do={ :set newDistance $minDistance; }
	if ($newDistance > $maxDistance) do={ :set newDistance $maxDistance; }
	if ($newDistance != $distance) do={
		/log warning "distance ($status): $distance [$minDistance, $maxDistance] -> $newDistance - $actualroute"
		/ip route set $k distance=$newDistance
	}
} else {
	:if ($status = 0 && !$disabled) do {
   		/ip route disable $k
		/log warning "Command: $cmd status=$status"
		/log warning "distance ($status): $distance DISABLE - $actualroute"
	} else {
		:if ($status != 0 && $disabled) do {
			/ip route enable $k
			/log warning "distance ($status): $distance ENABLE - $actualroute"
		}
	}
}
}
Hi Nathan1, please, sorry my inexperience with scripting and Mikrotik. Could you be so kind to explain better how to use your scripts? I have three WAN, but they have usual issues with the ISPs due to several reasons, I need to forward or reroute the traffic once a route is with problems.

Thanks a lot
 
sporkman
newbie
Topic Author
Posts: 26
Joined: Thu May 02, 2013 4:37 am

Re: enhance "check-gateway" feature - use arbitrary check IP

Wed Feb 21, 2018 9:44 pm

Maybe I'm misunderstanding your request, but this type of check exists already using recursive routing.
Many years later, this post of mine still comes up when I search for easy ways to do failover when the gateway is always "up".

I never answered this follow-up, but I will now.

This is to make setting it up easier, and for you to sell more routers. :)

Add the other requests in this thread, and you'd have something on-par with competing products that focus on load-balancing/failover if these features were added to the "check gateway" section:
  • Arbitrary IP for the status check
  • Set frequency of pings
  • Set packet loss % threshold
  • Set latency threshold
I know, that's not nearly baroque enough for diehard Mikrotik fans, but it sure would be nice.
 
xQx
just joined
Posts: 1
Joined: Fri May 25, 2018 3:04 pm

Re: enhance "check-gateway" feature - use arbitrary check IP

Fri May 25, 2018 3:24 pm

Since this very old thread is still going and it's the first result for a search in google for this topic, followed by a long list of solutions that require advanced scripting, I'd like to re-iterate that this is both possible and very, very easy. Also - credit where credit is due, this solution was explained in the second reply in this thread - just a bit confusingly.

Say you have two ISP's, your preferred one with gateway IP address 192.168.1.1, your failover ISP with gateway IP address 192.168.2.254.
In this example, the upstream IP address we're testing to confirm Internet connectivity is Google's DNS server, 8.8.4.4

Your failover route looks like this (Note the distance=10. Any default route with a distance lower than 10 will be used in preference to this route.):
/ip route add distance=10 gateway=192.168.2.254

Your primary gateway rule is two lines, the first says "to get to the host I want to ping, always use gateway address 192.168.1.1"
/ip route add distance=1 dst-address=8.8.4.4/32 gateway=192.168.1.1 scope=10

The second line is confusing, because it's a mikrotik specific thing. Technically you're saying "use the default gateway of 8.8.4.4", but Mikrotik uses a "recursive route lookup" and knows that you get to 8.8.4.4 via 192.168.1.1 - so it routes your traffic to 192.168.1.1 as long as 8.8.4.4 is pingable. (Note distance=1. This means it's preferred over your other default route).
/ip route add check-gateway=ping distance=1 gateway=8.8.4.4

Putting it all together into three lines that you can cut and paste. Just change "192.168.1.1" to the ip of your primary gateway and "192.168.2.254" to the IP of your failover gateway:

/ip route
add distance=1 dst-address=8.8.4.4/32 gateway=192.168.1.1 scope=10
add check-gateway=ping distance=1 gateway=8.8.4.4
add distance=10 gateway=192.168.2.254

Dead easy.
 
anav
Forum Guru
Forum Guru
Posts: 3274
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada

Re: enhance "check-gateway" feature - use arbitrary check IP

Sun May 27, 2018 5:30 pm

xQx very nice explanation.
My stupid newbie route for primary ISP with failover to secondary ISP (except my email goes through secondary ISP)
/ip route
add dest=0.0.0.0/0 gateway IP (of primary ISP) check-gateway=ping distance=1
add dest=0.0.0.0/0 gateway IP (of secondary ISP) distance=2
add dest=EmailServerIP gateway IP (of secondary ISP) distance=1

Based on your input would this be feasible to check two external IPs?..........
/ip route
add distance=1 dst-address=8.8.4.4/32 gateway=192.168.1.1 scope=10 (google)
add distance=2 dst-address=208.67.220.220/32 gateway=192.168.1.1 scope=10 (opendns)
add check-gateway=ping distance=1 gateway=8.8.4.4
add check-gateway=ping distance=2 gateway=208.67.220.220
add distance=10 gateway=192.168.2.254
add dest=emailServerIP gateway IP (of secondary ISP) distance=1


Where in you schema do I put in the expected lines dest-address=0.0.0.0/0 ??
I'd rather manage rats than software. Follow my advice at your own risk! (Sob & mkx forced me to write that!)
 
jo2jo
Forum Veteran
Forum Veteran
Posts: 969
Joined: Fri May 26, 2006 1:25 am

Re: enhance "check-gateway" feature - use arbitrary check IP

Fri Aug 31, 2018 12:39 am

xqx: thanks for explination , 2 questions:

1- assuming you dont have any other static routes (ie no other entries in /ip route), could you use:
add distance=3 gateway=192.168.2.254
instead of:
add distance=10 gateway=192.168.2.254
(im just trying to fully understand if there is a link between the scope=10 of first rule and distance=10 of last rule)

2- again with just your 3x /ip route rules (none other), 8.8.4.4 will always be routed via the the 192.168.1.1 , so assuming that 192.168.1.1 goes down (and now 192.168.2.254 is your def-gw), any users/clients who have hard coded their dns settings to use 8.8.4.4 will still be forced via the currently down 192.168.1.1 gw, correct?

ive been using a pretty complicated netwatch + scheduler + scripts failover system and am looking to simplify it.

thanks
:beep :beep :beep
 
jrbenito
just joined
Posts: 9
Joined: Tue May 20, 2014 4:19 am

Re: enhance "check-gateway" feature - use arbitrary check IP

Wed Oct 03, 2018 5:14 pm

1- assuming you dont have any other static routes (ie no other entries in /ip route), could you use:
add distance=3 gateway=192.168.2.254
instead of:
add distance=10 gateway=192.168.2.254
(im just trying to fully understand if there is a link between the scope=10 of first rule and distance=10 of last rule)

No, there is no link between distance and scope. Hence you can set distance to 3 if you don´t have any other routing more "important" than that.

2- again with just your 3x /ip route rules (none other), 8.8.4.4 will always be routed via the the 192.168.1.1 , so assuming that 192.168.1.1 goes down (and now 192.168.2.254 is your def-gw), any users/clients who have hard coded their dns settings to use 8.8.4.4 will still be forced via the currently down 192.168.1.1 gw, correct?

If I understood this https://wiki.mikrotik.com/wiki/Manual:U ... attributes correctly, scope parameter will handle this in the case ISP1 is down and failting over to ISP2. Hence, no problem with 8.8.4.4 not being reached. Need to test to confirm.

BRs
 
jrbenito
just joined
Posts: 9
Joined: Tue May 20, 2014 4:19 am

Re: enhance "check-gateway" feature - use arbitrary check IP

Wed Oct 03, 2018 5:19 pm

Based on your input would this be feasible to check two external IPs?..........
/ip route
add distance=1 dst-address=8.8.4.4/32 gateway=192.168.1.1 scope=10 (google)
add distance=2 dst-address=208.67.220.220/32 gateway=192.168.1.1 scope=10 (opendns)
add check-gateway=ping distance=1 gateway=8.8.4.4
add check-gateway=ping distance=2 gateway=208.67.220.220
add distance=10 gateway=192.168.2.254
add dest=emailServerIP gateway IP (of secondary ISP) distance=1

Yes, it is possible as per "Multiple host checking per Uplink" session in https://wiki.mikrotik.com/wiki/Advanced ... _Scripting but has on extra step you did not account on your example.
 
User avatar
oscarc
just joined
Posts: 6
Joined: Mon Apr 27, 2015 7:55 pm
Location: Barcelona
Contact:

Re: enhance "check-gateway" feature - use arbitrary check IP

Mon Dec 17, 2018 7:40 pm

Hello

Regarding that, is there any way to log any routing change in order to know if some ping to the gateway failed for a while?

Thanks in advance

Óscar
Let the wind blow back your hair
 
Luminair
just joined
Posts: 5
Joined: Sat Jul 07, 2018 12:54 pm

Re: enhance "check-gateway" feature - use arbitrary check IP

Wed Jun 05, 2019 11:46 am

The problem with this: check-gateway=ping cannot be configured. 10 second check that cannot be configured is not appropriate for failover.
 
User avatar
dcalanchini
just joined
Posts: 5
Joined: Thu Oct 17, 2019 10:12 pm
Location: Sacramento, Ca

Re: enhance "check-gateway" feature - use arbitrary check IP

Sat Oct 19, 2019 10:14 am

I have tried like HE** to get this to work, here is what I pasted in there (not including the numbers):

/ip route
1 add dst-address=8.8.8.8 gateway=10.1.1.254 scope=10
2 add dst-address=8.8.4.4 gateway=99.119.154.246 scope=10

/ip route
3 add distance=1 gateway=8.8.8.8 routing-mark=ISP1 check-gateway=ping
4 add distance=2 gateway=8.8.4.4 routing-mark=ISP1 check-gateway=ping

/ip route
5 add distance=1 gateway=8.8.4.4 routing-mark=ISP2 check-gateway=ping
6 add distance=2 gateway=8.8.8.8 routing-mark=ISP2 check-gateway=ping

With both Wan ports plugged in I get this: (Which I think is what I expect)

ARG, no pictures? Ok will try to describe:

Both WAN Active:
Active Routes: 3,6,1,2 and my wan 1 default route
Inactive Routes: 4,5 and my wan 2 default route

When I unplug Wan1 (this does not look right??)
Active Routes: 2 and my wan 2 default route
Inactive Routes: 4,5 and my wan 2 default route


This might be easier to look at:
Both wan In
Flags: X - disabled, A - active, D - dynamic,
C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme,
B - blackhole, U - unreachable, P - prohibit
# DST-ADDRESS PREF-SRC GATEWAY D
0 S 0.0.0.0/0 8.8.8.8
1 S 0.0.0.0/0 8.8.4.4
2 S 0.0.0.0/0 8.8.4.4
3 S 0.0.0.0/0 8.8.8.8
4 ADS 0.0.0.0/0 99.119.154.246
5 A S 8.8.4.4/32 99.119.154.246
6 S 8.8.8.8/32 10.1.1.254
7 ADC 10.1.10.0/24 10.1.10.1 bridge1
8 ADC 99.119.154.240/29 99.119.154.241 ether2
9 ADC 192.168.10.0/24 192.168.10.1 VoIPvlan10

Wan 2 unplugged
Flags: X - disabled, A - active, D - dynamic,
C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme,
B - blackhole, U - unreachable, P - prohibit
# DST-ADDRESS PREF-SRC GATEWAY DISTANCE
0 A S 0.0.0.0/0 8.8.8.8 1
1 S 0.0.0.0/0 8.8.4.4 2
2 S 0.0.0.0/0 8.8.4.4 1
3 A S 0.0.0.0/0 8.8.8.8 2
4 ADS 0.0.0.0/0 10.1.1.254 1
5 DS 0.0.0.0/0 99.119.154.246 2
6 A S 8.8.4.4/32 99.119.154.246 1
7 A S 8.8.8.8/32 10.1.1.254 1
8 ADC 10.1.1.0/24 10.1.1.64 ether1 0
9 ADC 10.1.10.0/24 10.1.10.1 bridge1 0
10 ADC 99.119.154.240/29 99.119.154.241 ether2 0
11 ADC 192.168.10.0/24 192.168.10.1 VoIPvlan10 0

Anyone have any ideas? I must be doing something wrong....I just don't see it
You can't fix stupid, they don't have an app for that...
 
User avatar
Chupaka
Forum Guru
Forum Guru
Posts: 8346
Joined: Mon Jun 19, 2006 11:15 pm
Location: Minsk, Belarus
Contact:

Re: enhance "check-gateway" feature - use arbitrary check IP

Mon Oct 21, 2019 5:56 pm

"/ip route print detail" is a better way of showing because it doesn't hide routing marks. Also, use [code] blocks - this will save formatting.
Russian-speaking forum: https://forum.mikrotik.by/. Welcome!

For every complex problem, there is a solution that is simple, neat, and wrong.

MikroTik. Your life. Your routing.
 
User avatar
dcalanchini
just joined
Posts: 5
Joined: Thu Oct 17, 2019 10:12 pm
Location: Sacramento, Ca

Re: enhance "check-gateway" feature - use arbitrary check IP

Mon Oct 21, 2019 8:27 pm

Good tip, thanks -
I did find another post regarding this issue with using your primary DNS as your test points, so I did change that.

This is with both wan ports active
 /ip route print detail
Flags: X - disabled, A - active, D - dynamic, 
C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme, 
B - blackhole, U - unreachable, P - prohibit 
 0 A S  dst-address=0.0.0.0/0 gateway=1.1.1.1 
        gateway-status=1.1.1.1 recursive via 10.1.1.254 ether1 
        check-gateway=ping distance=1 scope=30 target-scope=10 
        routing-mark=ISP1 

 1   S  dst-address=0.0.0.0/0 gateway=1.0.0.1 
        gateway-status=1.0.0.1 recursive via 99.119.154.246 ether2 
        check-gateway=ping distance=2 scope=30 target-scope=10 
        routing-mark=ISP1 

 2 A S  dst-address=0.0.0.0/0 gateway=1.0.0.1 
        gateway-status=1.0.0.1 recursive via 99.119.154.246 ether2 
        check-gateway=ping distance=1 scope=30 target-scope=10 
        routing-mark=ISP2 

 3   S  dst-address=0.0.0.0/0 gateway=1.1.1.1 
        gateway-status=1.1.1.1 recursive via 10.1.1.254 ether1 
        check-gateway=ping distance=2 scope=30 target-scope=10 
        routing-mark=ISP2 

 4 ADS  dst-address=0.0.0.0/0 gateway=10.1.1.254 
        gateway-status=10.1.1.254 reachable via  ether1 distance=1 scope=30 
        target-scope=10 vrf-interface=ether1 

 5  DS  dst-address=0.0.0.0/0 gateway=99.119.154.246 
        gateway-status=99.119.154.246 reachable via  ether2 distance=2 scope=30 
        target-scope=10 vrf-interface=ether2 

 6 A S  dst-address=1.0.0.1/32 gateway=99.119.154.246 
        gateway-status=99.119.154.246 reachable via  ether2 distance=1 scope=10 
        target-scope=10 

 7 A S  dst-address=1.1.1.1/32 gateway=10.1.1.254 
        gateway-status=10.1.1.254 reachable via  ether1 distance=1 scope=10 
        target-scope=10 

 8 ADC  dst-address=10.1.1.0/24 pref-src=10.1.1.64 gateway=ether1 
        gateway-status=ether1 reachable distance=0 scope=10 

 9 ADC  dst-address=10.1.10.0/24 pref-src=10.1.10.1 gateway=bridge1 
        gateway-status=bridge1 reachable distance=0 scope=10 

10 ADC  dst-address=99.119.154.240/29 pref-src=99.119.154.241 gateway=ether2 
        gateway-status=ether2 reachable distance=0 scope=10 

11 ADC  dst-address=192.168.10.0/24 pref-src=192.168.10.1 gateway=VoIPvlan10 
        gateway-status=VoIPvlan10 reachable distance=0 scope=10 


This is with Wan 1 unplugged

 /ip route print detail
Flags: X - disabled, A - active, D - dynamic, C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme, B - blackhole, U - unreachable, P - prohibit 
 0   S  dst-address=0.0.0.0/0 gateway=1.1.1.1 gateway-status=1.1.1.1 unreachable check-gateway=ping distance=1 scope=30 target-scope=10 routing-mark=ISP1 

 1   S  dst-address=0.0.0.0/0 gateway=1.0.0.1 gateway-status=1.0.0.1 recursive via 99.119.154.246 ether2 check-gateway=ping distance=2 scope=30 target-scope=10 
        routing-mark=ISP1

 2   S  dst-address=0.0.0.0/0 gateway=1.0.0.1 gateway-status=1.0.0.1 recursive via 99.119.154.246 ether2 check-gateway=ping distance=1 scope=30 target-scope=10 
        routing-mark=ISP2 

 3   S  dst-address=0.0.0.0/0 gateway=1.1.1.1 gateway-status=1.1.1.1 unreachable check-gateway=ping distance=2 scope=30 target-scope=10 routing-mark=ISP2 

 4 ADS  dst-address=0.0.0.0/0 gateway=99.119.154.246 gateway-status=99.119.154.246 reachable via  ether2 distance=2 scope=30 target-scope=10 vrf-interface=ether2 

 5 A S  dst-address=1.0.0.1/32 gateway=99.119.154.246 gateway-status=99.119.154.246 reachable via  ether2 distance=1 scope=10 target-scope=10 

 6   S  dst-address=1.1.1.1/32 gateway=10.1.1.254 gateway-status=10.1.1.254 unreachable distance=1 scope=10 target-scope=10 

 7 ADC  dst-address=10.1.10.0/24 pref-src=10.1.10.1 gateway=bridge1 gateway-status=bridge1 reachable distance=0 scope=10 

 8 ADC  dst-address=99.119.154.240/29 pref-src=99.119.154.241 gateway=ether2 gateway-status=ether2 reachable distance=0 scope=10 

 9 ADC  dst-address=192.168.10.0/24 pref-src=192.168.10.1 gateway=VoIPvlan10 gateway-status=VoIPvlan10 reachable distance=0 scope=10 
Fail over seems to work sporadically. Another issue is that voip phone wont re-register, but it may be related to this issue. Anyone see my mistake or have a working config they can paste to me?
Thanks in advance.
You can't fix stupid, they don't have an app for that...
 
pe1chl
Forum Guru
Forum Guru
Posts: 6252
Joined: Mon Jun 08, 2015 12:09 pm

Re: enhance "check-gateway" feature - use arbitrary check IP

Mon Oct 21, 2019 8:42 pm

No, the issue of VoIP not working correctly after failover is completely unrelated to that. It is an issue inherent to SIP VoIP, especially in combination with NAT.
See this topic viewtopic.php?t=129048
 
User avatar
dcalanchini
just joined
Posts: 5
Joined: Thu Oct 17, 2019 10:12 pm
Location: Sacramento, Ca

Re: enhance "check-gateway" feature - use arbitrary check IP

Mon Oct 21, 2019 8:50 pm

Try looking at these caps:
Both wan up
https://drive.google.com/file/d/19PnMYu ... sp=sharing

wan1 down
https://drive.google.com/file/d/19RPu5_ ... sp=sharing

reviewing voip re-registration link now.
You can't fix stupid, they don't have an app for that...

Who is online

Users browsing this forum: eworm, PhilipJFry and 94 guests