Community discussions

MikroTik App
 
simonefil
just joined
Topic Author
Posts: 11
Joined: Tue Apr 13, 2021 9:22 pm
Location: Bergamo - Italy
Contact:

Failover Scripting It does not work properly

Thu Apr 22, 2021 7:06 pm

Goodmorning everyone.
On my routerboard I am using the failover scripting present in the official guide: https://wiki.mikrotik.com/wiki/Failover_Scripting
I have adapted the gateways of the guide to my gateways:
: local GatewayISP1 ether10 (I use a pppoe)
: local GatewayISP2 192.168.78.1
And the script works, but not correctly.
By leaving both interfaces working, the traffic goes to ISP2 (it should be ISP1) while, by disabling the interface of ISP2, then the traffic goes to ISP1.
I don't want it to work so it should work exactly the other way around.
What am I wrong? Here is my custom configuration:
# ------------- start editing here -------------
# Edit the variables below to suit your needs

# Please fill the WAN interface names
:local InterfaceISP1 ether10 EOLO
:local InterfaceISP2 ether9 FASTWEB

# Please fill the gateway IPs (or interface names in case of PPPoE)
:local GatewayISP1 ether10 EOLO
:local GatewayISP2 192.168.78.1

# Please fill the ping check host - currently: dns Google
:local PingTarget 8.8.8.8

# Please fill how many ping failures are allowed before fail-over happends
:local FailTreshold 3

# Define the distance increase of a route when it fails
:local DistanceIncrease 2

# Editing the script after this point may break it
# -------------- stop editing here --------------



# Declare the global variables
:global PingFailCountISP1
:global PingFailCountISP2

# This inicializes the PingFailCount variables, in case this is the 1st time the script has ran
:if ([:typeof $PingFailCountISP1] = "nothing") do={:set PingFailCountISP1 0}
:if ([:typeof $PingFailCountISP2] = "nothing") do={:set PingFailCountISP2 0}

# This variable will be used to keep results of individual ping attempts
:local PingResult



# Check ISP1
:set PingResult [ping $PingTarget count=1 interface=$InterfaceISP1]
:put $PingResult

:if ($PingResult = 0) do={
	:if ($PingFailCountISP1 < ($FailTreshold+2)) do={
		:set PingFailCountISP1 ($PingFailCountISP1 + 1)
		
		:if ($PingFailCountISP1 = $FailTreshold) do={
			:log warning "ISP1 has a problem en route to $PingTarget - increasing distance of routes."
			:foreach i in=[/ip route find gateway=$GatewayISP1 && static] do=\
				{/ip route set $i distance=([/ip route get $i distance] + $DistanceIncrease)}
			:log warning "Route distance increase finished."
		}
	}
}
:if ($PingResult = 1) do={
	:if ($PingFailCountISP1 > 0) do={
		:set PingFailCountISP1 ($PingFailCountISP1 - 1)
		
		:if ($PingFailCountISP1 = ($FailTreshold -1)) do={
			:log warning "ISP1 can reach $PingTarget again - bringing back original distance of routes."
			:foreach i in=[/ip route find gateway=$GatewayISP1 && static] do=\
				{/ip route set $i distance=([/ip route get $i distance] - $DistanceIncrease)}
			:log warning "Route distance decrease finished."
		}
	}
}



# Check ISP2
:set PingResult [ping $PingTarget count=1 interface=$InterfaceISP2]
:put $PingResult

:if ($PingResult = 0) do={
	:if ($PingFailCountISP2 < ($FailTreshold+2)) do={
		:set PingFailCountISP2 ($PingFailCountISP2 + 1)
		
		:if ($PingFailCountISP2 = $FailTreshold) do={
			:log warning "ISP2 has a problem en route to $PingTarget - increasing distance of routes."
			:foreach i in=[/ip route find gateway=$GatewayISP2 && static] do=\
				{/ip route set $i distance=([/ip route get $i distance] + $DistanceIncrease)}
			:log warning "Route distance increase finished."
		}
	}
}
:if ($PingResult = 1) do={
	:if ($PingFailCountISP2 > 0) do={
		:set PingFailCountISP2 ($PingFailCountISP2 - 1)
		
		:if ($PingFailCountISP2 = ($FailTreshold -1)) do={
			:log warning "ISP2 can reach $PingTarget again - bringing back original distance of routes."
			:foreach i in=[/ip route find gateway=$GatewayISP2 && static] do=\
				{/ip route set $i distance=([/ip route get $i distance] - $DistanceIncrease)}
			:log warning "Route distance decrease finished."
		}
	}
}
Thank you all
Simone
 
