=====================================================================
D-101 MTU / geneve-over-v6 BUDGET -- first recorded verdict
Date: 2026-07-27   Branch: dc-dc-stage5-grounding-audit
Context: Stage-5 grounding audit, ruling R3.
=====================================================================

`scripts/dc-dc-mtu-geneve-budget.sh` has existed since it was written but had
NEVER been run to a recorded verdict (audit finding L2-5). D-101 states "The
measured underlay MTU is a Phase-0 gate -- do not assume jumbo." This capture is
that measurement.

---------------------------------------------------------------------
1. MEASURED UNDERLAY -- vcloud host bridges
---------------------------------------------------------------------
  $ virsh net-list --name | while read n; do br=$(virsh net-info "$n" | awk '/Bridge:/{print $2}');
      ip -o link show "$br"; done

  mesh-vr1-dc0-office1         virbr7     mtu=9000
  mesh-vr1-dc0-vr1-dc1         virbr5     mtu=9000     <- THE INTER-DC PATH
  mesh-vr1-dc1-office1         virbr3     mtu=9000
  office1-local                virbr2     mtu=9000
  office1-wan                  virbr11    mtu=1500     <- simulated ISP, CORRECT at 1500
  vr1-dc0-uplink               virbr4     mtu=1500     <- simulated ISP, CORRECT at 1500
  vr1-dc1-uplink               virbr1     mtu=1500     <- simulated ISP, CORRECT at 1500
  wan                          virbr0     mtu=1500     <- simulated ISP, CORRECT at 1500

IMPORTANT: the four 1500 legs are the D-125 simulated-ISP uplinks. They MODEL
THE INTERNET and must STAY 1500 -- D-125's egress isolation gate is defined
against them. They are not part of the jumbo underlay and are not a defect.

---------------------------------------------------------------------
2. MEASURED UNDERLAY -- rack side (both DCs)
---------------------------------------------------------------------
  Six plane bridges per rack (virbr1..virbr6): mtu=9000   [audit finding L2-5]
  Rack transit leg enp1s0:                     mtu=1500   <- LAGGING SEGMENT 1

---------------------------------------------------------------------
3. MEASURED -- MAAS VLAN records
---------------------------------------------------------------------
  All 17 VLANs report mtu 1500, including all ten named plane fabrics and both
  metal-admin/boot fabrics.                                <- LAGGING SEGMENT 2

  This is the one that bites silently: MAAS renders the VLAN MTU into node
  netplan, so a jumbo BRIDGE under a 1500 MAAS record still yields 1500 node
  interfaces. Jumbo bridges alone do not deliver a jumbo underlay.

---------------------------------------------------------------------
4. BUDGET SCRIPT VERDICTS -- both branches, run this session
---------------------------------------------------------------------
  $ bash scripts/dc-dc-mtu-geneve-budget.sh --underlay-mtu 1500
    geneve-over-v6 overhead (D-101: 40 IPv6 + 8 UDP + 8 Geneve base): 56 bytes
    Underlay is NOT jumbo (< 9000).
    Per D-101: tenant_mtu = underlay_mtu - 56 = 1500 - 56 = 1444
    Recorded decision: underlay_mtu = 1500; tenant MTU = 1444 (v6-geneve),
    MUST be set consistently across ovn geneve, tenant-network MTU, and amphora
    VERDICT: PASS
    MTU-BUDGET: underlay=1500 jumbo=no tenant_mtu=1444 verdict=PASS

  $ bash scripts/dc-dc-mtu-geneve-budget.sh --underlay-mtu 9000
    Underlay is jumbo (>= 9000).
    Per D-101: tenant MTU stays 1500; geneve/amphora headroom is generous.
    VERDICT: PASS
    MTU-BUDGET: underlay=9000 jumbo=yes tenant_mtu=1500 verdict=PASS

  NOTE: the 56-byte overhead is the IPv6 figure, and it applies BECAUSE R2 ruled
  dual-stack. Under a v4-only deployment the overhead would have been 42 and the
  1500-underlay tenant MTU would have been 1458. R2 and R3 are coupled.

  NOTE ON THE SCRIPT: invoked bare it correctly REFUSES -- "FAIL: --underlay-mtu
  is REQUIRED (no default -- measure it this session)". It does not guess. That
  is the assert-on-content discipline working.

---------------------------------------------------------------------
5. VERDICT AS RULED (R3, 2026-07-27)
---------------------------------------------------------------------
Operator selection, exact utterance: "Raise the two lagging segments to 9000
(Recommended)".

Target state: underlay jumbo END TO END, tenant MTU stays 1500, no per-charm MTU
coordination required.

Work implied (each a gated mutation, NOT authorised by the ruling):
  a. Raise `enp1s0` MTU to 9000 inside BOTH containment VMs (vvr1-dc0, vvr1-dc1),
     persistently -- a netplan/config change, not just `ip link set`.
  b. Raise the MAAS VLAN MTU records to 9000 on the plane fabrics, so MAAS renders
     jumbo into node netplan.
  c. LEAVE the four simulated-ISP uplink legs at 1500 (see section 1).
  d. Re-run this budget script with `--underlay-mtu 9000` and capture the verdict
     as the closing evidence.

Verification owed after the change: an end-to-end large-frame test across the
inter-DC path (dc0 rack -> virbr5 -> dc1 rack) with DF set, not merely a reading
of the interface MTUs. An interface claiming 9000 is not proof a 9000-byte frame
survives the path.