Hi
I am running two routers (Cisco and Mikrotik) with VRRP on the LAN. MT is master with higher priority. I am doing a connection tracking to verify that MT has upstream through the WAN. If upstream fails switchover to Cisco is done as it should be because of connection tracking. If connection tracking target is available again I want to have MT as master again but connection tracking and preemption is not allowed to configure side by side. Any idea how to overcome this?
Thx
Richard

I think I have a general understanding issue with this connection tracking. I am pretty new to MT and thought it is like Cisco does tracking with e.g. ip sla or interface states. As I have read now connection tracking is somehow exchanging state information between vrrp master and slave but for this both routers have to be MT with same OS version.
I am running mixxed environment; Cisco and MT. If MT is the vrrp master on the LAN I need some functionality where MT checks if upstream is available on WAN (e.g. interface state or icmp reachability of an address). If this test is failing vrrp priority shall be decreased to become vrrp slave. If upstream is available again priority shall be again as usual.
Any idea how to achieve this?
Thanks
Richard

First, there is a vernacular issue. "connection tracking" in the Linux and Mikrotik environment is a key part of stateful firewall implementation, allowing to identify packets belonging to previously seen TCP sessions, bi-directional UDP flows and alike. Your use of that term suggests that you have in mind monitoring of uplink availability (reachability of the external network via that uplink).

In the VRRP configuration, the configuration item sync-connection-tracking allows the current master router to continuously update the connection tracking table on the backup one, so that the established connections would be deemed established also by the backup one once it eventually becomes a master. This has nothing to do with the uplink availability monitoring.

You can use /tool netwatch to monitor uplink availability by pinging a single IP address with a configurable periodicity and execute a script on state change to "up" and on state change to "down". However, a single canary address may give false alarms (I've even seen Google DNS to stop responding for minutes in multiple countries some weeks ago), and there is a specific handling of privileges for netwatch, hence it is better to use a scheduled script to evaluate the state of multiple netwatch instances and manipulate the VRRP priority accordingly. But once you use a scheduled script, you can use it also to implement your own strategy of pinging (like pinging the canary addresses one by one until the first response rather than pinging all of them all the time) or you can even use a recursive next-hop search rather than netwatch to take care of the uplink availability monitoring, and let the scheduled script monitor only the resulting state of the recursive route. The periodicity of the pings is hardcoded to 10s for the check-gateway process of the recursive routes.

Without synchronized connection tracking, established connections may stop working once the backup router becomes a master; with synchronized connection tracking (not your case), other problems may arise from connections not being removed if there is NAT on the uplink (UDP connections updated from the LAN side keep being src-nated to the dead WAN IP address and thus either the packets sent by your LAN hosts get dropped further in the internet for having an unexpected source IP, or the responses to these packets never reach your router because they are routed via the dead uplink).

Hi Sindy,
thanks for the detailed answer which gives me the appropriate insights. Appreciate it!
Monitoring the upstream is done in our case not with a google DNS but with a high availability address within our ISP backbone. Pretty sure to have a good availability of this address and if it is not reachable I really do not care if a CPE does the appropriate switch over because it would not reach the internet any more and I have other problems to solve
So it seems that I have to look into scripting (which I wanted to avoid)
Regards Richard

Perhaps not relevant to your setup but this is in changelog for release 7.5
*) vrrp - added "sync-connection-tracking" compatibility with preemption-mode;

So now they should work together. I have not tested this however.