Try it without sync-connection-tracking to confirm it works first. e.g. sync-connection-tracking=no
I’m not seeing where you’re specifying the remote address to sync with either. Note that sync-connection tracking will only work if the WAN IP is also same on both routers.
It could be version specific. There have been bugs in VRRP in a few releases. You’d have to look at the release notes for “vrrp -”. But more with sync-connection-tracking=yes - why I suggest you don’t use that unless you really understand how suppose to works.
Also, perhaps a cut-and-paste error, your last rule will NAT everything, which may include VRRP. You may want remove that line.
I´ve deleted that line of configuration, but it still have problems.
I´ve updated both routers to 7.14.2 router os and still have problems.
Now, if I configure in one router priority 254 and the other with priority 1, I have router with priority 1 as master and router with priority 254 as backup.
Don’t know if case here… But that can happen if preemption-mode=no. e.g. backup starts up before the master, priority won’t matter when preemption-mode=no if backup is running. See docs:
preemption-mode > Whether the master node always has the priority. When set to ‘no’ the backup node will not be elected to be a master until the current master fails, even if the backup node has higher priority than the current master.
Do you still have sync-connection-tracking enabled? Maybe post current config.
First router on 7.16.2 firmware and second router on 7.18.2 firmware. VRRP works as expected, connection tracking and preemption mode. the 7.16.2 has 254 priority and preemption mode enabled, while 7.18.2 has 100 priority and disabled preemption mode. Restarting any of them works correctly to became master-slave. The only drawback the 7.18.2 router shows ‘Connection tracking innactive’ for VRRP instance, but the connection tracking is working.
Then I upgrade the first router to 7.18.2. No config is changed on both routers. VRRP brokes. Both routers have VRRP as master. Its like they do not see each other. But nothing changed in config in firewall. Only a firmware update was made.
I see this as a major bug in 7.18 versions of routeros. 7.16 works as expected, 7.18 breaks VRRP.
Mimiko, I call BS, you didnt originate the thread, popped in to complain, and have not provided the configs of your devices…
/export file=anynameyouwish ( minus router serial number, any public WANIP information,keys)
Great, that means Mikrotik has at least acknowledged the issue. The next step is to push the matter further and raise awareness in the two release channels that are currently active: v7.18.2 [stable] is released! v7.19beta [testing] is released!
Post a short description of the problem, like in this thread, and also mention that you’ve already reported it to support.
Well, what I did to solve the problem, is change V3 protocol to Version 3 and protocol IPv4, setting vrrp IP address to prefix /32 (don’t know if this matters). Seems that using V3 protocol IPv6 does not work, or is not configured correctly for me. Strangely in mikrotik version 7.16.2 it works.
Just for knowledge, I was stuck in the same issue, I tried to downgrade routeros firmware but I was stuck in the master/master issue.
Finally I found the problem: I was using “Trunk channel” for the upstream Procurve 1800-24G switch for the two ports on where I mapped the vrrp virtual devices. With Trunk (LACP) enabled VRRP didn’t exchange correctly the handshake and both router were master. When I turned off the trunk for the tho port magically the VRRP started working. I didn’t find anything about this issue so I wrote this note.