Skip to main content
RunBook Academy

VyOSXL · VRRP High AvailabilityVRRP

VRRP priority and skew — how election really works, the master-down-interval calculation

Advanced⏱ ~18 minshow vrrp detailconfigurecomparecommitsaverollbackvtyshtcpdumpip

What you'll learn

  • Explain the VRRP priority field (1-255) and the IP-owner special case
  • Calculate the master-down-interval from priority, skew, and advertisement-interval
  • Configure priority and skew to achieve the desired failover behaviour
  • Recognise the production failure modes where priority skew produces surprise election results

Prerequisites

Verified against VyOS 1.5.x LTS (circinus) · VyOS 1.4.x (sagitta) — legacy · FRRouting 10.x (VyOS 1.5) · Linux kernel 6.6 LTS (VyOS 1.5 base) · strongSwan 5.9.x (IPsec) · WireGuard 1.0.x (kernel module + userspace tooling) · 2026-08-15

Not yet marked complete on this device.

The priority field is the lever that controls which VRRP router becomes master. The skew field is the lever that controls how quickly the backup takes over when the master fails. Both are small integers in the configuration tree, but the behaviour they produce is non-obvious — the failover time is a function of priority, skew, and advertisement-interval combined, and the production operator who treats them as independent dials will misconfigure the failover behaviour.

This lesson covers how the VRRP priority field works, how the skew field contributes to the failover calculation, how the master-down-interval is derived, and the production failure modes that arise when these fields are not set consistently.

The priority field

Every VRRP router in a group has a priority between 1 and 255 (inclusive). The router with the highest priority becomes master. The election is straightforward: highest priority wins; ties are broken by the IP address (higher IP wins).

Three reserved values:

  • 255 — the IP address owner. A router with priority 255 that has the virtual IP as a real interface IP is the IP owner and is always the master regardless of any other VRRP traffic. This is a special mode used when the operator wants the router that “owns” the virtual IP to always be the master (rare in modern deployments because it requires the router to have the virtual IP configured on the interface before VRRP, which complicates failover).
  • 0 — reserved; indicates the router has stopped participating in VRRP. A master sending priority 0 indicates it is shutting down; backups use this as a fast-failover signal.
  • 100 — the default. Most routers that are not the IP owner use priority 100.

A typical production setup uses 100 (or 110) for one router and 200 (or 220) for the other. The differentiator is usually clear; the master has the higher priority, the backup has the lower priority. The exact values matter less than the relative order.

# R1: master (priority 200)
set high-availability vrrp group 1 interface eth0
set high-availability vrrp group 1 priority 200
set high-availability vrrp group 1 virtual-address 192.168.1.1/24

# R2: backup (priority 100)
set high-availability vrrp group 1 interface eth0
set high-availability vrrp group 1 priority 100
set high-availability vrrp group 1 virtual-address 192.168.1.1/24

The skew field

The skew is the second lever. It is a small integer (in centi-seconds — hundredths of a second) that delays the backup’s decision to take over. The purpose is to provide a graceful degradation: the backup waits a configurable time before announcing itself as master.

The math:

master_down_interval = (3 * advertisement_interval) + skew_time

Where:

  • advertisement_interval is the time between master advertisements (default 1 second).
  • skew_time is the skew value in seconds (skew is in centi-seconds; 100 = 1 second).

So with default settings (advertisement_interval = 1s, skew = 0), the backup declares the master down after 3 seconds (three missed advertisements). With skew = 200 (2 seconds), the backup declares the master down after 5 seconds.

The skew exists for a reason: the operator may want the backup to wait a moment longer than the strict protocol timeout to give the master a chance to recover. For example, if a master router’s CPU is briefly saturated (a microburst of traffic), the advertisements may be delayed by 100-200ms; with the default skew the backup might trigger a failover for what is really a transient. Setting a small skew (e.g., 50 = 0.5 seconds) gives the master more tolerance for transient slowness without artificially delaying the failover in a true failure.

gantt
    title VRRP failover timing with skew=200 (2s)
    dateFormat  X
    axisFormat %S
    
    section Master
    Advertisements    :a1, 0, 1000
    Failed            :crit, a2, 3000, 5000
    
    section Backup
    Waiting for advertisements :b1, 0, 4000
    Becoming master             :crit, b2, 5000, 5100
    
    section Detection
    3 missed adverts (3s) :done, d1, 0, 3000
    Skew delay (2s)       :done, d2, 3000, 5000
    Total failover        :crit, total, 0, 5000

