Skip to content

VRRP

Virtual Router Redundancy Protocol (VRRP) provides automatic gateway failover for IPv4 and IPv6 networks. VRRP combines multiple routers into a logical group called a Virtual Router (VR), allowing hosts to use a virtual IP as their default gateway while ensuring connectivity remains available if the primary router fails.

VRRP addresses the limitation of static routing where a failed gateway renders hosts unable to communicate beyond their local network. While dynamic routing protocols like OSPF or RIP solve this problem on larger networks, they introduce complexity that may be undesirable in simpler deployments. VRRP provides a lightweight alternative that delivers sub-second failover detection without the overhead of dynamic routing protocols.

In IPv6 networks, hosts discover routers through Router Advertisements in the Neighbor Discovery protocol. However, ND can take up to 38 seconds to detect an unreachable router. VRRP enables detection within 3 seconds without additional traffic overhead, making it essential for networks requiring rapid failover.

RouterOS implements VRRPv2 (RFC 3768) and VRRPv3 (RFC 5798), supporting both IPv4 and IPv6 networks with automatic failover and connection tracking synchronization.

VRRP operates by grouping routers into a Virtual Router identified by a Virtual Router ID (VRID). All routers in the VR share a virtual IP address, and one router operates as the Master while others serve as Backups. When the Master fails, the Backup with the highest priority takes over seamlessly.

The protocol uses multicast packets on protocol 112 (VRRP) to communicate between routers. IPv4 uses multicast address 224.0.0.18, while IPv6 uses FF02::12. All packets are sent with TTL=255 and are not forwarded by routers, ensuring VRRP traffic remains confined to the local network segment.

Understanding these fundamental concepts is essential for successful VRRP deployment:

Virtual Router (VR) - A logical group consisting of one Owner router and one or more Backup routers sharing the same VRID and virtual IP address. All routers in the VR must be configured with identical virtual IP addresses and VRID values.

Virtual Router ID (VRID) - A numeric identifier (1-255) that uniquely identifies the Virtual Router on a network segment. Multiple VRs can coexist on the same network using different VRIDs.

Master Router - The active router responsible for forwarding traffic for the Virtual Router. The Master sends periodic Advertisement packets to Backup routers and responds to ARP/ND requests for virtual IP addresses.

Backup Router - Standby routers that monitor the Master through Advertisement packets. When the Master becomes unavailable, the Backup with the highest priority becomes the new Master.

Virtual IP Address - The shared IP address configured on all VR members. This is the address hosts use as their default gateway. The virtual IP should not be configured as a real address on any router interface.

VRRP automatically assigns a virtual MAC address to each Virtual Router based on the standard VRRP MAC prefix. The first five octets are always 00:00:5E:00:01, and the final octet is the VRID value. For example, VRID 49 results in virtual MAC address 00:00:5E:00:01:31.

The Master router uses this virtual MAC address as the source for all Advertisement packets and responds to ARP requests for virtual IP addresses using this MAC. Backup routers do not respond to ARP requests for virtual IP addresses.

VRRP uses a priority-based election algorithm to determine the Master router. The router with the highest priority becomes Master, and all Backup routers monitor its availability through periodic Advertisement packets.

The Master sends Advertisement packets at configurable intervals (default: 1 second). Backup routers expect to receive these packets within a calculated Master Down interval. If three Advertisement intervals pass without receiving a packet, the Backup assumes the Master has failed and initiates the election process.

The Master Down interval is calculated as: Advertisement Interval × 3 + Skew Time, where Skew Time is derived from the router’s priority. This ensures Backup routers don’t trigger failover simultaneously, preventing oscillation.

When multiple routers start simultaneously or the current Master fails, the election process selects the new Master based on priority:

  1. Routers with priority 255 (Owner) are always elected Master
  2. Among other routers, the highest priority value wins
  3. If priorities are equal, the router with the higher primary IP address wins

Priority values range from 1-254, with 255 reserved for the Owner and 0 used by the Master to indicate it is releasing responsibility.

Each VRRP router operates within a three-state machine:

Init State - The initial state upon router startup or VRRP enablement. The router waits for a Startup event. When received, the router transitions to Master (if priority is 255) or Backup state.

Backup State - The router monitors Advertisement packets from the Master. If priority is 0 in an Advertisement, or if preemption is enabled and a higher priority is detected, the router transitions to Master. Backup routers do not respond to ARP requests for virtual IPs.

