RouterOS hot standby via VRRP

I had a RouterOS as a master router of network center, I need to set up hot standby now.

but the domain only routed to IP 1, If I using the example of the official wiki, It can’t route to the right IP address when the master router shutdown.

Normal:
example.com ===> 10.1.1.1(Master)
10.1.1.2(Backup)

Master router down:
example.com ===> 10.1.1.1(Error, router down)
10.1.1.2(As a hot standby router)

So it’s possible to set up the hot standby via VRRP with the same public IP address?

“Yes”, some years ago:
http://forum.mikrotik.com/t/vrrp-with-only-virtual-ip/53363/1

“No”, more recently:
https://forum.mikrotik.com//viewtopic.php?f=2&t=95829

I don’t see why the virtual IP needs to be in the same subnet as the real IPs. So long as the two real IPs can see each other, why does it matter?

While there are some usual configs, when you play with it a little, you’ll find out that pretty much anything goes. I’m not sure about interoperability, but if it’s just RouterOS routers, all they need is some IP address on physical interface. And I mean any address, whatever you put there works (at first, at least :wink:).

One problem could be if you start with the most standard setup (all addresses from same subnet) but you fail to give /32 netmask to virtual one(s). In that case routers sometimes get strangely confused.

One interesting thing is that it’s possible to “mix protocols”. Tell VRRP to use IPv6 and it will be happy with link-local addresses. And then you can add your single IPv4 address to virtual interface.

I hadn’t even thought of IPv6! A good justification for not using IPs in the same subnet would be if they were public IPs which obviously you don’t want to waste.

For the record, this combination of IPv6 with IPv4 is not exactly the most correct VRRP config, because IPv6 VRRP packets can’t contain IPv4 addresses (and the other way around). On the other hand, all you really need is the virtual MAC address and routers can figure that just fine. What IP address you stick to it is different matter. I didn’t see anything specifically prohibiting it in RFC (e.g. keepalived also supports this kind of virtual addresses not present in VRRP packets).