Master down interval in practice

The typical failure window for VRRP failover is 3-4 seconds with default settings. This is acceptable for most use cases but is unacceptable for some — voice over IP, for example, cannot tolerate 3 seconds of routing interruption (the call drops). Operators who need faster failover use:

  • Sub-second advertisement interval. Set advertisement-interval to 100ms (the lowest allowed by the protocol). This makes the master-down-interval effectively 300ms + skew.
  • Disable skew. Set skew to 0 to remove the additional delay.
  • Use BFD for faster failure detection. BFD detects link failures in 50-150ms; integrate BFD with VRRP to reduce the failover time further.

The trade-off: faster failover means faster traffic interruption when there is a transient (e.g., a microburst of CPU saturation). The right balance depends on the network’s tolerance for false positives.

# Fast-failover VRRP configuration
set high-availability vrrp group 1 interface eth0
set high-availability vrrp group 1 priority 200
set high-availability vrrp group 1 virtual-address 192.168.1.1/24
set high-availability vrrp group 1 advertisement-interval 100
set high-availability vrrp group 1 preemption delay 0

# On the backup
set high-availability vrrp group 1 priority 100
set high-availability vrrp group 1 advertisement-interval 100
set high-availability vrrp group 1 preemption delay 0

The configuration above produces a master-down-interval of approximately 300ms + skew on each router (3 * 100ms + skew). With skew = 0, the failover is approximately 300ms — fast enough for most real-time applications.

IP address owner

A router with priority 255 that has the virtual IP as a real interface IP is the IP address owner. The IP owner is always the master — no election, no priority comparison. This is a special mode with specific use cases:

  • The router “owns” the virtual IP in the sense that the IP is on the interface regardless of VRRP state.
  • Other routers (priority 100-254) participate in VRRP as backups; they cannot become master unless the IP owner fails or stops sending advertisements.
  • If the IP owner is connected to the LAN and sending advertisements, no one else can be master.

The IP-owner mode is rarely used in modern deployments because it ties the router’s identity to the IP. A router swap (replacing the failed router with a new one) requires the new router to either take over the IP (which means reconfiguring the interface) or to be a non-owner backup that can take over via VRRP election.

# IP-owner configuration (rare)
# The virtual IP is also the interface IP
set interfaces ethernet eth0 address 192.168.1.1/24
set high-availability vrrp group 1 interface eth0
set high-availability vrrp group 1 priority 255
set high-availability vrrp group 1 virtual-address 192.168.1.1/24

This configuration makes the router the IP owner; the IP is always on the interface; VRRP election is irrelevant because priority 255 always wins.

Configuration and validation

The configuration of priority and skew on VyOS:

configure
# Master
set high-availability vrrp group 1 interface eth0 priority 200
set high-availability vrrp group 1 interface eth0 virtual-address 192.168.1.1/24
set high-availability vrrp group 1 interface eth0 advertisement-interval 1000
set high-availability vrrp group 1 interface eth0 preemption delay 0

# Backup
set high-availability vrrp group 1 interface eth0 priority 100
# same interface, same virtual address, lower priority

# Optionally, configure the skew
set high-availability vrrp group 1 interface eth0 skew 50

commit
save

Validation:

# Check the priority and skew
show vrrp detail
# "Priority: 200" and "Skew: 50 centi-seconds"

# Verify the master-down-interval computation
show vrrp detail
# "Master down interval: 3050 ms" (3 * 1000 + 50)

# Trace the failover timing
tcpdump -ni eth0 'ip proto 112'
# Capture advertisements; verify the interval is 1 second

A clean validation: priority values are different (e.g., 200 and 100), skew is configured as expected, the master-down-interval matches the calculation (3 * advertisement_interval) + skew.

Production failure modes

Identical priorities produce split brain

Two routers with priority 100 and 100 — both cannot determine a master from priority alone. The tiebreaker is the IP address; the higher-IP router wins. This is fine for two routers, but if the tie-breaker is not under operator control (e.g., DHCP assigns different IPs to each router on different boots), the result is unpredictable.

Diagnostic: show vrrp on both routers; priority values match. show vrrp detail shows the IP address tiebreaker.