Master State - The router actively forwards traffic and sends Advertisement packets. It responds to ARP/ND requests for virtual IPs and sends Router Advertisements in IPv6. If a higher priority Advertisement is received, or the priority becomes 0, the router transitions to Backup.

Setting up VRRP for IPv4 requires creating a VRRP interface and configuring a virtual IP address. The following example creates a basic VRRP instance:

# Create VRRP interface on ether1
/interface vrrp add name=vrrp1 interface=ether1
# Configure real IP address on physical interface
/ip address add address=192.168.1.2/24 interface=ether1
# Configure virtual IP address on VRRP interface
/ip address add address=192.168.1.1/32 interface=vrrp1

Notice that only the interface parameter is required when creating the VRRP interface. Default values apply to other parameters: VRID=1, priority=100, authentication=none.

The VRRP interface address must use a /32 netmask when the address is from the same subnet as the physical interface. This is because the virtual IP floats between routers rather than being bound to a specific interface.

# Create VRRP with custom VRID and priority
/interface vrrp add name=vrrp1 interface=ether1 vrid=10 priority=150
# Configure authentication for security
/interface vrrp add name=vrrp2 interface=ether2 vrid=20 authentication=ah
# Set custom advertisement interval (500ms)
/interface vrrp add name=vrrp3 interface=ether3 interval=500ms
# Disable preemption for stable master selection
/interface vrrp add name=vrrp4 interface=ether4 preemption-mode=no

In IPv4 networks, the Master router responds to ARP requests for virtual IP addresses using the virtual MAC address. This ensures hosts send traffic to the correct gateway regardless of which physical router is currently Master. Backup routers silently discard ARP requests for virtual IPs.

IPv6 VRRP requires VRRPv3 and explicit IPv6 protocol configuration:

# Create VRRP interface for IPv6
/interface vrrp add name=vrrp1 interface=ether1 version=3 v3-protocol=ipv6
# Configure virtual IPv6 address with advertisement enabled
/ipv6 address add address=FEC0:0:0:FFFF::1/64 advertise=yes interface=vrrp1

IPv6 uses link-local addresses for VRRP communication between nodes, eliminating the need for additional address configuration beyond the global virtual address. The first address associated with the VR is always a link-local address.

In IPv6, the Master router sends unsolicited Neighbor Advertisement messages with the Router flag when it becomes Master. These advertisements notify hosts on the network that this router is now the gateway for the virtual addresses. The Master also responds to Neighbor Solicitation messages for virtual addresses.

Backup routers do not respond to Neighbor Solicitations for virtual addresses, ensuring only the current Master handles traffic.

This example configures a full active/standby VRRP setup between two routers. staging-router-01 acts as the primary (Master) and staging-router-02 acts as the standby (Backup). Both share virtual IP 192.168.1.1, which hosts use as their default gateway.

Hosts (192.168.1.x/24, gateway: 192.168.1.1)
|
ether1 (LAN)
/ \
staging-router-01 staging-router-02
192.168.1.2/24 192.168.1.3/24
priority=150 priority=100
\ /
ether2 (WAN / uplink)

staging-router-01 (Primary / Higher Priority)

Section titled “staging-router-01 (Primary / Higher Priority)”
# Physical interface address
/ip address add address=192.168.1.2/24 interface=ether1
# Create VRRP instance - VRID 10, priority 150 (will win election)
/interface vrrp add \
name=vrrp-lan \
interface=ether1 \
vrid=10 \
priority=150 \
preemption-mode=yes \
interval=1s
# Assign virtual IP to VRRP interface
/ip address add address=192.168.1.1/32 interface=vrrp-lan
# Enable connection tracking sync so failover preserves active sessions
/ip/firewall/connection/tracking/set enabled=yes
/interface vrrp set vrrp-lan sync-connection-tracking=yes

staging-router-02 (Standby / Lower Priority)

Section titled “staging-router-02 (Standby / Lower Priority)”
# Physical interface address
/ip address add address=192.168.1.3/24 interface=ether1
# Create VRRP instance - same VRID, lower priority (will be Backup)
/interface vrrp add \
name=vrrp-lan \
interface=ether1 \
vrid=10 \
priority=100 \
preemption-mode=yes \
interval=1s
# Assign the same virtual IP
/ip address add address=192.168.1.1/32 interface=vrrp-lan
# Enable connection tracking sync
/ip/firewall/connection/tracking/set enabled=yes
/interface vrrp set vrrp-lan sync-connection-tracking=yes

Run these commands on both routers to confirm the expected state:

