Hello everybody. Faced with the strange behavior of Mikrotik and now I’m wondering - it’s a bug.
The behavior is as follows: there is a hEX with iOS 4.7. and two uplinks. Using the netwatch mechanism, monitor ip 8.8.8.8 to check the availability of the channel. The idea is usual - to switch to the reserve when the main channel falls. And I noticed that by running ping on 8.8.8.8 with a live main channel, I get a normal response. When the main channel is disconnected, ping disappears and does not resume, although the routing table changes.
If the ping command is not reset and started again, then it will continue to ping unsuccessfully. But if you restart it, then everything will pass. The question is - a bug or a feature?
It is probably not caused by the netwatch ping itself but by connection and packet marking and routing selection you made elsewhere to make your dual-uplink work.
Yes, routing table correctly chenges and new ping goes throu Mikrotik to 8.8.8.8 succesfully.
Show your /export hide-sensitive
[MY_Home_Mikr] > export hide-sensitive
jul/30/2020 11:23:57 by RouterOS 6.45.9
software id = IJGR-G7PR
model = RB750Gr3
/interface bridge
add name=bridge1 protocol-mode=none
add admin-mac=C5:Ae:35:87:5A:B6 auto-mac=no comment=defconf name=bridgeLocal protocol-mode=none
/interface vlan
add comment=FOR_MANAGEMENT interface=ether1 name=“VLAN 4” vlan-id=4
add comment=UPLINK_MAIN interface=ether1 name=“VLAN 5” vlan-id=5
/interface bonding
add mode=active-backup name=bonding1 primary=ether4 slaves=ether4,ether5
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/ip dhcp-server
add disabled=no interface=bridge1 name=server1
/ip hotspot profile
set [ find default=yes ] html-directory=flash/hotspot
/interface bridge port
add interface=ether2
add interface=ether3
/ip settings
set route-cache=no <— i halted this option
/ip address
add address=192.168.1.1/24 interface=bonding1 network=192.168.1.0 <— MY SECONDARY UPLINK
add address=192.168.29.122/30 interface=“VLAN 5” network=192.168.29.120 <— MY WORK TRAFFIC THROU ETH1
add address=172.40.30.233/30 interface=“VLAN 4” network=172.40.30.232 <— MY MANAGEMENT IP FOR MIKROT THROU ETH1
add address=192.168.40.1/30 interface=ether2 network=192.168.40.0 <— MY LAN
/ip dhcp-server network
/ip dns
/ip firewall filter
add action=accept chain=input in-interface=ether1 src-address=8.8.8.8
add action=drop chain=input in-interface=bonding1 src-address=8.8.8.8
add action=drop chain=output dst-address=8.8.8.8 out-interface=bonding1
add action=drop chain=input disabled=yes
/ip firewall nat
add action=masquerade chain=srcnat src-address=192.168.40.0/30
/ip route
add comment=UPLINK1 distance=1 gateway=192.168.29.121
add comment=UPLINK2 disabled=yes distance=10 gateway=192.168.1.2
add comment=“monitor ip” distance=1 dst-address=8.8.8.8/32 gateway=192.168.29.121
/system clock
set time-zone-name=Europe/Copenhagen
/system identity
set name=MY_Home_Mikr
/tool netwatch
add down-script=“/ip route set [find comment="UPLINK1"] disabled=yes
\n/ip route set [find comment="UPLINK2"] disabled=no” host=8.8.8.8 interval=10s up-script=
“/ip route set [find comment="UPLINK1"] disabled=no
\n/ip route set [find comment="UPLINK2"] disabled=yes”
[MY_Home_Mikr] > quit
Ok I see you do not perform any connection marking..
Try to set the source IP address on the routes.
It’s not clear from what you wrote whether you are pinging 8.8.8.8 from the Mikrotik itself or from a device on a LAN. I suppose the latter, in that case, the explanation is how the NAT works. The sequence of ping requests and responses is handled by the firewall as any other tracked connection, so the firewall chooses the public IP to be used for all packets of that connection when processing the first one of them, and doesn’t change it even if the interface to which the address is attached fails - it wouldn’t make sense for “normal” connections (TCP, UDP) as the server identifies the connection by the client address, so the connection would fail anyway. In case of ping, this wouldn’t be a problem, but the firewall doesn’t have a special NAT treatment for ping.
Well, there is a netwatch running on the router itself…
Maybe the ping used by netwatch determines the source address only one time, I do not know. I would not expect it.
I suspect you are doing a continues pin from a device in the LAN?
No, not a bug.
The route has been cached, hence the symptoms. If you prefer, you can disable route cache in ip settings, but this can have negative performance impact
Hallo.
I perfom ping from my LAN ip on Mikrotik - 192.168.40.1
Hi, sindy.
I am pinging 8.8.8.8 from my LAN ip on the device itself. Link on LAN interface of course ON.
Yes, i also think that NAT could makes some influent. Ooooh, so behavior of my Mikrotik concerns only ICMP? Good? good. I will test it.
Yes! And netwatch sucsessfuly makes it’s work. My routing table changes acording to netwatch’s actions.
That’s right, i make continues ping from a device in the LAN. And i disabled my route cache, because i thougth that it may be the reason of this strange behavior. But with desabled route cache the problem still exists.
I think it is better to setup an actually working failover system e.g. using recursive routing.
Recursive routing also pings the reference IPs every 10 seconds (so no improvement in the reaction on the interface going down) and the same issue will remain.
If you ping from the LAN IP of the Mikrotik itself, your action=masquerade rule, which matches on the whole subnet as src-address, also changes the source IP of the connection to the one of the WAN through which the first ping request packet is sent out. Without that masquerade rule, the packets would be leaving with the private address unchanged, so either the ISP would not let them through or the responses would never reach your device.
No, you’ve understood me inversely - ICMP echo is handled the same way like UDP, TCP etc. although it could be handled differently due to different properties of the protocol. But it would be too much coding for too little benefit.
Yes, i have such NAT action. I masquerade ip packets with sourse from LAN.
Uffff, i setup secont Mikrotik.
Did you restart the router after disabling route cache?
Hi.
Yep. i restarted my router after disabling this option. The unstopable ping still exist.
But did you already try using recursive routing with route check? As shown in examples.
And also get rid of the bonding interface and try in with a plain ethernet port, maybe there is some difference there too.