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.