VRRP troubleshooting — split-brain, both-master, asymmetric traffic, missed elections

VRRP failures fall into a small number of categories: split-brain (both routers as master), missed election (the backup never takes over), asymmetric traffic (forward and reverse paths differ), and protocol-level failures (advertisements not received, version mismatch, multicast filtered). Diagnosing these requires a systematic flow from symptom to evidence to root cause — and the diagnostic tool is almost always a packet capture combined with show vrrp and show vrrp detail.

This lesson is the diagnostic reference for VRRP. It covers the four failure modes, the diagnostic flow for each, and the operational commands that reveal the state.

The diagnostic flow

The systematic flow for any VRRP failure:

1. Symptom — what the operator sees (hosts losing connectivity, slow failover, asymmetric traffic).
2. Show vrrp on both routers — what each router believes.
3. Capture on the LAN — what is on the wire.
4. Cross-reference — does the configuration match what the routers believe? Does what the routers believe match what is on the wire?
5. Root cause — the difference between the configuration and the on-the-wire state.

The tool that makes VRRP diagnostics tractable is the packet capture. The configuration can lie (a typo; a commit that didn’t apply; a script that pushed a broken config). The routers’ internal state can lie (a bug; a daemon restart; a race condition). The packet capture cannot lie — it shows what is actually on the wire.

# The minimal VRRP diagnostic set

# 1. State on the routers
vyos@R1:~$ show vrrp
# Router 1's view

vyos@R2:~$ show vrrp
# Router 2's view

# 2. Capture on the LAN (run on a monitor port or directly on a VRRP router)
$ tcpdump -ni eth0 'ip proto 112' -c 10 -vv
# What is actually on the wire

# 3. Verify the ARP cache of a host
host$ arp -n 192.168.1.1
# What the host thinks the virtual MAC is

# 4. Cross-reference
# Does R1's state match what the capture shows?
# Does R2's state match what the capture shows?
# Does the host's ARP cache match the virtual MAC?

Failure mode 1 — split-brain (both routers as master)

Symptom: hosts have intermittent connectivity; ARP cache shows two different MACs for the virtual IP.

Diagnostic:

# Check both routers' states
vyos@R1:~$ show vrrp
# State: Master

vyos@R2:~$ show vrrp
# State: Master
# Both believe they are master

# Confirm with a capture
$ tcpdump -ni eth0 'ip proto 112' -c 10 -vv
# Captures show advertisements from BOTH R1 and R2 with different source IPs

Common causes:

1. Layer 2 partition. The routers cannot see each other’s advertisements (multicast filtering, VLAN mismatch, switch misconfiguration). Each believes the other is down and becomes master.
2. Version mismatch. R1 sends VRRPv2, R2 sends VRRPv3. They cannot participate in the same group.
3. Authentication mismatch (VRRPv2). R1 and R2 have different authentication strings. The receivers drop advertisements with the wrong auth.
4. Group ID mismatch. R1 is in group 1, R2 is in group 2. They are masters of different groups (the hosts may end up using whichever group has a higher-traffic response).

flowchart LR
  R1["R1<br/>VRRPv3 group 1<br/>state: Master"]
  R2["R2<br/>VRRPv2 group 1<br/>state: Master"]
  SW["LAN switch"]
  H1["Host"]
  H2["Host"]
  R1 -- "v3 adverts" --> SW
  R2 -- "v2 adverts" --> SW
  SW --> H1
  SW --> H2

Diagnostic flow for split brain:

1. Show vrrp on both. Both show Master? Continue.
2. tcpdump on the LAN. Two sources of advertisements? Confirm split brain.
3. Check version field. Different versions → version mismatch.
4. Check authentication. R1’s auth string ≠ R2’s → auth mismatch.
5. Check switch forwarding. R1 cannot see R2’s advertisements → Layer 2 issue.

Remediation depends on the cause:

• Version mismatch: align set high-availability vrrp group 1 version 3 on both.
• Auth mismatch: align the auth string, or upgrade to VRRPv3 (no protocol-level auth).
• Layer 2: fix the multicast forwarding, VLAN, or switch configuration.

Failure mode 2 — missed election (backup never takes over)

Symptom: master fails; backup does not take over; hosts lose connectivity.

Diagnostic:

# On the backup router
vyos@R2:~$ show vrrp
# State: Backup (still!)
# The backup should have transitioned to Master after 3+ seconds

# Why?
vyos@R2:~$ show vrrp detail
# Look at the master_down_interval and the time since the last advertisement
# If the time-since-last-advertisement is greater than the master-down-interval,
# the backup should have taken over. If it has not, something is wrong.

Common causes:

