Routing Ping Check False Positives

keskol · May 23, 2025, 8:06am

Hi,

I have implemented recursive routing as described here: https://help.mikrotik.com/docs/spaces/ROS/pages/26476608/Failover+WAN+Backup
However I am having an issue that some routes are marked as active, although the Check IP is not reachable in fact. Initially I used stuff like 8.8.8.8 and thought there might be a false positive due to the fact that 8.8.8.8 could be reached from another WAN line, however even after changing to next-hop addresses and making sure that these are only available through the corresponding interface when everything is normal, I am still having an issue where especially VLAN1001 is often marked as available, when in fact it is theoretically not possible. It even detects Internet
Due to trunking, my WANs are in 3 different VLANS. The IPs used to Check against are internal networks of ISPs, for details see below.

VLAN1001 is a LTE line which only works when I book a data package. I have made sure with other devices, that the IPs used to check against are only available when a package is booked.

After a few seconds it does recognize that the route is in fact not available and removes it..
I can stop this issue by disabling the Mobile Connection in the LTE Router (from Huawei), but that disables the conviniece of being able to just book a data package and have the line automatically active and as default route.

Any ideas on how to stop these false positives from occuring?

ip/route/ export:

/ip route add comment="VLAN1000 - 1" disabled=no distance=1 dst-address=172.188.1.200/32 gateway=192.168.88.1 routing-table=main scope=10 suppress-hw-offload=no target-scope=10
/ip route add check-gateway=ping comment="VLAN1000 - 1 - Out" disabled=no distance=2 dst-address=0.0.0.0/0 gateway=172.188.1.200 routing-table=main scope=30 suppress-hw-offload=no target-scope=11
/ip route add comment="VLAN1000 - 2" disabled=no distance=1 dst-address=172.16.16.67/32 gateway=192.168.88.1 routing-table=main scope=10 suppress-hw-offload=no target-scope=10
/ip route add check-gateway=ping comment="VLAN1000 - 2 - Out" disabled=no distance=2 dst-address=0.0.0.0/0 gateway=172.16.16.67 routing-table=main scope=30 suppress-hw-offload=no target-scope=11

/ip route add comment="VLAN1001 - 1" disabled=no distance=1 dst-address=195.222.54.166/32 gateway=10.150.30.1 routing-table=main scope=10 suppress-hw-offload=no target-scope=10
/ip route add check-gateway=ping comment="VLAN1001 - 1 - Out" disabled=no distance=1 dst-address=0.0.0.0/0 gateway=195.222.54.166 routing-table=main scope=30 suppress-hw-offload=no target-scope=11
/ip route add comment="VLAN1001 - 2" disabled=no distance=1 dst-address=10.89.1.81/32 gateway=10.150.30.1 routing-table=main scope=10 suppress-hw-offload=no target-scope=10
/ip route add check-gateway=ping comment="VLAN1001 - 2 - Out" disabled=no distance=1 dst-address=0.0.0.0/0 gateway=10.89.1.81 routing-table=main scope=30 suppress-hw-offload=no target-scope=11


/ip route add comment="VLAN1003 - 1" disabled=no distance=1 dst-address=100.76.0.1/32 gateway=192.168.1.1 routing-table=main scope=10 suppress-hw-offload=no target-scope=10
/ip route add check-gateway=ping comment="VLAN1003 - 1 - Out" disabled=no distance=3 dst-address=0.0.0.0/0 gateway=100.76.0.1 routing-table=main scope=30 suppress-hw-offload=no target-scope=11
/ip route add comment="VLAN1003 - 2" disabled=no distance=1 dst-address=10.100.199.33/32 gateway=192.168.1.1 routing-table=main scope=10 suppress-hw-offload=no target-scope=10
/ip route add check-gateway=ping comment="VLAN1003 - 2 - Out" disabled=no distance=3 dst-address=0.0.0.0/0 gateway=10.100.199.33 routing-table=main scope=30 suppress-hw-offload=no target-scope=11

