michal/lab
1
0
Fork 0
Code Issues Pull Requests 3 Actions Packages Projects Releases Wiki Activity

fix(migration): require a working WAN, not every WAN

Browse Source 
This reverted a cutover that had actually succeeded.

The evidence, from the revert tearing it down:

  dhclient: DHCPRELEASE of 87.192.101.48 on bond0.53 to 185.232.119.244
  vtysh:    "no ip route 0.0.0.0/0 87.192.96.1 bond0.53 tag 210 1"
  netlinkd: RTM_NEWLINK -> bond0.53, mac=f0:9f:c2:12:9b:4f

bond0.53 came up with the cloned MAC and was handed 87.192.101.48 -- the exact
public address the USG holds -- with a default route via the real ISP gateway.
kea was serving live LAN clients at the same moment (10.0.0.12, 10.0.0.13,
192.168.8.28). The gateway was working.

The only failure was pppoe0: ppp@pppoe0.service exited 5/NOTINSTALLED. That is
the Vodafone FAILOVER line, and the health check listed "pppoe0 has an address"
as mandatory, so a working gateway was torn down because its backup WAN was
down. The check encoded "every WAN must work" when the requirement is "the box
must reach the internet".

Now: default route, reachability and DNS are mandatory; each WAN interface is
reported individually but fatal on neither. A failover line being down is worth
seeing, not worth reverting for.

This also incidentally settles the last genuine unknown in the migration, which
could not be tested any other way: the ISP does hand the same lease to the
cloned MAC. That was the one thing I had said was unknowable until the USG let
go of it.

Note the earlier polling fix (54b21fa) addressed a real weakness but not this
failure -- no amount of waiting would have satisfied a check that required a
line which was never going to come up.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DMVzWZgiKW2wquf5z8S1yH
This commit is contained in:
Michal
2026-08-18 01:37:14 +01:00
parent 54b21fa9ff
commit ce6911c196
1 changed files with 19 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files

21
migration/vyos-unifi-switch
View File

@@ -171,13 +171,30 @@ health_checks() {
# no PPPoE stanza is a lab/partial delta, and failing it on a missing
# pppoe0 would make the script untestable anywhere but the live cutover.
# Announced loudly, because a quietly skipped check is worse than no check.
if grep -q "^set interfaces pppoe" "$DELTA"; then
if grep -qE "^set interfaces (pppoe|bonding bond0 vif 5)" "$DELTA"; then
# What matters is that SOME WAN works, not that every WAN works.
#
# This reverted a cutover that had genuinely succeeded. The 10 gig line came
# up on bond0.53 and the cloned MAC was handed the same public address the
# USG had (87.192.101.48); kea was serving real LAN clients at the same
# moment. The only failure was pppoe0 -- the Vodafone FAILOVER line -- and
# requiring it undid a working gateway.
#
# Written as [ -n "$(...)" ] rather than `... | grep -q` for the pipefail
# reason above: a pipeline ending in grep -q cannot be trusted here.
_chk "pppoe0 has an address" '[ -n "$(ip -4 -br addr show pppoe0 2>/dev/null | awk "{print \$3}")" ]'
_chk "a default route exists" '[ -n "$(ip -4 route show default)" ]'
_chk "internet reachable" "ping -c2 -W3 8.8.8.8"
_chk "DNS resolves through us" "getent hosts vyos.net"
# Informational only: report each WAN, fail on neither. A failover line
# being down is worth seeing, not worth reverting for.
for _w in pppoe0 bond0.53; do
if [ -n "$(ip -4 -br addr show "$_w" 2>/dev/null | awk '{print $3}')" ]; then
say " ok WAN $_w has an address (informational)"
else
say " note WAN $_w has no address (informational, not fatal)"
fi
done
else
warn "this delta configures no WAN -- skipping all WAN health checks."
warn "That is expected in the lab and WRONG for the real cutover."