VRRP concept — Virtual Router Redundancy Protocol, master/backup, virtual MAC

Virtual Router Redundancy Protocol (VRRP) is the first-hop redundancy protocol a VyOS engineer reaches for when two (or three) routers share the default gateway role for a LAN and the LAN cannot tolerate a single router’s failure. VRRP is the production standard for IPv4 first-hop redundancy, defined in RFC 5798 (version 3) and originally specified in RFC 3768 (version 2). It is conceptually similar to Cisco’s HSRP and to the older Virtual Router Redundancy Protocol; the principle is the same — two or more routers share a virtual IP and a virtual MAC, the elected master owns the pair, and the backups take over if the master fails.

This lesson is the conceptual reference for VRRP on VyOS 1.5 LTS / FRR 10.x: what VRRP is at the protocol level, why a production network uses it, how the master/backup election works, what the virtual MAC buys you, and the operational commands to validate the result. The configuration itself is covered in the next lessons; this one is the model.

What VRRP solves

A host on a LAN has a default gateway — the IP address to which the host sends all off-network traffic. The default gateway is, in most deployments, a single physical router. If that router fails, the host’s traffic stops flowing off-network, even if a second physical router is sitting right next to it on the same LAN. The host has no way to know that the second router exists; its ARP cache still points at the failed router.

VRRP solves this by inserting a virtual router between the hosts and the physical routers. The virtual router has its own IP address (the “virtual IP”) and its own MAC address (the “virtual MAC”). The hosts use the virtual IP as their default gateway. The physical routers (the “VRRP routers”) participate in an election; the elected master owns the virtual IP and answers ARP requests for it. If the master fails, one of the backups takes over and starts answering ARP requests for the same virtual IP and MAC.

flowchart LR
  H1["Host A<br/>192.168.1.10"]
  H2["Host B<br/>192.168.1.11"]
  GW["Virtual IP<br/>192.168.1.1<br/>virtual MAC<br/>00:00:5E:00:01:01"]
  R1["R1 (master)<br/>priority 200"]
  R2["R2 (backup)<br/>priority 100"]
  NET["Upstream network"]
  R1 -. "owns" .-> GW
  R2 -. "monitors" .-> GW
  H1 -- "ARP for 192.168.1.1" --> GW
  H2 -- "ARP for 192.168.1.1" --> GW
  GW -- "answered by" --> R1
  R1 --> NET
  R2 --> NET

The hosts see only the virtual IP. They never know which physical router is the master. When R1 fails, R2 takes over within a few seconds (typically 3 seconds, the default VRRP advertisement interval is 1 second plus a skew), and the hosts’ ARP caches remain valid because the virtual IP and virtual MAC are unchanged. The failover is transparent.

Master and backup election

VRRP routers on the same LAN (in the same “VRRP group”) elect a master. The election is based on a configurable priority (1-255, with 255 reserved for the IP address owner; the default is 100). The router with the highest priority becomes the master; ties are broken by the IP address (the higher IP wins).

When the master fails (stops sending advertisements), the backup with the highest priority takes over and becomes the new master. The failover time depends on the advertisement interval and the priority skew; with the default values, failover takes 3-4 seconds (3 advertisements of 1 second each plus processing delay).

sequenceDiagram
  participant R1 as R1 (priority 200)
  participant R2 as R2 (priority 100)
  participant LAN as LAN
  Note over R1,R2: Both routers boot
  R1->>R2: VRRP advertisement (priority 200)
  R2->>R1: VRRP advertisement (priority 100)
  R1->>LAN: ARP for virtual IP
  Note over R1,R2: R1 is master (higher priority)
  R1->>LAN: advertisements every 1s
  R2->>R2: waiting, monitoring
  Note over R1,R2: R1 fails
  R2->>R2: no advertisements for 3.6s
  R2->>LAN: gratuitous ARP for virtual IP
  R2->>R2: becomes master

The election is fast and deterministic. The protocol guarantees that exactly one router is master at any time; if two routers somehow become master (the “split-brain” failure mode), both answer ARP for the virtual IP and the LAN ends up with traffic going to both — usually destroying connectivity.

The virtual MAC address

Each VRRP group has a virtual MAC address derived from the group ID. For IPv4 VRRP, the address is 00:00:5E:00:01:XX where XX is the VRRP group ID in hex. A group 1 has virtual MAC 00:00:5E:00:01:01; group 10 has 00:00:5E:00:01:0A; group 255 has 00:00:5E:00:01:FF.

The virtual MAC is the key to fast failover. When the master fails, the backup starts using the same virtual MAC. The hosts’ ARP cache (which maps virtual IP to virtual MAC) remains valid; only the source of frames with that MAC changes. There is no need to flush the ARP cache or wait for ARP timeouts.

# Inspect the virtual MAC on a VyOS host
$ show vrrp
Virtual Router 1 - Master
  State: Master
  Virtual IP: 192.168.1.1
  Virtual MAC: 00:00:5E:00:01:01
  Priority: 200
  Advertisement interval: 1s
  Skew: 0.0s
  Preemption: enabled

The virtual MAC also has implications for switch learning. The LAN switch learns that the virtual MAC is reachable via a particular switch port (the port connected to the master). When the master fails and the backup takes over, the switch must relearn the MAC’s location — a process that takes 5-15 seconds with the default MAC aging timers. This is why some deployments tune the MAC aging timers down (e.g., to 1-2 seconds) to make the failover faster.

VRRP advertisement packets

VRRP routers communicate via IP multicast. VRRPv2 uses multicast address 224.0.0.18; VRRPv3 uses the same. The advertisements are sent by the master every advertisement interval (default 1 second) and contain the master’s priority and the virtual IP addresses.

