I have been using cisco devices in the past and I haven’t faced this problem until I used mikrotik.
Say I have:
LAN: 192.168.1.0/24
WAN1 gateway: 10.10.10.1 (Distance = 1)
WAN2 gateway: 11.11.11.1 (Distance = 2)
I’m not using any policy routing, juts normal default routing. All lan traffic to internet will default to WAN1 gateway. Then if WAN1 fails, or if I manually change the distance to 3, all traffic will flow to WAN2. Working fine so far.
/ip route
add comment=wan1 distance=1 gateway=10.10.10.1
add comment=wan2 distance=2 gateway=11.11.11.1
Here’s the problem:
When I issue “ping 8.8.8.8 -t”, on the lan computer, I receive a reply.
C:\>ping 8.8.8.8 -t
Pinging 8.8.8.8 with 32 bytes of data:
Reply from 8.8.8.8: bytes=32 time=24ms TTL=48
Reply from 8.8.8.8: bytes=32 time=24ms TTL=48
Reply from 8.8.8.8: bytes=32 time=4ms TTL=48
Reply from 8.8.8.8: bytes=32 time=27ms TTL=48
Reply from 8.8.8.8: bytes=32 time=35ms TTL=48
Reply from 8.8.8.8: bytes=32 time=2ms TTL=48
But as soon as I manually change the default route, the reply stops:
C:\>ping 8.8.8.8 -t
Pinging 8.8.8.8 with 32 bytes of data:
Reply from 8.8.8.8: bytes=32 time=24ms TTL=48
Reply from 8.8.8.8: bytes=32 time=24ms TTL=48
Reply from 8.8.8.8: bytes=32 time=4ms TTL=48
Reply from 8.8.8.8: bytes=32 time=27ms TTL=48
Reply from 8.8.8.8: bytes=32 time=35ms TTL=48
Reply from 8.8.8.8: bytes=32 time=2ms TTL=48
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
The solution is to press Ctrl-C and issue the ping command again. This time, reply will be received again.
Question: When I do continuous ping on computers on the LAN using cisco routers and I change the default route on the router, ping will fail temporarily but replies will be received after about 2 failed replies.
When I use mikrotik router and I change the default route, replies will not received until I issue another separate ping command.
Is this really the behavior of mikrotik in handling default routes or is there a solution to make it act like a cisco router?
I’ve run into that as well. I have suspected the LAN configuration (i.e. switching or bridging the LAN ports). I haven’t noticed a consistent behavior yet. Do you have multiple LAN interfaces and if so, how are they set up? How do you have your NAT configured?
Just a single LAN IP block on all lan ports, all lan ports are on a single bridge interface.
I declared my lan on an address-list.
/ip firewall address-list
add address=192.168.1.0/24 list=lan-users
Then declared NAT for each interface.
/ip firewall nat
add action=masquerade chain=srcnat out-interface=wan1 src-address-list=lan-users
add action=masquerade chain=srcnat out-interface=wan2 src-address-list=lan-users
It really puzzles my why I need to issue another ping command to receive replies again. It seems like a new command “refresh” the default route. I need to figure this out because some of our application will continuously wait for replies in these situations.
When you figure it our, please let us know. I’m sure we are not the only ones that have seen that 
Maybe connection tracking?
/ip firewall connection
I think that’s working as intended.
Prior to start pinging, MT actually establish connection-oriented communication with remote device, 8.8.8.8 in your case, in Transport layer. After handshake, packets start moving. When you manually change default route, you practically break session. Source Address in IP header is no more address of WAN1, its address of WAN2 now. And remote device is “waiting” packets from Source Address of WAN1. I don’t know how’s Cisco working, but you can do the same with MT.
At least, this is what think it’s going on. I didn’t put it trought Wireshark, so i can be wrong.
I tried changing the timeouts to 10 seconds. It marks connections as timeouts but the behavior of continuous ping on the client computer still stops.
Can you elaborate on how to change settings here?
Yes I’m trying to find out how to do it in mikrotik. Can you point which settings should I look at?
ping is icmp protocol.
/ip firewall connection tracking
Default on mine is 10 seconds.
Default on mine too is 10 secs.
The problem is, on the mikrotik terminal, ping will still have replies when I change the default route.
On the computer connected on the LAN, changing the default route will stop the ping replies. I need to issue another ping command to have replies.
I’m looking to replicate the behavior of cisco routers as this doesn’t happen.
Sorry to bring this one back from the dead but I have observed the exact same behaviour today.
It occurs for icmp, tcp and udp packets - I tried reducing the session timeouts, but if i watch the active conections, or just drops from the table after the session times out however the session is never reestablished and so traffic just stalls.
As previously noted, any newly sessions can be established without an issue, it’s just those that originate from before the route change.
FYI, in my case the MikroTik was performing NAT, I can try again without this on Monday.