1. Multicast filtered. The backup does not receive the master’s advertisements (even when the master is alive). The backup keeps its master-down-interval counter reset only when it does receive an advertisement; if it never receives any, the counter should expire and the backup should take over. But if the multicast is filtered, the backup might believe the master is up because it received an advertisement a long time ago and the router has not refreshed its counter.
2. Virtual MAC conflict. A physical device has the same MAC address as the virtual MAC (rare; should not happen because the OUI 00:00:5E is reserved).
3. Configuration error. R2 is configured but not for the same group ID or virtual IP. R2 is backup but for a different VRRP group.
4. Software bug. A bug in the VRRP implementation prevents the failover (rare; check show version and the changelog).

# Diagnostic for missed election

# 1. Confirm both routers are alive
vyos@R1:~$ show vrrp
# State: Master (and R1 is reachable on the LAN)

vyos@R2:~$ show vrrp
# State: Backup (still)

# 2. Check the master-down-interval
vyos@R2:~$ show vrrp detail
# Master down interval: 3050 ms
# Time since last advertisement: 30500 ms
# The counter is past the threshold but the state has not flipped — bug?

# 3. Check the virtual MAC on the LAN
host$ arp -n 192.168.1.1
# 192.168.1.1 -> 00:00:5E:00:01:01 (R1's MAC, as expected)

# 4. Verify the router's VRRP daemon
vyos@R2:~$ ps aux | grep vrrp
# The daemon is running

Remediation depends on the cause:

1. Multicast filtering: enable multicast on the switch; configure IGMP snooping properly.
2. Virtual MAC conflict: identify the device with the duplicate MAC (rare; usually a misconfigured VM or container).
3. Configuration error: verify both routers have the same group ID and virtual IP.
4. Software bug: upgrade to a fixed version or restart the VRRP daemon (after documenting the cause).

Failure mode 3 — asymmetric traffic

Symptom: hosts send traffic to the virtual IP; the traffic is dropped by an upstream stateful firewall; hosts see half-open TCP connections.

Diagnostic:

# Confirm the master state
vyos@R1:~$ show vrrp
# State: Master

# Confirm the routing
vyos@R1:~$ show ip route 0.0.0.0/0
# Default route via ISP-A (R1's uplink)

vyos@R2:~$ show ip route 0.0.0.0/0
# Default route via ISP-B (R2's uplink)

# Confirm the upstream firewall state
# The ISP-A firewall logs show SYN-ACK drops because there is no matching SYN

Common causes:

1. Each router has a different upstream. R1’s default route is via ISP-A; R2’s is via ISP-B. After a failover, the traffic flows via a different upstream; the upstream firewall has no state for the new connections.
2. BGP session divergence. R1 and R2 have different BGP peers and learn different routes. The default route for each is different.
3. Asymmetric state. The return traffic uses a different router from the forward traffic; the upstream stateful firewall drops the return packets because it has no state.

flowchart LR
  H["Host"]
  V["Virtual IP<br/>192.168.1.1"]
  M["R1 (master)"]
  B["R2 (backup)<br/>also has default route"]
  FW1["ISP-A firewall<br/>(no state for new conn)"]
  FW2["ISP-B firewall<br/>(has state for new conn)"]
  INT["Destination"]
  H -- "via R1 / ISP-A" --> V
  V --> M
  M -- "default route via ISP-A" --> FW1
  FW1 -. "no state" .-> INT
  INT -- "return via ISP-B" --> FW2
  FW2 --> B
  B -. "host unreachable" .-> H

Remediation depends on the cause:

1. Different upstream per router: align the routing (e.g., both routers use the same ISP), or accept the asymmetry (and configure the upstream firewalls to allow asymmetric routing, which is rare).
2. BGP divergence: align the BGP configuration; both routers should learn the same routes and have the same preferences.
3. Asymmetric state: disable preemption in VRRP (so the master does not flip when the original master recovers); the asymmetry is consistent with the master.

Failure mode 4 — protocol-level failures

Symptoms: VRRP state is Initialize, or no advertisements are seen on the LAN.

Diagnostic:

# Check the interface state
vyos@R1:~$ show interfaces eth0
# state: up

# Check the VRRP configuration
vyos@R1:~$ show configuration commands | grep vrrp

# Check the kernel logs
vyos@R1:~$ dmesg | grep -i vrrp

# Check the FRR logs
vyos@R1:~$ journalctl -u frr | grep -i vrrp

# Capture on the LAN to see what is on the wire
$ tcpdump -ni eth0 'ip proto 112' -c 4 -vv
# Nothing? Routing is fine but VRRP is not running.

Common causes:

