MikroTik VRRP: How to Configure High Availability Step by Step

A single router as a default gateway is a single point of failure. When it goes down, every host pointed at it loses connectivity at the same moment — no failover, no warning, just a dead gateway. VRRP fixes this by giving two or more routers one shared virtual identity, so hosts keep working even when the physical router behind that identity changes.

This guide covers VRRP on RouterOS v7 from the ground up: core concepts, a full two-router configuration, priority and preemption, authentication, connection tracking synchronization for stateful failover, and the firewall rules and troubleshooting steps that catch the mistakes that break VRRP in production.

Table of Contents

1. What VRRP Solves
2. Core VRRP Concepts
3. Step-by-Step: Basic Two-Router VRRP
4. Priority and Preemption Explained
5. Securing VRRP with Authentication
6. Multi-Interface Consistency with Group Authority
7. Stateful Failover: Connection Tracking Sync
8. Firewall Rules for VRRP
9. Verification Commands
10. Troubleshooting VRRP
11. Quick-Reference Configuration Cheat Sheet
12. Deployment Checklist
13. Conclusion

What VRRP Solves

• The problem: Hosts on a LAN point at one default gateway IP. If that physical router fails, every host loses its route out — even if a second, fully capable router sits right next to it on the same switch.
• The VRRP fix: Multiple physical routers share one virtual IP and one virtual MAC address. Hosts point their default gateway at the virtual IP, never the real IP of any individual router.
• Only one router answers at a time. Among the participating routers, one becomes Master and actively handles traffic for the virtual IP. The rest sit as Backup, watching for the Master to disappear.
• Failover is automatic. When the Master stops sending its periodic advertisement, a Backup router takes over as the new Master — typically within seconds, with zero reconfiguration needed on connected hosts.

Core VRRP Concepts

• VRID (Virtual Router ID). A number from 1–255 identifying a specific virtual router. Every router participating in the same VRRP group uses the same VRID, and it must be unique on the network segment — a duplicate VRID from an unrelated VRRP group on the same LAN causes conflicts.
• Virtual IP. The shared gateway address hosts actually use. This address should not be configured as a real address on any physical interface — it belongs to the virtual router, not to any one device.
• Virtual MAC address. RouterOS derives this automatically from the VRID, using the prefix 00:00:5E:00:01 followed by the VRID in hex. VRID 1 becomes 00:00:5E:00:01:01; this MAC moves with the Master role, so ARP tables on the LAN never need to change during failover.
• Priority. A value from 1–254 that determines which router becomes Master. Higher priority wins the election. Default priority is 100.
• Protocol 112. VRRP runs as IP protocol 112 (also matchable as protocol=vrrp in RouterOS firewall rules), not TCP or UDP — this matters for any firewall rule that needs to allow it through.

Step-by-Step: Basic Two-Router VRRP

This example builds a VRRP pair on the LAN side: Router A (192.168.1.2) as the preferred Master, Router B (192.168.1.3) as Backup, sharing virtual IP 192.168.1.1.

1. Create the VRRP interface on Router A

/interface vrrp add name=vrrp1 interface=bridge1 vrid=1 priority=200

2. Assign the virtual IP to the VRRP interface

/ip address add address=192.168.1.1/32 interface=vrrp1

Use a /32 netmask for the virtual IP when the physical interface already holds an address in the same subnet — this avoids an address conflict between the real and virtual addressing on the same segment.

3. Repeat on Router B, with a lower priority

/interface vrrp add name=vrrp1 interface=bridge1 vrid=1 priority=100
/ip address add address=192.168.1.1/32 interface=vrrp1

• Same VRID (1) on both routers — this is what ties them into the same virtual router.
• Higher priority (200) on Router A makes it the preferred Master under normal conditions.
• Point every host’s default gateway at 192.168.1.1, never at the real IP of either router.

4. Confirm the election

/interface vrrp print detail

Router A should show master=yes; Router B should show as backup. Power off Router A and re-run this command on Router B — it should transition to Master within seconds.

Priority and Preemption Explained