Log entries:

 2025-05-23 09:41:33 route,debug,calc Prepare queued IP/10.89.1.81/30-11/2
 2025-05-23 09:41:33 route,debug,calc Set initial reachability for IP/10.89.1.81/30-11/2
 2025-05-23 09:41:33 route,debug,calc Apply reachability to IP/10.89.1.81/30-11/2
 2025-05-23 09:41:33 route,debug,calc Resolving IP/10.89.1.81/30-11/2
 2025-05-23 09:41:33 route,debug,calc Resolved link IP/10.89.1.81/30-11/2 via 10.89.1.81->IP/10.150.30.1/11-10/0 FLD{1} rr has metric BEST/32
 2025-05-23 09:41:33 route,debug,calc route/calc/publish
 2025-05-23 09:41:33 route,debug,calc route/calc/cleanup/route
 2025-05-23 09:41:33 route,debug,calc route/calc/fwp/merge
 2025-05-23 09:41:33 route,debug,calc Prepare queued IP/195.222.54.166/30-11/2
 2025-05-23 09:41:33 route,debug,calc Set initial reachability for IP/195.222.54.166/30-11/2
 2025-05-23 09:41:33 route,debug,calc Apply reachability to IP/195.222.54.166/30-11/2
 2025-05-23 09:41:33 route,debug,calc Resolving IP/195.222.54.166/30-11/2
 2025-05-23 09:41:33 route,debug,calc Resolved link IP/195.222.54.166/30-11/2 via 195.222.54.166->IP/10.150.30.1/11-10/0 FLD{1} rr has metric BEST/32
 2025-05-23 09:41:33 route,debug,calc route/calc/publish
 2025-05-23 09:41:33 route,debug,calc route/calc/cleanup/route
 2025-05-23 09:41:33 route,debug,calc route/calc/publish
 2025-05-23 09:41:33 route,rpki,debug stats roas 0 roa 0 nodes4 0 nodes6 0
 2025-05-23 09:41:33 route,debug,calc route/calc/publish
 2025-05-23 09:41:33 route,rpki,debug wipe stats roas 0 roa 0 nodes4 0 nodes6 0
 2025-05-23 09:41:33 interface,info VLAN1001 detect INTERNET
 2025-05-23 09:41:41 route,rpki,debug stats roas 0 roa 0 nodes4 0 nodes6 0
 2025-05-23 09:41:41 route,debug,calc route/calc/publish
 2025-05-23 09:41:41 route,rpki,debug wipe stats roas 0 roa 0 nodes4 0 nodes6 0
 2025-05-23 09:41:43 route,rpki,debug stats roas 0 roa 0 nodes4 0 nodes6 0
 2025-05-23 09:41:43 route,debug,calc route/calc/publish
 2025-05-23 09:41:43 route,rpki,debug wipe stats roas 0 roa 0 nodes4 0 nodes6 0
 2025-05-23 09:42:04 route,debug,calc route/calc/fwp/merge
 2025-05-23 09:42:04 route,debug,calc Prepare queued IP/195.222.54.166/30-11/2
 2025-05-23 09:42:04 route,debug,calc Prepare queued IP/10.89.1.81/30-11/2
 2025-05-23 09:42:04 route,debug,calc Disqualified fwp IP/195.222.54.166/30-11/2
 2025-05-23 09:42:04 route,debug,calc Disqualified fwp IP/10.89.1.81/30-11/2
 2025-05-23 09:42:04 route,debug,calc Resolving IP/195.222.54.166/30-11/2
 2025-05-23 09:42:04 route,debug,calc Resolve as unreachable, gateway is not active
 2025-05-23 09:42:04 route,debug,calc Resolving IP/10.89.1.81/30-11/2
 2025-05-23 09:42:04 route,debug,calc Resolve as unreachable, gateway is not active
 2025-05-23 09:42:04 route,debug,calc route/calc/publish
 2025-05-23 09:42:04 route,debug,calc route/calc/cleanup/route
 2025-05-23 09:42:04 route,debug,calc route/calc/publish

For more background on the setup:
This is for a connection at a cottage house which has 3 Uplinks:

LTE Connection with Distance 1 (VLAN1001)
WISP Connection with Distance 2 (VLAN1000)
Wireless Bridge to neighbor with DSL as Distance 3 (VLAN1003)
The LTE Connection has Distance 1 and is most of the time unavailable. If I need higher speeds, I activate a Data package and the routing automatically switches to the LTE Conn. After the data has been used up, the connection gets disabled on the operators end until I book a new package
The WISP Connection is always available, but not as fast as LTE. It is used 90% of the time however
The Wireless Bridge to neighbor is used as last resort if both of the above fail for whatever reason, as one uplink is needed/preferred to control the heating and other smart home things

keskol · May 23, 2025, 8:16am

Once again, I can definitely rule out that the LTE Connection and therefore the IPs used to check are available once there is no data package booked. I have ran a ping towards them for over 24h from a raspberry pi directly connected to the LTE Router and I have a 100% package loss

jaclaz · May 23, 2025, 6:16pm

Post the output of:

/ip route print

thrice, once when everything is working as it is supposed to, once when you have the false positive (should be the same as the first), and once when the secondary link is down.

wiseroute · May 24, 2025, 4:46pm

@ keskol,

[]
However I am having an issue that some routes are marked as active, although the Check IP is not reachable in fact. Initially I used stuff like 8.8.8.8 and thought there might be a false positive due to the fact that 8.8.8.8 could be reached from another WAN line, however even after changing to next-hop addresses and making sure that these are only available through the corresponding interface when everything is normal, I am still having an issue where especially VLAN1001 is often marked as available, when in fact it is theoretically not possible. It even detects Internet
Due to trunking, my WANs are in 3 different VLANS. The IPs used to Check against are internal networks of ISPs, for details see below.
[]

sorry to quote that long lines.

it wasn’t false positive per se. it was due to vlan interface is always up interface unless you have disabled it.

vlan1001 can’t reach its gateway yes. but it still can route your tracked session to other vlan wan interface until the remaining tracked session for vlan1001 empty.

that’s why it’s not recommended to plug internet ip address on vlan interface unless it’s a reliable one for this wan backup context.