Health checks

VRRP only notices when the other router stops sending advertisements. A router can be perfectly healthy as far as VRRP is concerned and still useless: its link to the ISP is up, but the ISP has stopped routing to it. Every office PC would keep sending traffic to it.

vrrp_script isp_reachable checks what actually matters: every two seconds, keepalived runs ping -c 1 -W 1 203.0.113.1. Two failures in a row (fall 2) put the instance into the FAULT state, which gives up the addresses; two successes (rise 2) bring it back.

In the lab, the ISP stops routing to r1's address, while every link stays up. Within a few seconds, r1 logs the script failing and enters FAULT on both instances (the sync group again), and r2 takes over 10.10.10.1. When the ISP fixes its routing, the script succeeds again and r1, with its higher priority, takes the addresses back.

Choose the check carefully: test something beyond your own link (the ISP's gateway, or better, two addresses further away) but not something that fails on its own, or the routers will swap back and forth. interval, fall and rise decide how fast and how jumpy the check is. The script runs as root here (script_user root, with enable_script_security); a dedicated user is better on a production router.

root@isp:~# ip route add blackhole 203.0.113.2/32

root@r1:~# journalctl -u keepalived --no-pager -o cat | grep -E "isp_reachable|FAULT|BACKUP" | tail -4; ip -br -4 addr show dev staff
VRRP_Script(isp_reachable) failed (exited with status 1)
(STAFF) Entering FAULT STATE
VRRP_Group(OFFICE) Syncing instances to FAULT state
(WAN) Entering FAULT STATE
staff@eth1       UP             10.10.10.2/24 

root@r2:~# ip -br -4 addr show dev staff
staff@eth1       UP             10.10.10.3/24 10.10.10.1/24 

root@isp:~# ip route del blackhole 203.0.113.2/32

root@r1:~# journalctl -u keepalived --no-pager -o cat | grep -E "isp_reachable|MASTER" | tail -3
(WAN) Entering MASTER STATE
VRRP_Group(OFFICE) Syncing instances to MASTER state
(STAFF) Entering MASTER STATE