• Preemption is enabled by default. When the higher-priority router comes back online after a failover, it reclaims the Master role automatically.
• Disable preemption when flapping matters more than optimal routing:

  /interface vrrp set vrrp1 preemption-mode=no

  With preemption off, a router that returns online stays in Backup rather than immediately reclaiming Master — useful when a router that reboots repeatedly would otherwise cause repeated, disruptive role switches.

• Priority 255 is reserved for a router with the virtual IP configured as a real address on its interface — this is the “IP address owner” case in the VRRP specification and behaves slightly differently from a standard election. Most deployments avoid this and use distinct, non-255 priorities instead.

Securing VRRP with Authentication

Without authentication, any device on the LAN segment could send VRRP advertisements and attempt to hijack the Master role. Set matching authentication on every router in the group:

/interface vrrp set vrrp1 authentication=simple password=YOUR-STRONG-PASSWORD

• All routers participating in the same VRID need identical authentication settings — a mismatch prevents the group from forming correctly.
• Simple password authentication is not encryption — it is a basic integrity check, not a defense against a determined attacker already on the segment. Treat VRRP as trusted-LAN-only traffic, and control access to that LAN segment separately.

Multi-Interface Consistency with Group Authority

A router often needs VRRP running on more than one interface — LAN and WAN, for example — and those interfaces need to fail over together, not independently. If the LAN-side VRRP elects Router A as Master while the WAN-side VRRP elects Router B, traffic ends up routing asymmetrically through both routers at once.

/interface vrrp add name=vrrp-lan interface=bridge1 vrid=1 priority=200 group-authority=1
/interface vrrp add name=vrrp-wan interface=ether1 vrid=2 priority=200 group-authority=1

Setting a shared group-authority value ties multiple VRRP interfaces on the same router together, so a failure detected on one interface forces all interfaces in the group to fail over consistently, rather than leaving the router split between Master on one interface and Backup on another.

Stateful Failover: Connection Tracking Sync

Without connection tracking sync, a failover breaks every active connection — the new Master has no record of in-progress sessions, and NAT’d or firewall-tracked connections drop even though the network path itself recovered instantly. RouterOS v7 solves this by syncing connection state from Master to Backup continuously.

/interface vrrp set vrrp1 sync-connection-tracking=yes

• Connection tracking must actually be running. By default RouterOS runs conntrack in auto mode, which activates only when firewall rules exist. If a VRRP router has no firewall rules configured, enable connection tracking manually:

  /ip firewall connection tracking set enabled=yes

• Sync flows one direction only — from Master to Backup. The Backup always has a current copy of the Master’s connection state, ready to take over instantly.
• With multiple VRRP interfaces between the same two routers, enable sync-connection-tracking=yes on only one of them — enabling it on more than one interface between the same pair is redundant and unsupported.
• Preemption interacts with sync: when both sync-connection-tracking and preemption-mode are enabled, a returning higher-priority router waits for connection state to sync first, then becomes Master — avoiding a window where it reclaims Master before it actually has current connection data.

Firewall Rules for VRRP

VRRP traffic and connection tracking sync traffic need explicit firewall handling — both use protocols that a default “allow established, drop new” ruleset will not automatically permit.

# Allow VRRP itself (protocol 112)
/ip firewall filter add chain=input protocol=vrrp action=accept comment="Allow VRRP"

# Allow connection tracking sync traffic (UDP port 8275 by default)
/ip firewall filter add chain=input protocol=udp dst-port=8275 src-address=192.168.1.3 \
  action=accept comment="Allow VRRP conntrack sync from peer"

• Place both rules before any general drop rule in the input chain — VRRP traffic dropped by an earlier catch-all rule prevents the group from ever forming, with no obvious error beyond “the router never sees Master.”
• Scope the conntrack sync rule to the peer’s real IP, not the virtual IP — sync traffic originates from each router’s actual address, not the shared virtual address.

Verification Commands

/interface vrrp print detail
/interface vrrp monitor vrrp1
/ip address print where interface=vrrp1
/log print where topics~"vrrp"