# Confirm master/backup state and active flags
/interface/vrrp/print detail
# Watch for state transitions in the log
/log print where message~"vrrp"
# Verify the virtual IP is present on the Master
/ip address print where interface=vrrp-lan

On staging-router-01, status=master should appear. On staging-router-02, status=backup. To simulate failover, disable ether1 on the primary and confirm staging-router-02 assumes Master state and responds to ARP for 192.168.1.1.

When the LAN is served by a bridge (common in RouterOS setups that include switch chip offloading), configure the VRRP interface against the bridge rather than the underlying physical port.

# Existing bridge
/interface bridge add name=bridge1
# Add LAN ports to the bridge
/interface bridge port
add bridge=bridge1 interface=ether2
add bridge=bridge1 interface=ether3
add bridge=bridge1 interface=ether4
# Assign real IP to the bridge
/ip address add address=192.168.1.2/24 interface=bridge1
# Create VRRP on the bridge interface
/interface vrrp add \
name=vrrp-bridge \
interface=bridge1 \
vrid=20 \
priority=150
# Virtual IP on VRRP interface
/ip address add address=192.168.1.1/32 interface=vrrp-bridge

The second router uses the same configuration with priority=100 and its own real IP (192.168.1.3/24) on bridge1.

  • The virtual MAC (00:00:5E:00:01:<vrid-hex>) is placed in the bridge forwarding table automatically. No static FDB entries are required.
  • If the bridge has hardware offloading enabled, verify that multicast protocol 112 packets are not dropped by the switch chip. Disable hw-offload on the bridge port or add a bridge filter to accept protocol 112 if multicast packets are being silently dropped.
  • On CCR and CRS series, the bridge may need multicast-querier=no to avoid interfering with VRRP multicast packets.
# If multicast filtering causes issues, disable querier on bridge
/interface bridge set bridge1 multicast-querier=no

VRRP routers communicate using IP protocol 112 over multicast. Without explicit firewall rules permitting this traffic, RouterOS may drop VRRP advertisement packets, preventing Master election and causing both routers to remain in Backup state indefinitely.

Add these rules to the input chain on each VRRP router. Place them before any general-drop rules:

# Accept VRRP protocol (112) multicast from the local segment
/ip firewall filter add \
chain=input \
protocol=vrrp \
action=accept \
comment="Accept VRRP advertisements" \
place-before=0
# IPv6 equivalent (VRRPv3)
/ipv6 firewall filter add \
chain=input \
protocol=vrrp \
action=accept \
comment="Accept VRRPv3 advertisements" \
place-before=0

The protocol=vrrp matcher is equivalent to protocol=112 — RouterOS recognises the name. Both forms work.

When sync-connection-tracking=yes is enabled, the Master streams connection state to the Backup over UDP port 8275 (configurable). Add input rules on the Backup to permit this traffic:

# Accept connection tracking sync from VRRP peer
/ip firewall filter add \
chain=input \
protocol=udp \
dst-port=8275 \
src-address=192.168.1.2 \
action=accept \
comment="Accept VRRP conntrack sync from peer"

Replace 192.168.1.2 with the real IP of the Master router. Repeat on both routers, pointing at each other’s real IP (not the virtual IP).

If VRRP does not elect a Master, check whether firewall rules are dropping protocol 112:

# Add a logging rule to catch dropped VRRP packets (temporary, diagnostic)
/ip firewall filter add \
chain=input \
protocol=vrrp \
action=log \
log-prefix="VRRP-DROP-CHECK" \
place-before=0
# Then check the log
/log print where message~"VRRP-DROP-CHECK"

If entries appear, move the accept rule above the drop rule. Remove the logging rule once resolved.

See Firewall Filter Rules for general guidance on rule ordering and chain structure.

RouterOS v7 supports synchronizing connection tracking entries from Master to Backup, enabling stateful failover for firewall connections:

# Ensure connection tracking is enabled
/ip/firewall/connection/tracking/set enabled=yes
# Enable connection tracking sync on VRRP interface
/interface vrrp set vrrp1 sync-connection-tracking=yes

When a failover occurs, established connections are maintained on the new Master, providing seamless continuity for active sessions. This is essential for firewall rules that depend on connection state.

Connection tracking sync uses UDP port 8275 by default and requires connection tracking to be explicitly enabled if no firewall rules exist.

For load balancing across multiple routers, configure multiple VRRP groups with active-active connection tracking mode:

