All:
I just submitted a quick ticket because I’m having difficulty getting licensing on a few virtuals in my environment. I noticed that I submitted a ticket about VRRP v3 incompatibilities with Cisco back in November, and I haven’t been reached out to on that ticket.
Is that typical? I’m using quite a few of these devices in my day to day work and am not sure how this would fare if I had an actual insurmountable issue…?
These days the problem is that MT seems to downplay importance of this forum … so directing your issue here will probably have no effect what so ever.
Understandable. I would just be curious to the “usefulness” of tech support had I needed it in a panic situation - and if others have a similar experience of creating a ticket for it to just sit. Especially with something like Licensing - if I needed to obtain a license (and everything is cloud today…) and couldn’t, what’s my workaround? Probably nothing, but I hope the system gets back to function soon.
To my knowledge MT doesn’t offer 24/7 support with guaranteed response deadlines to end users. I’ve seen them mentioning support through certified distributors but I don’t know if they could support you any better.
Which, in a nut shell, means that one expecting support to mission critical applications should go with another vendor (with an order of magnitude larger price tags for sure). Support wouldn’t be for free, but it would be available this way or another.
You can ping them by adding a comment with “Any update?”. Dunno if that help. May change response from weeks to days, but not hours 
.
Presuming authentication is set to “none” since it’s not support in VRRPv3… One thing to try is “messing” with “Group Master”, it likely it should be set to “none”, but perhaps “self” etc may cause this to work. I recall some older bug that was fixed by doing that, not sure it help here but something to try while waiting.
Or…try using VRRPv2 instead of V3.
It’s been a minute - but the brand new Cat9300X that I installed wouldn’t do vrrp v2 if I recall correctly. VRRP v3 - the Mikrotik side was throwing CRC checksum errors. No authentication set on either side. I ended up just doing a hot cut - no worries, but would have been neat to safely transition the gateway. If I ever get another Cat9300X in to deploy/inventory, I’ll definitely re-lab it.
The company I’m with is doing a surprising amount of work with Mikrotik - and I’ve learned to use them well enough to slot them in where they make sense from a financial perspective. We had a pair running as L3 Cores for a data center for a short time (data center moniker is overkill, just a single rack - but still, tied the site together.) These were what we transitioned to Cisco - but again, I’ll still use Mikrotik where it makes sense and can interoperate with the architecture.
Thanks for the insight!
LOL. I use Mikrotik with VRRP since two redundant cheap routers has some benefits over one brand-name thing. They just make you do the testing & not having the setup in a lab make it tough to work with their support timeframes .
e.g. There have been various bugs where VRRP was broken in some way since they add the group-master and “sync connection” features. So bad timing on the specific RouterOS build you tried, might be a cause here.
If this is needed then one is supposed to go to a “Certified Consultant” to provide this service. https://mikrotik.com/consultants hoping they can work around the bugs.
You could post the ticket number here, so somebody can check the status. Maybe it has been answered, but mail got lost or something.
Are you using VRRP with IPv4 or IPv6?
With IPv4, there are some implementations that include the pseudo-header in the VRRP checksum calculation and this can lead in some interop problems.
This incompatibility has been an industry problem until rfc5798bis: https://datatracker.ietf.org/doc/draft-ietf-rtgwg-vrrp-rfc5798bis/; which should clarify that with section 5.2.8.
Looks like RouterOS does not offer the possibility to exclude IPv4 pseudo-header from the VRRP checksum calculation; from a ROS point of view and as other users suggested, if you want to fix this interop between CISCO and ROS you should probably try VRRPv2.