3c933b96e0
Some checks failed
The unattended window's W1/W2. Both routers now carry the VLAN 2 IPv6 config (addresses ::1/::2, RA with managed-flag + no-autonomous-flag + link-mtu 1472, DHCPv6 reservations for all five nodes), applied via migration/vlan2-v6-apply with a vlan2-v6-watchdog armed on both routers throughout. IPv4 untouched: internet up, 6 MASTER / 6 BACKUP, 5/5 nodes Ready, watchdogs quiet. default-lifetime 0 on purpose -- addressing without egress. Turning on v6 egress moves image pulls onto a tunnel of unmeasured throughput, and the person who would notice is away. One line to flip when attended. THE WINDOW'S QUESTION IS ANSWERED, HALF YES, HALF NO: YES: NetworkManager follows the managed flag. worker0 logged dhcp6 (eno1): activation: beginning transaction minutes after the RA appeared. "ipv6.method=auto will do DHCPv6" is now evidence, not inference. NO: the reservations never match. Every packet kea logs is [no hwaddr info] -- the clients identify with DUID-UUID (and one DUID-LLT), kea derives no MAC from any of them, so hw-address reservations cannot match and no node got its reserved address. VyOS accepting `static-mapping mac` renders valid kea config that simply never matches these clients. The "one source of truth with IPv4" addressing scheme does not survive contact with DHCPv6; options (DUID keys, kea mac-sources, dynamic range + discovery, or SLAAC) are written up in migration/window-evidence/2026-09-06-dhcpv6.txt for an attended decision. FOUND LIVE AND FIXED IN THE SAME WINDOW: `service dhcpv6-server` with no listen-interface renders kea6 with interfaces: ["*"] -- a DHCPv6 server on EVERY VLAN. kea was answering an unrelated device on bond0.10 within seconds of the first apply. Same family as the kea IPv4 cross-VLAN bug (ISC #1117). Now pinned to bond0.2 on both routers. Also in this commit, three self-inflicted script bugs found by their own failures: log() wrote progress lines into the captured config stream (VyOS rejected each as "Invalid command", leaving the two routers correct but NOT identical); "Invalid command" was missing from the failure patterns so that run reported success; and the MAC lookup matched its own freshly-created v6 reservations on the second run, returning doubled MACs. All three fixed, both routers converged and diffed identical. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01DMVzWZgiKW2wquf5z8S1yH
36 lines
1.1 KiB
Plaintext
36 lines
1.1 KiB
Plaintext
=== W0 baseline 2026-09-06T22:25:20+01:00 ===
|
||
--- 10.0.1.252 ---
|
||
vyos001
|
||
holds VIP : YES
|
||
WAN : bond0.53=87.192.101.48 pppoe0=90.251.152.236
|
||
route : default via 87.192.96.1 dev bond0.53 proto failover metric 1
|
||
internet: UP
|
||
ipv6 : UP
|
||
vrrp : 6 MASTER
|
||
vlan2 v6 present already? : 0
|
||
--- 10.0.1.253 ---
|
||
vyos002
|
||
holds VIP : no
|
||
WAN :
|
||
route :
|
||
internet: DOWN
|
||
ipv6 : DOWN
|
||
vrrp : 6 BACKUP
|
||
vlan2 v6 present already? : 0
|
||
--- cluster ---
|
||
aitopatom-3a1c Ready
|
||
spark-2935 Ready
|
||
worker0-k8s0.ad.itaz.eu Ready
|
||
worker1-k8s0.ad.itaz.eu Ready
|
||
worker2-k8s0.ad.itaz.eu Ready
|
||
--- known-good save ---
|
||
[0;36m[known-good][0m pinned 1118 lines as known-good on vyos001
|
||
[0;36m[known-good][0m restore with: /config/vyos-known-good restore
|
||
[0;36m[known-good][0m pinned 1119 lines as known-good on vyos002
|
||
[0;36m[known-good][0m restore with: /config/vyos-known-good restore
|
||
--- vrrp-wan-install --check ---
|
||
10.0.1.252: vrrp-wan in sync
|
||
10.0.1.253: vrrp-wan in sync
|
||
vyos001: in sync (533 nodes)
|
||
vyos002: in sync (534 nodes)
|