VRRP tracking — decrement priority on link failure, react to upstream state

VRRP tracking is the production mechanism for making VRRP react to upstream-state changes. Without tracking, a VRRP master continues to be master even when its uplink to the Internet (or to a critical downstream) is down. The hosts continue to send traffic to the virtual IP, but the traffic is black-holed at the master. Tracking solves this by decrementing the master’s priority when a tracked interface (or route, or remote ping target) goes down — making the backup the new master with its still-working uplink.

This lesson covers how tracking works, the three forms (interface tracking, route tracking, remote IP tracking), how to configure them, and the production failure modes that arise when tracking is not configured or is misconfigured.

What tracking does

A VRRP router has a configured priority (e.g., 200). When a tracked object goes down, the router decrements its priority by a configured value (e.g., 150). The effective priority becomes 200 - 150 = 50. If the backup has a static priority of 100, it now has a higher effective priority and becomes master.

flowchart LR
  subgraph BEFORE["Before uplink failure"]
    R1M["R1 (master)<br/>priority 200"]
    R2B["R2 (backup)<br/>priority 100"]
  end
  subgraph AFTER["After R1 uplink failure"]
    R1D["R1 (decremented)<br/>priority 50<br/>(200 - 150)"]
    R2N["R2 (new master)<br/>priority 100"]
  end
  BEFORE -->|Uplink fails| AFTER
  R1D -. tracked decremented .-> R2N

The decrement is not automatic; the operator must configure it. A typical configuration:

• R1: priority 200, tracks uplink to ISP-A with decrement 150. When uplink is up, effective priority = 200. When uplink is down, effective priority = 200 - 150 = 50.
• R2: priority 100, no tracking. Effective priority always 100.

When R1’s uplink is up, R1 is master (200 > 100). When R1’s uplink fails, R1’s effective priority drops to 50; R2 becomes master (100 > 50). The hosts now send traffic to R2 (the new master) which has a working uplink.

When R1’s uplink recovers, R1’s effective priority rises back to 200. With preemption enabled (default), R1 pre-empts R2 and becomes master again. With preemption disabled, R2 stays as master until its own uplink fails.

Three forms of tracking

VyOS 1.5 LTS supports three forms of VRRP tracking:

Interface tracking

Decrement priority when a specific interface goes down (admin down, link down, or no carrier).

# Configure interface tracking on eth1 (the uplink to ISP-A)
set high-availability vrrp group 1 track interface eth1
set high-availability vrrp group 1 track interface eth1 priority-decrement 150

When eth1 goes down (e.g., the ISP link fails), the priority drops by 150.

Route tracking

Decrement priority when a specific route disappears from the routing table. This is useful when the upstream state is more nuanced than a single interface (e.g., the route is via BGP and disappears when the BGP session drops).

# Configure route tracking for the default route
set high-availability vrrp group 1 track route 0.0.0.0/0
set high-availability vrrp group 1 track route 0.0.0.0/0 priority-decrement 150

When the default route disappears (e.g., BGP session to ISP-A drops), the priority drops by 150.

Remote IP tracking

Decrement priority when a remote IP becomes unreachable (via ping, BFD, or other mechanisms).

# Configure remote IP tracking for the upstream gateway
set high-availability vrrp group 1 track remote-ip 198.51.100.1
set high-availability vrrp group 1 track remote-ip 198.51.100.1 priority-decrement 150
# Set the ping interval and threshold
set high-availability vrrp group 1 track remote-ip 198.51.100.1 interval 5
set high-availability vrrp group 1 track remote-ip 198.51.100.1 threshold 3

When the remote IP (typically the ISP gateway or a critical service) is unreachable for 3 consecutive 5-second polls, the priority drops by 150.

Configuring tracking — full example

A full configuration of VRRP with tracking on VyOS:

configure

# R1 (master, tracks uplink to ISP-A)
set interfaces ethernet eth1 address 198.51.100.2/30
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 preemption delay 0
set high-availability vrrp group 1 advertisement-interval 1000
set high-availability vrrp group 1 version 3
# Track the uplink eth1; decrement by 150 if it fails
set high-availability vrrp group 1 track interface eth1 priority-decrement 150

commit
save

# R2 (backup, tracks uplink to ISP-B)
set interfaces ethernet eth1 address 203.0.113.2/30
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
set high-availability vrrp group 1 preemption delay 0
set high-availability vrrp group 1 advertisement-interval 1000
set high-availability vrrp group 1 version 3
# Track the uplink eth1; decrement by 150 if it fails
set high-availability vrrp group 1 track interface eth1 priority-decrement 150