1. Interface not up. show interfaces eth0 shows state: down. The router does not run VRRP on a down interface.
2. VRRP not configured. show configuration commands | grep vrrp returns nothing. The configuration is missing.
3. Multicast destination unreachable. The router sends advertisements but the LAN does not forward them. Switch misconfiguration.
4. Daemon not running. ps aux | grep vrrp shows nothing. The VRRP daemon is not running.

Remediation depends on the cause. Most are configuration-level fixes.

Validation and operational commands

# Quick state check on a single router
show vrrp

# Detailed state with timers, counters, last state change
show vrrp detail

# Tracking status
show vrrp track

# Configuration in a list form
show configuration commands | grep vrrp

# Capture on the LAN (use a span port on the switch, or run on a host that is on the LAN)
tcpdump -ni eth0 'ip proto 112' -vv

# Inspect the virtual MAC on a host
arp -n <virtual-ip>

# Inspect the kernel's VRRP module (Linux-specific)
lsmod | grep vrrp
cat /proc/net/vrrp

A typical diagnostic workflow:

# Step 1: Identify the symptom
# Hosts cannot reach the virtual IP, or intermittent connectivity.

# Step 2: Check both routers
R1: show vrrp
R2: show vrrp

# Step 3: Capture on the LAN
host$ tcpdump -ni eth0 'ip proto 112' -c 10 -vv

# Step 4: Cross-reference
# Are the routers' states consistent? Is the capture consistent with the states?

# Step 5: Root cause
# Most common: multicast filtering, version mismatch, or asymmetric routing.

Production failure modes

Firewall blocks VRRP multicast

The stateful firewall on the LAN filters multicast (or specifically filters protocol 112 destination 224.0.0.18). The backup never receives the master’s advertisements. With nothing to keep the master-down-interval counter going, the backup eventually takes over (assuming it considers itself alone in the group), but the failover may be slow or unreliable.

Fix: configure the firewall to allow VRRP multicast. Add a rule: protocol 112, destination 224.0.0.18, accept.

Switch MAC aging too slow

The master fails; the backup takes over with the virtual MAC; the LAN switch still has the old MAC entry pointing at the failed master’s port. The switch continues to forward frames with the virtual MAC to the failed port. The hosts’ traffic is dropped.

The fix: tune the switch’s MAC aging timer. The default is 5 minutes (300 seconds). For VRRP failover of 3 seconds, the aging timer should be 30 seconds or less.

Stale gratuitous ARP

The backup takes over and sends a gratuitous ARP to update the hosts’ ARP caches. Some hosts ignore gratuitous ARP (a security feature); the hosts keep the stale ARP entry pointing at the failed master. The hosts continue to send to the failed master’s MAC.

The fix: configure the hosts to honour gratuitous ARP, or wait for the ARP cache to time out (typically 5-20 minutes depending on the OS), or pre-emptively update the ARP cache on the routers via a script.

Routing protocol convergence during VRRP failover

The master fails; the backup takes over via VRRP. The routing protocols (BGP, OSPF) have not yet converged. The new master has stale routes; traffic to some destinations is black-holed until routing converges.

The fix: tune the routing protocol timers to converge quickly (BFD, sub-second OSPF hello), or use routing-protocol failover mechanisms (BGP graceful restart, OSPF graceful restart) to minimise the convergence window.

Rollback

# Capture the diagnostic output. Operational mode has no `| save`
# pipe; it is a shell, so redirect the output to a file.
show vrrp detail | no-more > /config/vrrp-diag-TICKET.txt

# Capture the running configuration. `save` is a configuration-mode
# command that takes a path, not an operational-mode pipe.
configure
save /config/pre-change-vrrp-TICKET.conf

# Roll back to the previous configuration
load /config/pre-change-vrrp-TICKET.conf
compare
commit
save

# Or fall back to the commit archive. `show system commit` in
# operational mode lists the revisions; /config/archive/ holds the
# matching files, and `load` fills the candidate from one of them so
# that `compare` still gets read before anything takes effect.
load /config/archive/config.boot-20260815_2148
compare
commit
save

The rollback restores the previous VRRP configuration; the state returns to the last known-good point.

Production discipline

Cross-course references

• Part LII-04 (LII-VyOS-Troubleshoot / subsystem by subsystem) covers the wider diagnostic methodology that VRRP diagnostics fit into.
• Part XLIX-04 (XLIX-VyOS-Monitoring / VRRP telemetry) covers the monitoring and alerting that catches VRRP failures before users notice.
• Part XXXIX-06 (XXXIX-VyOS-MultiWAN / troubleshoot) covers the asymmetric routing diagnostics that interact with VRRP.
• Part XXXVII-06 (XXXVII-VyOS-Firewall / troubleshoot) covers the stateful firewall diagnostics that interact with VRRP asymmetric traffic.

Quiz