# Router 1 configuration
/interface vrrp
add connection-tracking-mode=active-active connection-tracking-port=8275 \
interface=ether1 name=vrrp30 priority=100 sync-connection-tracking=yes vrid=1
add connection-tracking-mode=active-active connection-tracking-port=8276 \
interface=ether1 name=vrrp40 priority=100 sync-connection-tracking=yes vrid=2
# Router 2 configuration
/interface vrrp
add connection-tracking-mode=active-active connection-tracking-port=8275 \
interface=ether1 name=vrrp30 priority=55 sync-connection-tracking=yes vrid=1
add connection-tracking-mode=active-active connection-tracking-port=8276 \
interface=ether1 name=vrrp40 priority=155 sync-connection-tracking=yes vrid=2

Each VRRP group has a different Master, distributing traffic across both routers while maintaining connection state synchronization.

Group multiple VRRP interfaces to ensure they share the same state. This prevents asymmetric routing when NAT or firewalls are involved:

# Create separate VRRP instances for LAN and WAN
/interface vrrp add name=vrrp-wan interface=sfp-sfpplus1 vrid=1 priority=100
/interface vrrp add name=vrrp-lan interface=bridge1 vrid=2 priority=100
# Group them so LAN controls the state
/interface vrrp set [find where name!=vrrp-lan] group-authority=vrrp-lan

When grouped, all interfaces transition to the same state. The group-authority interface controls the state machine, and all group members follow its state. If any group member detects a failure, all members transition to the failure state.

VRRP supports executing scripts on state transitions, enabling custom failover actions:

# Execute script when becoming Master
/interface vrrp set vrrp1 on-master="/system/script/run master-failover"
# Execute script when becoming Backup
/interface vrrp set vrrp1 on-backup="/system/script/run backup-activated"
# Execute script on failure
/interface vrrp set vrrp1 on-fail="/system/script/run vrrp-failure"

Scripts can be used to update monitoring systems, adjust routing tables, or trigger notifications when VRRP state changes.

ParameterDefaultDescription
interface(required)Physical interface for VRRP
vrid1Virtual Router ID (1-255)
priority100Election priority (1-254, 255 for Owner)
interval1sAdvertisement interval (10ms-4m15s)
preemption-modeyesAllow higher priority to become Master
authenticationnoneAH, simple, or none
version3VRRP version (2 or 3)
v3-protocolipv4Protocol for VRRPv3 (ipv4 or ipv6)
sync-connection-trackingnoEnable connection tracking sync
connection-tracking-modepassive-activeSync mode for connection tracking
connection-tracking-port8275UDP port for connection sync
group-authoritynoneGroup authority setting
arpenabledARP resolution mode
on-master(none)Script to execute on Master transition
on-backup(none)Script to execute on Backup transition
on-fail(none)Script to execute on failure
StatusDescription
backupRouter is in Backup state
masterRouter is in Master state
failureInterface failure detected
invalidConfiguration error detected
grp-authorityInterface is group authority
grp-memberInterface is group member

VRRP not electing Master - Verify all routers have matching VRID, virtual IP, and interval values. Check that firewalls allow VRRP protocol (112) multicast traffic.

Frequent Master/Backup transitions - Increase the advertisement interval to reduce sensitivity to packet loss. Verify network connectivity and check for bandwidth saturation.

ARP requests not reaching Master - Confirm the virtual MAC address is being used correctly. Check switch configuration for proper multicast handling.

Connection tracking not syncing - Ensure connection tracking is explicitly enabled with /ip/firewall/connection/tracking/set enabled=yes. Verify UDP port 8275 is not blocked.

# View VRRP interface status
/interface/vrrp/print detail
# Monitor VRRP events
/log print where message~vrrp
# Check VRRP state transitions
/tool/packet-sniffer filter protocol=112

VRRPv3 deprecated authentication as specified in RFC 5798. For environments requiring VRRP security, consider:

  • Deploy VRRP on isolated management networks when possible
  • Use AH authentication (authentication=ah) for VRRPv2 deployments
  • Implement network segmentation to limit VRRP packet exposure
  • Monitor for VRRP spoofing attempts using packet sniffing
  1. Use the same RouterOS version on all VRRP routers for compatibility
  2. Configure matching interval values on all VR members
  3. Use preemption-mode=no when rapid failover is less critical than stability
  4. Enable connection tracking sync for stateful firewall deployments
  5. Group LAN and WAN VRRP interfaces to prevent asymmetric routing
  6. Test failover scenarios before production deployment
  7. Use descriptive comments on VRRP interfaces for documentation