commit
save

With this configuration:

• Both routers are up and both uplinks are up: R1 is master (priority 200 vs 100); R2 is backup.
• R1’s uplink fails: R1’s effective priority drops to 50; R2 becomes master (priority 100 > 50). Hosts send traffic via R2.
• R1’s uplink recovers: R1’s priority rises back to 200. With preemption enabled, R1 pre-empts and becomes master again.
• R2’s uplink fails while R2 is backup: nothing happens (R2 is not master; the tracking affects only the master election).
• Both uplinks fail simultaneously: R1 has priority 50, R2 has priority 50. Tie broken by IP address; the higher-IP router remains master.

Validation

# Check the tracking status
show vrrp track
# Shows the tracked interfaces, routes, or remote IPs and their state (up/down)

# Check the effective priority
show vrrp
# "Priority: 200" (configured) and the effective priority is shown when tracking is in effect

# Verify the tracked interface state
show interfaces eth1
# "state: up" or "state: down"

# Verify the tracked route
show ip route 0.0.0.0/0
# The route should be present (or absent if tracking is to fail)

# Trace the priority changes during a failure
tcpdump -ni eth0 'ip proto 112' -c 4 -vv
# The priority field will change when the tracking affects it

A clean validation: the tracking configuration is visible in show vrrp track; the effective priority matches the configured minus decrement; the priority changes during a simulated failure.

Production failure modes

Tracking not configured

The operator deploys VRRP but does not configure tracking. The master stays master even when its uplink fails. The hosts continue to send traffic to the master; the master has no upstream path; traffic is black-holed.

Diagnostic: show vrrp track shows nothing; the master is master regardless of uplink state.

Fix: configure tracking on the uplink interface or the upstream route.

Decrement too small

The operator configures tracking with a small decrement (e.g., 30). R1 has priority 200; the decrement is 30. R2 has priority 100. When R1’s uplink fails, R1’s priority is 170 (still higher than R2’s 100). The election does not flip; R1 remains master; the upstream is broken.

Diagnostic: show vrrp track shows the uplink failed; the effective priority is 170; R1 is still master.

Fix: increase the decrement to a value that makes R1’s effective priority lower than R2’s (e.g., 150 — giving R1 an effective priority of 50, lower than R2’s 100).

Both routers track the same uplink

The operator configures both R1 and R2 to track the same uplink (e.g., both track the LAN interface, which is always up). When the WAN fails (the link both routers’ uplinks depend on), both decrement priorities simultaneously. Result: both have the same priority; tiebreaker is IP; one remains master with no upstream.

Diagnostic: the WAN is down; both routers show the same effective priority (e.g., 50 vs 50); one is master by IP tiebreaker but has no upstream.

Fix: track each router’s own uplink, not a shared one.

Tracking flaps

A flaky uplink triggers tracking to oscillate (the priority goes down and up rapidly). The VRRP state flaps (master/backup alternation). The hosts see frequent connectivity interruptions.

Diagnostic: show vrrp track history shows the tracked object going up and down repeatedly; log records show priority changes.

Fix: address the underlying flapping (replace the flaky link); or use a smaller priority decrement so the priority change does not cross the election threshold.

Preemption disabled, but tracking would have flipped the election

The operator has preemption disabled (e.g., for asymmetric-traffic safety). R1 is master; R1’s uplink fails; tracking decrements R1’s priority to 50; R2 has priority 100. R2 should be the new master — but preemption disabled also applies to the tracking-driven election. R1 may or may not step down depending on the router implementation; some implementations still respect the priority comparison even with preemption disabled.

Diagnostic: show vrrp shows R1 as master despite the lower priority; the election did not flip.

Fix: enable preemption on the tracking-affected election (which usually means enabling it overall, or using tracking-specific preemption if available).

Rollback

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

# Compare
compare

# Remove the tracking configuration
delete high-availability vrrp group 1 track
commit

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

The rollback removes the tracking; the priority returns to the configured value; the VRRP election no longer reacts to uplink failure.

Production discipline

Cross-course references

• Part XL-02 (XL-VyOS-VRRP / priority and skew) covers the priority field that tracking modifies.
• Part XL-03 (XL-VyOS-VRRP / preemption) covers the preemption behaviour when tracking restores the original priority.
• Part XXXIX-02 (XXXIX-VyOS-MultiWAN / WAN failover) covers the wider WAN-failover context that VRRP tracking supports.
• Part XXXII-04 (XXXII-VyOS-BFD / BFD with OSPF) covers BFD, which can be used for remote IP tracking.

Quiz