Are there any known issues with VRRP? I'm trying to setup VRRP in Eve / GNS3 but I fail to do so, somehow.
My config is:
R1
# 2026-04-03 22:17:31 by RouterOS 7.22
# system id = IyfNhU9TahK
#
/interface ethernet
set [ find default-name=ether1 ] disable-running-check=no
set [ find default-name=ether2 ] disable-running-check=no
set [ find default-name=ether3 ] disable-running-check=no
set [ find default-name=ether4 ] disable-running-check=no
set [ find default-name=ether5 ] disable-running-check=no
set [ find default-name=ether6 ] disable-running-check=no
set [ find default-name=ether7 ] disable-running-check=no
set [ find default-name=ether8 ] disable-running-check=no
/interface vrrp
add interface=ether1 name=VRRP priority=150
/ip firewall connection tracking
set enabled=yes
/ip address
add address=192.168.0.2/24 interface=ether1 network=192.168.0.0
add address=192.168.0.1 interface=VRRP network=192.168.0.1
R2
# 2026-04-03 22:15:18 by RouterOS 7.22
# system id = B+Mgb7aR3gD
#
/interface ethernet
set [ find default-name=ether1 ] disable-running-check=no
set [ find default-name=ether2 ] disable-running-check=no
set [ find default-name=ether3 ] disable-running-check=no
set [ find default-name=ether4 ] disable-running-check=no
set [ find default-name=ether5 ] disable-running-check=no
set [ find default-name=ether6 ] disable-running-check=no
set [ find default-name=ether7 ] disable-running-check=no
set [ find default-name=ether8 ] disable-running-check=no
/interface vrrp
add interface=ether1 name=VRRP
/ip firewall connection tracking
set enabled=yes
/ip address
add address=192.168.0.3/24 interface=ether1 network=192.168.0.0
add address=192.168.0.1 interface=VRRP network=192.168.0.1
R1's and R2's ether1, alongside R3 are all connected to a dumb switch / bridge.
What's not working: pinging the VRRP IP address. I get no reply. From R3 (which is supposed to be a PC), I can ping 192.168.0.2 and 192.168.0.3 successfully, but not 192.168.0.1.
We’re experiencing the same issue in versions 7.22 and 7.22.1. I’m running it on CHR with P1 licenses under ESXi 8.0 Update 3 (both instances).
The IP failover between the two CHRs works correctly, but the VRRP address cannot be pinged. MAC addresses do appear in the ARP table, but no traffic actually flows through it. It only works if I configure a static IP instead.
In version 7.21.3 everything works perfectly, and it has been stable in previous versions for a long time. I recommend trying version 7.21.3—I think you’ll see the same behavior.
@rplant as @phoenixgeek also said, the VRRP instance is fine, it's up (only one of them at a time), everything seems fine.
The firewall is not enabled, so it's not a firewall issue, it's a simple VRRP interface added to two new routers. No firewall, no anything. Config above.
@phoenixgeek so this seems like a bug then? Glad to hear I'm not the only one with this issue. Have you reported it?
Maybe VRRP is a peculiar exception, but AFAICU a /32 address (with itself as network) is not pingable/reachable as it has an extremely narrow network (only itself):
Yep, but it doesn't say anywhere that the VRRP address is pingable, the interface (ether1) on which the vrrp interface is attached has another address, and this is the one that is pingable, from what I understand.
What I am trying to say (and not necessarily I am right, mind you) is that a /32 address with itself as network is not pingable by any other address in the same network, mainly because NO other IP exists in the same network (as a generic network rule).
That's not how it works.
You have the 192.168.0.2/24 IP address and that adds to your routing table a route, telling the router that 192.168.0.0/24 is reachable via ether1 ( for example).
Now, if you'd ping 192.168.0.1 there's no one to respond. That's where 192.168.0.1/32 comes into play. Now, when an arp request for 1992.168.0.1 comes in, via ether1 the VRRP master will reply.
When an icmp request will come in, the router will check its addresses and check if it owns 192.168.0.1 (icmp destination). It it does, it forms a response for that request, and then it will check the routing table to see on which interface that response should be sent.
Using /32 IP addresses is quite common (especially on loopback interfaces). This doesn't mean that the device owning the IP will not reply. A /32 will not add a route to the routing table. Other than that, it's and IP like any other.
Anyways, this used to work. The VRRP interface was pingable in 7.21 and I'm trying to determine if this is a bug or I'm missing something.
And the /32 does add a DAc route (with dst address 192.168.1.1/32 gateway vrrp1) to the routing table.
But if I remove the 192.168.1.2/24 IP from ether1, the DAc route (with dst-address 192.168.1.0/24 gateway ether1) vanishes (obviously) and the 192.168.1.1 is not anymore pingable.
The /24 route on ether1 is evidently used for the vrrp1 also, or the vrrp1 "depends" on the ether1.
Interestingly in winbox, with the interface list vrrp window open, the vrrp1 interface becomes red and shows the same error message "--- No IPv4 address!" if I disable either of the 192.168.1.1/32 (of the vrrp1) or the 192.168.1.2/24 (of the ether1).
So, if it works on 7.15.3 and on your 7.21, it is a change (or bug) in 7.22.
A /32 is required, otherwise packets get duplicated—even if only one MikroTik is running (you can clearly see it, for example, when pinging a host).
That said, I’ve now also configured a proper subnet on the VRRP interface, and it shows exactly the same behavior.
This is an automated message. Our bug tracker reports that your issue has been fixed. This means that we plan to release a RouterOS update with this fix. Make sure to upgrade to the next release when it comes out. To be sure this specific fix is included, read the changelog when the next version comes out. If your issue is not mentioned, it might mean it will be in the next release.
If you would like any more details - please reply to this message and one of our support engineers will contact you.
I was only looking at the non /32 routes due to a previous filter 
: