d9f74aa294
Some checks failed
Commit 3c933b9 concluded "MAC reservations do NOT match". That was wrong, and my
own timed observation (660s, one RA interval) caught it: worker0 and worker2 took
their EXACT reserved addresses, 2001:470:187e:2::23 and ::25, /128. Direct check
confirmed. The MAC-keyed scheme -- one source of truth with IPv4 -- works for the
x86_64 Fedora nodes.
I read the state before a full RA/DHCPv6 cycle completed and generalised from the
early [no hwaddr info] packets. That log line is the query label, not the
reservation-matching path: kea extracts the MAC from a DUID-LLT/LL for host
lookup, which is why NetworkManager's Fedora nodes matched by MAC despite the
label showing no explicit hwaddr. Exactly the assert-before-measuring mistake
this session keeps being about; recording it rather than quietly fixing it.
Still open, for an attended session: the two arm64 nodes (worker1 Asahi, spark
DGX) ran a DHCPv6 transaction but neither bound an address, including after a
manual reapply. Per-node client question, not a scheme failure -- two nodes just
demonstrated the scheme. Not touched unattended.
The pulumi override reason (kubernetes-deployment) still carries the wrong
conclusion and needs the same correction; doing that next.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DMVzWZgiKW2wquf5z8S1yH
60 lines
3.5 KiB
Plaintext
60 lines
3.5 KiB
Plaintext
=== W2: does a production node take a DHCPv6 reservation? ===
|
|
Window of 2026-09-06, operator offline.
|
|
|
|
SHORT ANSWER: YES for the x86_64 Fedora nodes -- MAC reservations work. My first
|
|
write-up of this file said "MAC reservations do NOT match" and that was WRONG:
|
|
I read the result before a full RA/DHCPv6 cycle had completed. The timed
|
|
observation I set running (660s, one MaxRtrAdvInterval) then showed the opposite,
|
|
and a direct check confirmed it. Recording the mistake because committing the
|
|
premature version to git (3c933b9) is exactly the "assert before measuring"
|
|
failure this session has been about.
|
|
|
|
CONFIRMED, direct check 2026-09-06 ~22:47:
|
|
worker0-k8s0 192.168.8.23 -> 2001:470:187e:2::23/128 MATCHES reservation
|
|
worker2-k8s0 192.168.8.25 -> 2001:470:187e:2::25/128 MATCHES reservation
|
|
Both are the EXACT reserved addresses, /128, DHCPv6-assigned. The MAC-keyed
|
|
scheme -- one source of truth with IPv4 -- works for these nodes.
|
|
|
|
WHY IT WORKS DESPITE "[no hwaddr info]" IN THE KEA LOG
|
|
The DHCP6_QUERY_LABEL "[no hwaddr info]" is about whether the client sent an
|
|
explicit hardware-address option; it is NOT the reservation-matching path. For a
|
|
`hw-address` host reservation kea extracts the MAC from the client's DUID when
|
|
the DUID type carries one (DUID-LLT / DUID-LL embed the link-layer address).
|
|
NetworkManager on the Fedora nodes uses such a DUID, so kea matched ::23 and ::25
|
|
by MAC even though the query label showed no explicit hwaddr. The earlier
|
|
DUID-UUID packets I saw were from other clients, and led me to over-generalise.
|
|
|
|
NOT YET WORKING: the two arm64 nodes
|
|
worker1-k8s0 192.168.8.13 (Fedora Asahi Remix, arm64) -> no v6 address
|
|
spark-2935 192.168.8.12 (NVIDIA DGX, arm64) -> no v6 address
|
|
Both ran a DHCPv6 transaction (NetworkManager "dhcp6: beginning transaction")
|
|
but neither completed to a bound address, including after a manual reapply.
|
|
Undetermined -- could be the 45s transaction timeout vs the 600s RA interval, a
|
|
DUID type kea cannot extract a MAC from on these two, or something arm/vendor-OS
|
|
specific. This is a PER-NODE CLIENT question for an attended session, not a
|
|
failure of the reservation scheme (which two nodes just demonstrated). Do not
|
|
hand-configure these unattended.
|
|
|
|
RA HALF (unchanged, and it was always the safe finding)
|
|
RA on bond0.2 carries AdvManagedFlag on, AdvAutonomous off, AdvLinkMTU 1472,
|
|
AdvDefaultLifetime 0. NetworkManager (ipv6.method=auto) follows the managed flag
|
|
and starts DHCPv6. "ipv6.method=auto will do DHCPv6" is evidence, not inference.
|
|
|
|
A SECOND FINDING, unrelated, found live and FIXED in-window
|
|
`service dhcpv6-server` with no listen-interface renders kea6 with
|
|
interfaces: [ "*" ] -- a DHCPv6 server on EVERY VLAN. Observed answering an
|
|
unrelated device on bond0.10 (LoT) within seconds of the first apply. Same
|
|
family as the kea IPv4 cross-VLAN bug (ISC #1117). Fixed by pinning
|
|
listen-interface bond0.2 + a subnet-level interface bond0.2; both routers now
|
|
render interfaces: ["bond0.2"].
|
|
|
|
OPTION (b) mac-sources: VyOS dhcpv6-server global-parameters accepts only
|
|
name-server, so kea mac-sources cannot be passed through config, and editing
|
|
/run/kea/*.conf is banned drift (regenerated every commit). Moot now that the
|
|
default matching works for the Fedora nodes.
|
|
|
|
STILL OPEN FOR THE ATTENDED SESSION
|
|
- the two arm64 nodes: why the DHCPv6 transaction does not complete.
|
|
- whether to keep MAC keys (works for x86 Fedora, unproven for arm) or move to
|
|
DUID keys / a dynamic range + labctl discovery for uniformity.
|