pe1chl
Forum Guru
Forum Guru
Posts: 7420
Joined: Mon Jun 08, 2015 12:09 pm

Re: Failover Scripting It does not work properly

Thu Apr 22, 2021 10:33 pm

When you are using PPPoE, your interface name is not ether10 but like pppoe-out1 (or different when you have renamed it).
 
simonefil
just joined
Topic Author
Posts: 11
Joined: Tue Apr 13, 2021 9:22 pm
Location: Bergamo - Italy
Contact:

Re: Failover Scripting It does not work properly

Thu Apr 22, 2021 11:27 pm

When you are using PPPoE, your interface name is not ether10 but like pppoe-out1 (or different when you have renamed it).
Thank you for your answer.
My pppoe interface is called "pppoe-out1"
I reloaded the whole script with these values through the terminal:
# ------------- start editing here -------------
# Edit the variables below to suit your needs

# Please fill the WAN interface names
:local InterfaceISP1 pppoe-out1
:local InterfaceISP2 ether9

# Please fill the gateway IPs (or interface names in case of PPP)
:local GatewayISP1 pppoe-out1
:local GatewayISP2 192.168.78.1

# Please fill the ping check host - currently: Google DNS
:local PingTarget 8.8.8.8

# Please fill how many ping failures are allowed before fail-over happends
:local FailTreshold 3

# Define the distance increase of a route when it fails
:local DistanceIncrease 2

# Editing the script after this point may break it
# -------------- stop editing here --------------
But nothing has changed.
Do I have to delete the current script before loading the correct script? Or does the new script overwrite the one on the routerboard?
Thank you
 
pe1chl
Forum Guru
Forum Guru
Posts: 7420
Joined: Mon Jun 08, 2015 12:09 pm

Re: Failover Scripting It does not work properly

Fri Apr 23, 2021 11:09 am

I did not study the script in detail, I only noted the common mistake of using the ethernet interface name as the indication of the internet interface where PPPoE is used.
 
simonefil
just joined
Topic Author
Posts: 11
Joined: Tue Apr 13, 2021 9:22 pm
Location: Bergamo - Italy
Contact:

Re: Failover Scripting It does not work properly

Fri Apr 23, 2021 11:15 am

I did not study the script in detail, I only noted the common mistake of using the ethernet interface name as the indication of the internet interface where PPPoE is used.
ok thanks for your help anyway :)
 
User avatar
rextended
Forum Guru
Forum Guru
Posts: 3208
Joined: Tue Feb 25, 2014 12:49 pm
Location: Capalbio, Tuscany, Italy

Re: Failover Scripting It does not work properly

Fri Apr 23, 2021 2:57 pm

I do not know why someone has wrotten one script to do what can be made with simply two settings...
(cross-routes check is another question, but in this case one wan are by pppoe)

do not use any script, simply:

REMOVE ALL STATIC ROUTE(S) with 0.0.0.0/0 (generated by script)

set pppoe-out1 default route distance = 10
set dhcp-client (you use this???) default route distance=20

if you use static IP for fastweb, instead of dhcp client (dhcp client for me is preferred),
add default route with dst. address 0.0.0.0/0 , gateway 192.168.78.1 and distance=20

if pppoe go down, it use automatically other connection.
BUT (Script or not) some NAT connection still locked on other gateway until they go on timeout or connection are closed (=VoIP problems)
user can lose some data or experience interruptions.

when pppoe go up again, automatically all go back to normal
BUT the estabilished connections trough NAT do NOT STOP working until they go on timeout or connection are closed.
this prevent the user to lose some data or experience interruptions.
I'm Italian, not English. Sorry for my imperfect grammar.
 
simonefil
just joined
Topic Author
Posts: 11
Joined: Tue Apr 13, 2021 9:22 pm
Location: Bergamo - Italy
Contact:

