Community discussions

MikroTik App
 
joshhboss
Member Candidate
Member Candidate
Topic Author
Posts: 274
Joined: Thu Aug 01, 2019 2:13 pm

Failover Scare

Wed Mar 20, 2024 5:20 pm

SO I have my fail-over that is check on 1.1.1.1 and it is set to use the gateway address of ISP1.. but what im noticing is that is gateway for ISP1 is reachable from anywhere on the internet, so when that interface link went down.. it look like the net watch rule kept enabling and disabled, because the ISP1 gateway was still reachable through ISP2.. I mean I think thats what it means.. Because the Link interface was completely down for about 5 minutes but the up/down status kept being triggered.. I will post my config and let me know what you guys think.. Also the logs from both when the ISP switch lost link.. and then the state of the NetwatchRule
 0  As   ;;; WAN1
         dst-address=0.0.0.0/0 routing-table=main pref-src="" gateway=XX.XX.XX.1 immediate-gw=XX.XX.XX.1%sfp-sfpplus1_WAN distance=1 scope=30 
         target-scope=10 suppress-hw-offload=no 

 2  As   ;;; WAN2-dns
         dst-address=1.0.0.1/32 routing-table=main pref-src="" gateway=XX.XX.XX.158 immediate-gw=XX.XX.XX.158%ether2_WAN2 distance=1 scope=30 
         target-scope=10 suppress-hw-offload=no 

 3  As   ;;; WAN1-dns
         dst-address=1.1.1.1/32 routing-table=main pref-src="" gateway=XX.XX.XX.1 immediate-gw=XX.XX.XX.1%sfp-sfpplus1_WAN distance=1 scope=30 
         target-scope=10 suppress-hw-offload=no 

 4  As   ;;; WAN1-21
         dst-address=0.0.0.0/0 routing-table=WAN21 pref-src="" gateway=XX.XX.XX.158 immediate-gw=XX.XX.XX.158%ether2_WAN2 distance=1 scope=30 
         target-scope=10 suppress-hw-offload=no 


         0   ;;; Internet Test - WAN1
     host=1.1.1.1 type=icmp up-script=ip route enable [find where comment=WAN1] down-script=ip route disable [find where comment=WAN1] test-script="" 
     thr-max=2s thr-avg=700ms thr-stdev=700ms thr-jitter=2s http-codes="" status=up 

 1   ;;; Internet Test - WAN2
     host=1.0.0.1 type=icmp up-script=/ip route enable [find where comment=WAN1-21]\r\n down-script=/ip route disable [find where comment=WAN1-21]\r\n 
     test-script="" thr-max=2s thr-avg=700ms thr-stdev=500ms thr-jitter=2s http-codes="" status=up 

     
It is important to note that im getting the internet to a CRS309 and then 10 gig'ing that to the CCR2116.. not going directly into the router.,
You do not have the required permissions to view the files attached to this post.
 
TheCat12
Member Candidate
Member Candidate
Posts: 178
Joined: Fri Dec 31, 2021 9:13 pm

Re: Failover Scare

Wed Mar 20, 2024 10:54 pm

Just one question: why haven't you done the failover with the help of recursive routing? It's much more reliable in my opinion:
/ip route
set 0 gateway=1.1.1.1 check-gateway=ping scope=11
set 2 scope=10
set 3 scope=10
set 4 gateway=1.0.0.1 check-gateway=ping distance=2 scope=11
And if it's a failover scenario, why are both default routes with the same distance?
 
User avatar
anav
Forum Guru
Forum Guru
Posts: 19395
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada
Contact:

Re: Failover Scare

Wed Mar 20, 2024 11:02 pm

He is using recursive sort of, but also netwatch (vice check-gateway=ping)
His problem may be linked to the fact that he used distance=1 for the WAN2-dns vice distance=2 ( main route traffic for same WAN should be same distance)
( dont believe its shown in the pic though, I happen to be clairvoyant )

Good point though, to ensure his scope and target scope lineup if its standard recursive, you got me when you throw netwatch into the loop.
 
icemending
just joined
Posts: 1
Joined: Tue Mar 19, 2024 6:01 am

Re: Failover Scare

Thu Mar 21, 2024 6:45 am

The net watch rule seems to be triggered repeatedly, possibly due to the gateway of ISP1 still being reachable through ISP2.x trench run To address this issue, you may need to refine your fail-over logic to account for scenarios where the gateway becomes inaccessible. Adjusting the net watch rule to include checks for both the external IP address and the gateway status could potentially resolve the issue. It's also essential to verify the routing configuration to ensure that traffic is correctly rerouted when fail-over occurs.

Who is online

Users browsing this forum: Amazon [Bot], Bing [Bot], GoogleOther [Bot], jaclaz and 25 guests