Split brain
VRRP works because each router can hear the other. If they can't, each concludes that the other is dead, and both become master. That's split brain: both routers answer for 10.10.10.1 and 203.0.113.4, PCs and the ISP end up talking to one or the other more or less at random, and connections break in confusing ways.
The lab tries it in two steps:
- r2 stops hearing r1 on the staff VLAN only (a firewall rule drops VRRP there). Nothing happens: r2 still hears r1 on the WAN, and the sync group keeps both of r2's instances together, in BACKUP. The sync group protects against a split on one network.
- r2 stops hearing r1 on both networks. Within seconds, r2 enters MASTER on both instances, and both routers hold 10.10.10.1.
Removing the rule ends it: r2 hears r1's advertisement with priority 150, higher than its own 100, and steps back to BACKUP.
The usual causes in real networks are exactly these: a firewall rule (often a new ruleset without protocol 112), a VLAN missing from a switch trunk, a different virtual_router_id on each router, or the link between the routers' switches failing. Two habits help: monitor that exactly one router holds each shared address, and keep the firewall rule for VRRP in the same file, reviewed with the rest.
root@r2:~# nft insert rule inet filter input iifname staff ip protocol 112 drop
root@r2:~# journalctl -u keepalived --no-pager -o cat --since "-10s"; ip -br -4 addr show dev staff
staff@eth1 UP 10.10.10.3/24
root@r2:~# nft insert rule inet filter input iifname eth0 ip protocol 112 drop
root@r2:~# journalctl -u keepalived --no-pager -o cat --since "-10s"; ip -br -4 addr show dev staff
(WAN) Entering MASTER STATE
VRRP_Group(OFFICE) Syncing instances to MASTER state
(STAFF) Entering MASTER STATE
staff@eth1 UP 10.10.10.3/24 10.10.10.1/24
root@r1:~# ip -br -4 addr show dev staff
staff@eth1 UP 10.10.10.2/24 10.10.10.1/24
root@r2:~# systemctl reload nftables && sleep 5 && journalctl -u keepalived --no-pager -o cat --since "-6s"; ip -br -4 addr show dev staff
(STAFF) Master received advert from 10.10.10.2 with higher priority 150, ours 100
(STAFF) Entering BACKUP STATE
VRRP_Group(OFFICE) Syncing instances to BACKUP state
(WAN) Entering BACKUP STATE
staff@eth1 UP 10.10.10.3/24 - Lines 1–4: VRRP blocked on the staff VLAN only: r2 stays BACKUP, held by the sync group.
- Lines 6–12: Blocked on the WAN too: r2 becomes master on both…
- Lines 14–15: …while r1 still holds 10.10.10.1. Two routers, one address.
- Lines 17–22: The rule is gone: r2 hears priority 150 and steps back.
Check your understanding
Both routers hold 10.10.10.1. What do you check first?
- Whether VRRP advertisements (protocol 112) reach each router: firewall rules, the VLAN on the switch, and matching virtual router IDs.
- The routers' priorities.
- conntrackd.
- The health check.