Fix: set different priorities (e.g., 200 and 100); reload both routers to re-elect.

Skew delay too long

The operator configures a large skew (e.g., 3000 centi-seconds = 30 seconds) and the failover takes 30+ seconds. The hosts experience a 30-second outage.

Diagnostic: show vrrp detail shows skew = 3000. The master-down-interval is 33 seconds.

Fix: reduce the skew to a small value (e.g., 50 = 0.5 seconds) or 0.

IP owner does not release the IP on failover

The IP owner (priority 255, virtual IP also on the interface) fails. The backup takes over the VRRP role but cannot take over the IP — the IP is on the failed owner’s interface, not on the backup’s. Result: the LAN hosts send traffic to the virtual IP; the traffic goes nowhere because the IP is unreachable.

This is a known issue with IP-owner mode. The fix is to use priority 100-254 and not configure the IP on the interface. The IP is virtual only.

Sub-second advertisements on old hardware

The operator sets advertisement-interval 100 but the router is too slow. The actual interval is 1 second (the protocol floor). show vrrp detail shows the configured value (100ms) but the actual behaviour is the default (1s) — a misleading state.

Diagnostic: tcpdump on the LAN captures advertisements at 1-second intervals, not 100ms.

Fix: upgrade the hardware or accept the default interval.

Rollback

# Capture the running configuration
show configuration commands | grep vrrp | save /tmp/vyos-vrrp-priority-backup.txt

# Compare
compare

# Remove the priority change
delete high-availability vrrp group 1 priority
delete high-availability vrrp group 1 skew
delete high-availability vrrp group 1 advertisement-interval
commit

# Or restore a previous configuration
load /tmp/vyos-vrrp-backup.conf
commit

The rollback removes the explicit priority, skew, and advertisement-interval; the protocol falls back to the default (priority 100, skew 0, advertisement-interval 1s). The result is a working VRRP setup, just with longer failover times.

Production discipline

Cross-course references

  • Part XL-01 (XL-VyOS-VRRP / VRRP concept) covers the protocol basics and the virtual MAC address.
  • Part XL-03 (XL-VyOS-VRRP / preemption) covers how a higher-priority router takes over from a lower-priority master after recovery.
  • Part XL-05 (XL-VyOS-VRRP / tracking) covers how to decrement priority on link failure (the right way to influence election in a failure).
  • Part XLIX-04 (XLIX-VyOS-Monitoring / VRRP telemetry) covers monitoring priority changes and election events.

Quiz

Knowledge check · 4 questions

  1. Q1. Two VRRP routers: R1 priority 100, R2 priority 100. Advertisement interval 1 second. Skew 0 on both. The master fails and stops sending advertisements. After how long does the backup take over?

  2. Q2. A router configured with VRRP priority 255 is automatically the master regardless of any other VRRP traffic, including the router's own advertisements.

  3. Q3. A production site runs VoIP and uses VRRP for the default gateway. The VoIP gateway times out after 500ms. The default VRRP failover of 3 seconds is too slow. The operator wants to reduce the failover time. What are the options, and what is the trade-off?

    The site has two routers running VRRP group 1, virtual IP 192.168.1.1. R1 is master (priority 200, skew 0, advertisement-interval 1s); R2 is backup (priority 100, skew 0, advertisement-interval 1s). A router failure produces a 3-second VRRP failover. The VoIP gateway (a SIP gateway connected to the LAN) times out SIP INVITE messages after 500ms; a 3-second failover causes dropped calls. The operator needs sub-second failover.

  4. Q4. An operator configures VRRP with skew 200 on both routers. After a network blip, the routers begin flapping (alternating between master and backup). What is the cause and what is the fix?

    R1 (priority 200) and R2 (priority 100) are configured with skew 200 (2 seconds) and advertisement-interval 1000 (1 second). The master-down-interval is therefore 3 * 1s + 2s = 5 seconds. During a brief network blip (a 4-second Layer 2 outage), R2 sees no advertisements from R1 for 4 seconds, but the master-down-interval is 5 seconds. R2 does not yet declare R1 dead. However, after the Layer 2 outage ends, R2's advertisements reach R1 (which by now is sending again), and the routers re-converge. The flap was caused by something else, but the operators suspect the skew is the issue.

Passing score: 75%. Answers are checked in this browser.