Re: Failover Scripting It does not work properly

Fri Apr 23, 2021 8:24 pm

I do not know why someone has wrotten one script to do what can be made with simply two settings...
(cross-routes check is another question, but in this case one wan are by pppoe)

do not use any script, simply:

REMOVE ALL STATIC ROUTE(S) with 0.0.0.0/0 (generated by script)

set pppoe-out1 default route distance = 10
set dhcp-client (you use this???) default route distance=20

if you use static IP for fastweb, instead of dhcp client (dhcp client for me is preferred),
add default route with dst. address 0.0.0.0/0 , gateway 192.168.78.1 and distance=20

if pppoe go down, it use automatically other connection.
BUT (Script or not) some NAT connection still locked on other gateway until they go on timeout or connection are closed (=VoIP problems)
user can lose some data or experience interruptions.

when pppoe go up again, automatically all go back to normal
BUT the estabilished connections trough NAT do NOT STOP working until they go on timeout or connection are closed.
this prevent the user to lose some data or experience interruptions.
Thank you for your answer.
I deleted the script and I used your tips as simply as workly. Thank you!
In your post you talk about some connections that remain "hanging" on the routes of the fault wan, especially the SIP traffic. Well, I think I've found a way around this problem.
The much hated "SIP ALG" that everyone disables as a first operation, in this case it helped me. I set the "SIP Timeout" to a very low value "02 seconds" and in case of gateway switch every two seconds it drops the previous route, the client will establish a new one on the new gateway.
I tested this setup for a few hours and it seems to work perfectly, without any problems or disturbances during calls
 
User avatar
rextended
Forum Guru
Forum Guru
Posts: 3208
Joined: Tue Feb 25, 2014 12:49 pm
Location: Capalbio, Tuscany, Italy

Re: Failover Scripting It does not work properly

Fri Apr 23, 2021 8:41 pm

I do not know why someone has wrotten one script to do what can be made with simply two settings...
(cross-routes check is another question, but in this case one wan are by pppoe)

do not use any script, simply:

REMOVE ALL STATIC ROUTE(S) with 0.0.0.0/0 (generated by script)

set pppoe-out1 default route distance = 10
set dhcp-client (you use this???) default route distance=20

if you use static IP for fastweb, instead of dhcp client (dhcp client for me is preferred),
add default route with dst. address 0.0.0.0/0 , gateway 192.168.78.1 and distance=20

if pppoe go down, it use automatically other connection.
BUT (Script or not) some NAT connection still locked on other gateway until they go on timeout or connection are closed (=VoIP problems)
user can lose some data or experience interruptions.

when pppoe go up again, automatically all go back to normal
BUT the estabilished connections trough NAT do NOT STOP working until they go on timeout or connection are closed.
this prevent the user to lose some data or experience interruptions.
Thank you for your answer.
I deleted the script and I used your tips as simply as workly. Thank you!
In your post you talk about some connections that remain "hanging" on the routes of the fault wan, especially the SIP traffic. Well, I think I've found a way around this problem.
The much hated "SIP ALG" that everyone disables as a first operation, in this case it helped me. I set the "SIP Timeout" to a very low value "02 seconds" and in case of gateway switch every two seconds it drops the previous route, the client will establish a new one on the new gateway.
I tested this setup for a few hours and it seems to work perfectly, without any problems or disturbances during calls
Use my script here, for the same problem, this is valid for all services, not only SIP. Setting low timeout sometime interrupt the call, if the phone voip device are not configured correctly...

viewtopic.php?f=9&t=154606#p853803

just add on ppp profile (used by pppoe-out1) on script menu, both on on-up and on-down sections:
/ip fire conn
:foreach idc in=[find where timeout>60 and reply-dst-address~$"local-address"] do={
 remove [find where .id=$idc]
}

do not change $"local-address": is one variable automatically filled by pppoe-out1 inside the script, everytime the service go up or down

P.S.: I'm a WISP and on my 4000 CPEs ftp, pptp, tftp and sip alg are everytime active ;)) as I give one public IP to CPE without NAT anywere, except on end user LAN.
I'm Italian, not English. Sorry for my imperfect grammar.

Who is online

Users browsing this forum: No registered users and 22 guests