Live inspection of the PVE cluster on 2026-07-19 found two defects.
1. No IPv6 address on any external interface, on all three nodes.
/etc/frr/frr.conf enables "ipv6 forwarding" for the OSPFv3 Thunderbolt
mesh that carries corosync, which sets net.ipv6.conf.all.forwarding=1.
The kernel default accept_ra=1 means "accept RAs only while NOT
forwarding", so the nodes silently discarded the Router Advertisements
the gateway sends on VLAN 40. Every external interface was left with
only a link-local address; the sole non-link-local IPv6 anywhere on the
nodes was the corosync mesh /128, which is static in frr.conf and never
depended on RAs.
Verified the gateway is not at fault: RAs arrive on vmbr1.40 from
fe80::265a:4cff:fea6:fd3c every ~10-15s, carrying both the Telekom GUA
prefix and a ULA, and non-forwarding hosts on the LAN autoconfigure
normally. The PVE nodes are the only hosts running FRR.
Fixed with a sysctl drop-in setting accept_ra=2, the value a forwarding
host needs in order to still autoconfigure its own uplink.
2. saturn's vmbr0 is at MTU 1500 while its own uplink enp2s0f0np0 and both
peer nodes' bridges are at 9000. Since the three bridges share one L2
domain, large frames between saturn's guests and the other nodes' guests
blackhole rather than fragmenting. saturn's vmbr0 stanza is simply
missing the mtu line that jupiter and neptune both have.
The two fixes are separated by risk. The sysctl change is non-disruptive
and applies on every run. The MTU change is staged as a pending PVE network
change and applied only when pve_node_network_apply_pending is set, because
applying it reloads networking on the node and briefly interrupts the Talos
k8s VM and its Ceph OSD. The play uses serial: 1 so nodes converge one at a
time.
The MTU task reconstructs the full bridge definition from a pvesh GET before
issuing the PUT. A PUT on /nodes/<node>/network/<iface> replaces rather than
merges, so passing only --mtu would silently drop bridge_ports,
bridge_vlan_aware and bridge_vids, detaching the uplink and flattening every
SDN VNet.
Not applied yet — no run has been made against the cluster.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
claude-botandClaude Opus 4.8