Community discussions

MikroTik App
 
tomislav91
Member
Member
Topic Author
Posts: 303
Joined: Fri May 26, 2017 12:47 pm

better way for failover 2 ISP

Wed May 19, 2021 11:45 pm

So i am having two ISPs and having this as a failover
/ip route
add check-gateway=ping distance=1 gateway=8.8.8.8
add check-gateway=ping distance=2 gateway=8.8.4.4
add distance=2 dst-address=8.8.4.4/32 gateway=192.168.2.1 scope=10
add distance=1 dst-address=8.8.8.8/32 gateway=192.168.1.1 scope=10
And this genneraly works, problem is when GW is alive from another ISP but there is no access to internet (provider problem), and when my 1 uplink disconnect, second also not working, but in my routing table it is shows me like reachable (it is , but only gateway).
And in the dude i wonder why its red :D

What is better way for doing this? Does anyone use 2isp failover (i dont need load balancing)
 
User avatar
rextended
Forum Guru
Forum Guru
Posts: 11982
Joined: Tue Feb 25, 2014 12:49 pm
Location: Italy
Contact:

Re: better way for failover 2 ISP

Thu May 20, 2021 12:34 am

dozen of post already exist for that, use search function
 
sindy
Forum Guru
Forum Guru
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: better way for failover 2 ISP

Thu May 20, 2021 1:00 am

problem is when GW is alive from another ISP but there is no access to internet (provider problem), and when my 1 uplink disconnect, second also not working, but in my routing table it is shows me like reachable (it is , but only gateway).
And in the dude i wonder why its red :D
I'm not sure I get what is your problem. Both your default routes use recursive next-hop search, so both should go down if there is a problem in the respective ISP network. The check-gateway=ping acts on the 8.8.x.x address so it should deactivate the default route whenever that "gateway" IP cannot be reached due to the ISP problem.

Are these the only routes you've got in your routing table?
 
User avatar
anav
Forum Guru
Forum Guru
Posts: 19099
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada
Contact:

Re: better way for failover 2 ISP

Thu May 20, 2021 1:43 am

/export hide-sensitive file=anynameyouwish

part bits of a config are useless for debugging.
 
tomislav91
Member
Member
Topic Author
Posts: 303
Joined: Fri May 26, 2017 12:47 pm

Re: better way for failover 2 ISP

Thu May 20, 2021 1:02 pm

problem is when GW is alive from another ISP but there is no access to internet (provider problem), and when my 1 uplink disconnect, second also not working, but in my routing table it is shows me like reachable (it is , but only gateway).
And in the dude i wonder why its red :D
I'm not sure I get what is your problem. Both your default routes use recursive next-hop search, so both should go down if there is a problem in the respective ISP network. The check-gateway=ping acts on the 8.8.x.x address so it should deactivate the default route whenever that "gateway" IP cannot be reached due to the ISP problem.

Are these the only routes you've got in your routing table?
For failover yes, but if gateway is reachable, it wont change to 2nd ISP, just stay thats reachable
 
sindy
Forum Guru
Forum Guru
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: better way for failover 2 ISP

Sat May 22, 2021 10:36 am

As said, the way you've set it up, it normally works as expected. Just to be sure, I did the following test, replicating your setup, except that I used a test route with dst-address=1.2.3.0/24 instead of a default one with dst-address=0.0.0.0/0.

[me@myTik] > ip route print detail where dst-address~"^1\\..*"
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=1.1.1.1/32 gateway=10.11.0.177 gateway-status=10.11.0.177 reachable via bridge.wan.1 distance=1 scope=10 target-scope=10

1 S dst-address=1.2.3.0/24 gateway=1.1.1.1 gateway-status=1.1.1.1 recursive via 10.11.0.177 bridge.wan.1 check-gateway=ping distance=1 scope=30 target-scope=10


When I set the firewall to block pings to 1.1.1.1, the state of the route with dst-address=1.2.3.0/24 gateway=1.1.1.1 is as shown above; when I stop blocking pings to 1.1.1.1, the route with dst-address=1.2.3.0/24 gateway=1.1.1.1 becomes Active again.

So unless you have some more routes than those you've shown, which affect the behaviour, the only thing to come to my mind is that you haven't noticed that setting check-gateway to ping on a route activates pinging of its gateway IP once in 10 seconds, so once the problem in the ISP network begins, it may take 10 seconds in worst case until the recursive route via that ISP becomes inactive.

Who is online

Users browsing this forum: andrep, gigabyte091, kolopeter, menyarito, Speedyboat13 and 92 guests