• /interface vrrp print detail — shows current role (Master/Backup), priority, and VRID for every configured VRRP interface.
• /log print where topics~"vrrp" — shows role transition history, useful for confirming failover actually happened at the expected time during a test.
• Test with a real failover, not just a config review — disconnect or power off the Master and confirm both the role transition and continued host connectivity through the virtual IP.

Troubleshooting VRRP

Router stays in Backup when it should be Master

• Cause 1: Priority is lower than expected, or lower than another router’s priority on the same VRID.
• Cause 2: Another Master is already active and reachable on the segment, so this router correctly remains Backup.
• Fix: Confirm priority values with /interface vrrp print detail on every router in the group, and confirm network connectivity between all participants.

VRRP never elects a Master at all

• Cause: Firewall rules are dropping protocol 112 traffic somewhere in the path, most commonly on the input chain of one or both routers.
• Fix: Add a temporary logging rule matching protocol=vrrp above the drop rule to confirm whether packets are being caught and dropped, then move the accept rule above the drop rule once confirmed. Remove the logging rule afterward.

VRID conflict — unexpected role changes or duplicate Masters

• Cause: Another VRRP group on the same LAN segment is using the same VRID, and the two groups are interfering with each other.
• Fix: Confirm the VRID is unique across every VRRP deployment on that specific network segment, not just within your own router pair.

Failover happens, but active connections still drop

• Cause: Connection tracking sync is not enabled, or connection tracking itself is not running on one of the routers.
• Fix: Confirm sync-connection-tracking=yes is set and that /ip firewall connection tracking print shows tracking as active on both routers.

LAN-side and WAN-side VRRP disagree on which router is Master

• Cause: No group authority configured, so each VRRP interface elects independently based on its own link state.
• Fix: Set a matching group-authority value across every VRRP interface on the same router that needs to fail over as a unit.

Quick-Reference Configuration Cheat Sheet

# Basic VRRP interface (Router A - preferred Master)
/interface vrrp add name=vrrp1 interface=bridge1 vrid=1 priority=200
/ip address add address=192.168.1.1/32 interface=vrrp1

# Basic VRRP interface (Router B - Backup)
/interface vrrp add name=vrrp1 interface=bridge1 vrid=1 priority=100
/ip address add address=192.168.1.1/32 interface=vrrp1

# Authentication (set identically on both routers)
/interface vrrp set vrrp1 authentication=simple password=YOUR-STRONG-PASSWORD

# Disable preemption if flapping matters more than optimal routing
/interface vrrp set vrrp1 preemption-mode=no

# Multi-interface consistency
/interface vrrp set vrrp1 group-authority=1

# Stateful failover
/interface vrrp set vrrp1 sync-connection-tracking=yes
/ip firewall connection tracking set enabled=yes

# Firewall: allow VRRP and conntrack sync
/ip firewall filter add chain=input protocol=vrrp action=accept
/ip firewall filter add chain=input protocol=udp dst-port=8275 action=accept

# Verify
/interface vrrp print detail
/log print where topics~"vrrp"

Deployment Checklist

• Use the same VRID on every router in the group, and confirm it is unique on the LAN segment
• Set the virtual IP with a /32 netmask when it shares a subnet with the physical interface
• Point every host’s default gateway at the virtual IP, never a physical router’s real IP
• Set distinct priorities so the intended preferred router wins the election
• Configure identical authentication on every router in the group
• Decide deliberately on preemption — enabled for optimal routing, disabled to reduce flapping
• Set matching group-authority across interfaces that must fail over together on the same router
• Enable connection tracking and sync-connection-tracking for stateful failover
• Allow protocol VRRP (112) and the conntrack sync port explicitly in the firewall, before any drop rule
• Test with a real failover — power off the Master and confirm both election and continued connectivity

Conclusion

VRRP removes the single point of failure a single gateway router represents, and RouterOS makes the basic setup genuinely simple — a VRID, a priority, and a shared virtual IP. The production-grade details are what separate a working demo from a reliable deployment: authentication to prevent hijacking, group authority to keep multi-interface routers consistent, and connection tracking sync so failover does not silently drop every active session. Get those three right, and a router failure becomes a non-event instead of an outage.

---

Check our list of MikroTik guides