25 lines
1.2 KiB
Plaintext
25 lines
1.2 KiB
Plaintext
|
#!/bin/sh
|
||
|
|
# VRRP health check: may THIS router hold the floating IPs?
|
||
|
|
#
|
||
|
|
# It may only if it can actually carry the WAN. Without this, VRRP decides
|
||
|
|
# mastership purely on whether the peer is still advertising -- so a router with
|
||
|
|
# no WAN at all happily takes the VIPs and blackholes the entire LAN's internet
|
||
|
|
# while looking perfectly healthy. That is not hypothetical: it is the outage of
|
||
|
|
# 2026-09-02, reproduced in labsim.
|
||
|
|
#
|
||
|
|
# The test is "do I have an ADDRESS on a WAN interface", deliberately NOT "can I
|
||
|
|
# reach the internet" and NOT "do I have a default route". During a real ISP
|
||
|
|
# outage the default route disappears on BOTH routers; a check keyed on that
|
||
|
|
# would put both into FAULT, nobody would hold the VIPs, and the LAN would lose
|
||
|
|
# inter-VLAN routing too -- turning an internet outage into a total one. An
|
||
|
|
# address on a WAN interface distinguishes "this box structurally cannot route"
|
||
|
|
# (the failure we must prevent) from "the internet happens to be down right now"
|
||
|
|
# (which the router can do nothing about, and during which it should keep
|
||
|
|
# serving the LAN).
|
||
|
|
#
|
||
|
|
# exit 0 = eligible for MASTER, non-zero = release and let the peer have it.
|
||
|
|
for ifc in bond0.53 pppoe0; do
|
||
|
|
ip -4 addr show dev "$ifc" 2>/dev/null | grep -q 'inet ' && exit 0
|
||
|
|
done
|
||
|
|
exit 1
|