Morning All,
Does VRRP work on different subnet masks or do they have to be on the same one?
Thanks in advance.
Andy
Try to be more specific.
If it by chance answers what you are actually asking - I’ve set up IP addresses of the carrier interfaces (ether3) from one subnet, and the IP address of the vrrp interfaces using ether3 as carrier interface from another subnet, and it works fine and even if the “physical” and “virtual” subnets have different masks. But as @Sob says, your question is too vague.
VRRP is strange, both specification and implementations.
Specification deals with both MAC and IP addresses, even though just the virtual MAC address would be enough for the purpose. VRRP includes IP addresses in packets it exchanges, but can’t mix address families, so you either need separate virtual routers for IPv4 and IPv6, or you can add the other addresses just as extras that won’t be in exchanged VRRP packets. Keepalived (VRRP daemon for Linux) even allows to configure what same-family addresses should be exchanged and what should be hidden extras. So if there weren’t any IP addresses in VRRP packets at all, it wouldn’t really matter and things could still work (except the specification requires at least one).
The virtual MAC address, which seems as the core feature at first, is expendable too. Keepalived doesn’t use it by default and lives happily with just physical MAC addresses and gratuitous ARPs.
Then there’s the owner mode, where primary router has some IP address on its physical interface and if it dies, secondary router turns this IP address into virtual IP address. That’s not supported by RouterOS for a change.
Netmasks, VRRP doesn’t seem to care about them at all. The usual way is to have virtual IP addresses from same subnet as the parent interface uses, but with /32 netmasks. If same netmask is used in this case, it doesn’t end well. But if you add virtual address from different subnet, then it doesn’t seem to cause any issues, even when it’s not /32. Oh and when VRRP puts it in its packets, it strips the mask and only sends bare IP address. So if you’d for some reason (I can’t find any myself) wanted the virtual address with one mask on first router and with another on second, nothing stops you.
And subnets on parent interfaces doesn’t seem to matter either. If I use one /24 on first router and completely different /24 on second router, nothing complains and everything seems to work fine.
Historically, the idea behind was that it took minutes to Windows to discover a change of MAC address of the default gateway, and they were either ignoring gratuitous ARP or it was not invented yet. I’ve never tried how Windows would handle such change nowadays without the gratuitous ARP, and I don’t have the tools necessary to create a gratuitous ARP handy.
Other than the above, there may be some features aimed just to make VRRP different enough from HSRP so that the former could not be called a repaint of the latter.
And, using the opportunity - can you confirm my understanding that in VRRPv3, which Mikrotik uses by default, the transition from backup to master mode should happen in between 0.3 and 0.4 seconds if the interval is set to 100ms? Because even with priorities 254 and 253, it takes the backup Mikrotik about 5 seconds to become the new master after the old master becomes silent, so I’d like to have a second opinion before raising a ticket with support.
You made me look at RFC. 
And yes, if original master router dies, then with 100ms interval, backup router should become master in 0.3-0.4 seconds, depending on its priority. My quick test with current CHRs (6.44beta9) says that it works. Millisecond here and there, but with running mtr at 0.1s interval, there are three lost pings, so that’s it.
What does take at least 5 seconds is when new higher-priority master takes over previous low-priority master. It does depend on interval, but around 5 seconds seems to be minimum even for 10ms interval. I can’t find where this comes from.
Look this tutorial in dutch but it’s verry clear.