From ce6911c196d0843c552f5b4d029c01b78fe6e053 Mon Sep 17 00:00:00 2001 From: Michal Date: Tue, 18 Aug 2026 01:37:14 +0100 Subject: [PATCH] fix(migration): require a working WAN, not every WAN 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) Claude-Session: https://claude.ai/code/session_01DMVzWZgiKW2wquf5z8S1yH --- migration/vyos-unifi-switch | 21 +++++++++++++++++++-- 1 file changed, 19 insertions(+), 2 deletions(-) diff --git a/migration/vyos-unifi-switch b/migration/vyos-unifi-switch index 945ceed..df18ee6 100755 --- a/migration/vyos-unifi-switch +++ b/migration/vyos-unifi-switch @@ -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."