# Capture VRRP advertisements on a VyOS host
$ tcpdump -ni eth0 'ip multicast and src host 192.168.1.254' -c 4
12:34:56.789012 192.168.1.254 > 224.0.0.18: VRRPv2, Advertisement, vrid 1, prio 200, authtype none, intvl 1s, length 36
12:34:57.789234 192.168.1.254 > 224.0.0.18: VRRPv2, Advertisement, vrid 1, prio 200, authtype none, intvl 1s, length 36
12:34:58.789456 192.168.1.254 > 224.0.0.18: VRRPv2, Advertisement, vrid 1, prio 200, authtype none, intvl 1s, length 36
12:34:59.789678 192.168.1.254 > 224.0.0.18: VRRPv2, Advertisement, vrid 1, prio 200, authtype none, intvl 1s, length 36

The captures show the source IP of the sending router (a real IP, not the virtual IP), the multicast destination (224.0.0.18), the VRRP version (v2 or v3), the VRRP group ID, the master’s priority, and the advertisement interval. An operator who sees no advertisements from a router concludes that the router is not the master or is not participating in VRRP.

Configuration on VyOS 1.5 LTS

The VyOS configuration for VRRP lives under high-availability vrrp. VRRP is configured per-interface; each interface can participate in one or more VRRP groups.

configure
# Configure VRRP group 1 on eth0
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 1000
set high-availability vrrp group 1 preemption delay 0
set high-availability vrrp group 1 version 3

# On the backup router, the configuration is similar but with a lower priority
set high-availability vrrp group 1 priority 100

# Commit and save
commit
save

The minimum configuration is the interface, the virtual address, and the priority. The advertisement interval, preemption, and version are optional and have sensible defaults (1 second, enabled, v2 for backward compatibility, respectively).

Validation

The operational commands to validate VRRP:

# VRRP state on the local router
show vrrp
# Shows the groups, virtual IPs, priorities, and state (Master/Backup/Initialize)

# Detailed state with timers and counters
show vrrp detail
# Includes the master down interval, skew, preemption status, and counters

# Configuration as a single block
show configuration commands | grep vrrp
# Lists the VRRP configuration in `set` format

# Verify the virtual MAC and IP on the interface
ip -d link show eth0
# Look for the "vrrp" link type and the virtual MAC

# Verify the virtual IP is in the routing table as a local address
show ip route 192.168.1.1
# Should show "proto kernel" or a local route

A clean validation: show vrrp shows the expected group(s) in Master state (or Backup state on the backup router); the virtual MAC matches the pattern 00:00:5E:00:01:XX; the virtual IP is reachable from the LAN; ARP on a host shows the virtual IP bound to the virtual MAC.

Production failure modes

Split brain

Two routers both believe they are master and both answer ARP for the virtual IP. The hosts see two MAC addresses for the same IP and may alternate between them, or the switch may flood traffic to both ports. Result: traffic goes to neither router consistently.

Cause: usually a misconfigured advertisement interval that prevents the backup from detecting the master’s failure (e.g., the backup has the advertisement interval set to a value that makes the master down interval too long). Sometimes caused by Layer 2 connectivity issues that prevent VRRP advertisements from being received.

Diagnostic: show vrrp on both routers; both show Master state. tcpdump on the LAN shows two sources of VRRP advertisements for the same group.

Asymmetric traffic

The hosts send traffic to the virtual IP, but the upstream return path uses a different router. This is asymmetric routing; stateful firewalls in the path drop the return packets because they have no state.

Cause: the VRRP master has an asymmetric path to the upstream network (e.g., a different ISP, a different routing protocol metric). The hosts send traffic via the master (R1) but the upstream return traffic comes via R2 (the backup), so the stateful firewall between the routers and the upstream network drops the SYN-ACK.

Diagnostic: traceroute from a host through the virtual IP; the return path uses different routers.

Gratuitous ARP storm on failover

When the backup takes over after a master failure, the new master sends gratuitous ARP to update the LAN hosts’ ARP caches. If the LAN has a large number of hosts (e.g., 5,000) and the gratuitous ARP is flooded, the LAN switch may experience a brief storm during the failover.

Diagnostic: the failover is working (hosts ping the virtual IP) but the LAN switch logs show high traffic volume during the failover.

VRRP version mismatch

R1 uses VRRPv2 and R2 uses VRRPv3. They cannot participate in the same group; each becomes master of its own version. The LAN has two masters and split-brain behaviour.

Diagnostic: show vrrp on both routers; the version field differs.

Rollback

# Show what changed
compare

# Remove VRRP from the interface
delete high-availability vrrp group 1
commit

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

# Verify the rollback
show vrrp
ip -d link show eth0

The rollback removes the VRRP group; the virtual IP is no longer shared; the LAN hosts must use a real IP as their default gateway (or the operator must reconfigure VRRP with rollback N and commit).

Production discipline

Cross-course references

• Part VIII-04 (VIII-VyOS-VLANs / VLAN routing) covers the VLAN-routed interfaces where VRRP most commonly runs.
• Part IX-03 (IX-VyOS-Bridges / bridge vs routing) covers when to layer-3 route vs bridge, including VRRP’s requirement for a shared Layer 2 segment.
• Part XXXIX-04 (XXXIX-VyOS-MultiWAN / policy routing) covers the asymmetric-routing complications that VRRP interacts with in a multi-WAN environment.
• Part XL-02 (XL-VyOS-VRRP / priority and skew) covers the priority field, the skew value, and how the master down interval is computed.
• Part XLIX-04 (XLIX-VyOS-Monitoring / VRRP telemetry) covers the SNMP and Prometheus integration for VRRP state.

Quiz