VLAN 2 IPv6 applied to production: RA proven, MAC reservations do NOT match
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
2026-09-06 22:36:47 +01:00
|
|
|
=== W2: does a production node take a DHCPv6 reservation? ===
|
|
|
|
|
Window of 2026-09-06, operator offline.
|
|
|
|
|
|
|
|
|
|
SHORT ANSWER: the RA half works; the RESERVATION half does not, and the reason
|
|
|
|
|
is structural rather than a misconfiguration.
|
|
|
|
|
|
|
|
|
|
WHAT WORKS
|
|
|
|
|
- RA is emitted on bond0.2 with AdvManagedFlag on, AdvAutonomous off,
|
|
|
|
|
AdvLinkMTU 1472, AdvDefaultLifetime 0 (deliberately not a default router).
|
|
|
|
|
- NetworkManager on worker0 SAW it and acted:
|
|
|
|
|
dhcp6 (eno1): activation: beginning transaction (timeout in 45 seconds)
|
|
|
|
|
So "ipv6.method=auto follows the managed flag" is now EVIDENCE, not
|
|
|
|
|
inference. That was the open question this window set out to close.
|
|
|
|
|
- kea-dhcp6 runs on both routers and receives SOLICITs on bond0.2.
|
|
|
|
|
|
|
|
|
|
WHAT DOES NOT WORK, AND WHY
|
|
|
|
|
Every DHCPv6 packet kea logs is annotated [no hwaddr info]:
|
|
|
|
|
|
|
|
|
|
duid=[00:04:69:d9:30:64:c3:4e:...] [no hwaddr info] <- DUID-UUID (type 4)
|
|
|
|
|
duid=[00:04:25:11:e0:0a:7b:c4:...] [no hwaddr info] <- DUID-UUID
|
|
|
|
|
duid=[00:01:00:01:31:78:0a:ae:...] [no hwaddr info] <- DUID-LLT (type 1)
|
|
|
|
|
|
|
|
|
|
DHCPv6 identifies a client by DUID, not by MAC. kea can sometimes DERIVE a MAC
|
|
|
|
|
(its mac-sources machinery), but here it derives nothing -- including from a
|
|
|
|
|
DUID-LLT, which does embed one. So `hw-address` reservations cannot match, and
|
|
|
|
|
a node that solicits gets no reserved address.
|
|
|
|
|
|
|
|
|
|
VyOS accepting `static-mapping <name> mac` is therefore necessary but NOT
|
|
|
|
|
sufficient: it renders valid kea config ("hw-address": "78:55:36:08:28:fb",
|
|
|
|
|
confirmed in /run/kea/kea-dhcp6.conf) that simply never matches these clients.
|
|
|
|
|
The plan's assumption -- "reservations keyed on MAC, one source of truth with
|
|
|
|
|
IPv4" -- does not survive contact with DHCPv6.
|
|
|
|
|
|
|
|
|
|
OPTIONS, none free, for an attended session:
|
|
|
|
|
a) Key reservations on DUID (VyOS static-mapping supports `duid`). Works, but a
|
|
|
|
|
DUID is client-generated: it is a SECOND source of truth, it must be
|
|
|
|
|
harvested per node, and it changes if a node is rebuilt -- which is exactly
|
|
|
|
|
the "out of the box for new nodes" property we were trying to preserve.
|
|
|
|
|
b) Set kea `mac-sources` explicitly and see whether any method recovers a MAC
|
|
|
|
|
from these clients. Cheap to try; may simply not work for DUID-UUID.
|
|
|
|
|
c) Drop reservations: hand out a dynamic range and have labctl DISCOVER the
|
|
|
|
|
node's address rather than predict it. The k3s preflight (914135c) already
|
|
|
|
|
refuses to write a node-ip the node does not hold, so discovery is safe --
|
|
|
|
|
but the address is then not knowable before the node boots.
|
|
|
|
|
d) SLAAC with no-autonomous cleared, and accept EUI-64 addresses. Stable per
|
|
|
|
|
NIC and needs no server state at all, but the address is not ours to choose.
|
|
|
|
|
|
|
|
|
|
A SECOND FINDING, unrelated and worse if unnoticed
|
|
|
|
|
`service dhcpv6-server` with no listen-interface renders kea6 with
|
|
|
|
|
interfaces: [ "*" ] -- a DHCPv6 server on EVERY VLAN. Observed live: kea began
|
|
|
|
|
answering SOLICIT/REQUEST from an unrelated device on bond0.10 (LoT) within
|
|
|
|
|
seconds of the first apply. Same family as the kea IPv4 cross-VLAN bug (ISC
|
|
|
|
|
#1117) this estate already fought. Fixed by pinning
|
|
|
|
|
`set service dhcpv6-server listen-interface bond0.2` plus a subnet-level
|
|
|
|
|
`interface bond0.2`; both routers now render interfaces: ["bond0.2"].
|
|
|
|
|
|
2026-09-06 22:37:23 +01:00
|
|
|
OPTION (b) RULED OUT IN-WINDOW: VyOS's dhcpv6-server global-parameters accepts
|
|
|
|
|
only `name-server` -- there is no knob to pass kea `mac-sources`, and editing
|
|
|
|
|
/run/kea/kea-dhcp6.conf directly is the hand-sed drift this estate already
|
|
|
|
|
banned (it is regenerated on every commit anyway). Worth knowing for the
|
|
|
|
|
attended decision: worker0's link-local IS EUI-64 (fe80::7a55:36ff:fe08:28fb
|
|
|
|
|
embeds 78:55:36:08:28:fb) so a mac-source of ipv6-link-local could match it --
|
|
|
|
|
but at least one client on the VLAN uses a privacy-style link-local
|
|
|
|
|
(fe80::b2c3:ee96:e630:519d), so even upstream support would not cover everyone.
|
|
|
|
|
That pushes toward option (a) DUID keys or (c) dynamic range + discovery.
|