NetBox subnetting DRAFT -- VR1 DC-DC rebuild on 10.13.0.0/16

DRAFT -- proposal, NOT ruled, NOT committed. This is a planning artifact only. It does not touch live NetBox, live infra, lib-net.sh, the overlays, or any other authoritative surface. No git commit. It exists to let the operator rule the re-IP (F1 pivot, below) with the full blast radius in view.

• Author: background agent (Task #2), 2026-08-08.
• Method: read-only extraction from scripts/lib-net.sh (full), netbox/draft/vr1-office1-current-20260801.json, docs/design-decisions.md (D-115, D-134), and a repo-wide grep sweep for 10.12. literals. Every value below is measured from those files this session; none is inferred.
• Governing decisions named for the owed ruling: D-101 / D-115 / D-124 / D-134 (per docs/audit/queued-findings-20260808-...-reip-pivot.txt F1).

1. Why (the pivot)

docs/audit/queued-findings-20260808-dc0-tailscale-incident-reip-pivot.txt F1 records the operator pivot verbatim: the VR1 build's 10.12.0.0/16 collides with the still-online IPv4 single-DC cloud (the NetBox draft that seeded VR1 was that cloud's external export). It surfaced at the Headscale step -- advertising 10.12.8.0/22 overlaps the live cloud on the shared tailnet, and Headscale has no 4via6, so routes must be non-overlapping. Operator plan: drive dc0 to a full-deployment checkpoint, then teardown + redeploy on 10.13.0.0/16 -- a fresh subnetting build, never editing live infra.

This draft is the addressing half of that redeploy. It is a greenfield build on a free /16, so "re-IP" here means "author the new plan"; there is no live-object edit.

2. Proposed mapping principle -- 1:1 octet-preserving shift

10.12.a.b -> 10.13.a.b for every DC (Cloud) address. Second octet 12 -> 13; octets 3 and 4 unchanged.

This preserves, exactly and by construction:

• the six-plane role layout and offsets for both DCs,
• dc1's 10.12.64.0/19 -> 10.13.64.0/19 /19 supernet (D-115),
• the D-134 utility octet map (.4/.5/.6/.7) and the .4-.49 / .50-.99 bands,
• the triple-HA VIP columns and octets (D-020),
• the FIP pool sizes and offsets,
• the keystone public VIP octet.

Only the DC (Cloud-role) 10.12 space moves. Everything else stays (Section 6).

3. Before / after tables

3.1 DC0 planes (vr1-dc0; flat /22s, D-052/D-053 offsets)

3.2 DC1 planes (vr1-dc1; contiguous /22s inside the 10.12.64.0/19 supernet, D-115)

3.3 Gateways (PLANE_GW) -- unchanged posture, shifted value

Per D-134 the .1 gateway exists on the provider-public subnet ONLY; metal-admin and the four data planes are gw=none (measured; MAAS returns none, .1 is held by NOTHING on both DCs). The VR0-only vr0-dc0 arm additionally pins metal-admin 10.12.8.1 -- that arm is NOT part of this rebuild (it is the live cloud; see OQ (a)/(c)).

3.4 VIP prefixes (triple-HA columns, D-020/D-052) + keystone public VIP

VIP band .50-.99 (VIP_OCTET_MIN=50, VIP_OCTET_MAX=99), VIP_COUNT_EXPECT=13 (11 + vault .61 + designate .62, R11) -- all UNCHANGED. The 13 service VIP octets (.50 keystone .. .62 designate) are octet-preserved on each of the three legs.

3.5 D-134 utility bands + octet map (per plane)

Each plane carries a .4-.49 utility band and a .50-.99 VIP band (NetBox ip-ranges). The D-134 utility octet map (extended by D-129(iii)(a) for .7) rides the metal-admin plane:

(The .4-.49 / .50-.99 band ip-ranges exist on ALL six planes per DC, 24 ranges total; each shifts by the same 12->13 rule.)

3.6 FIP pools (D-003) -- NOTE: MAAS reserved ipranges, not NetBox objects

Each sits inside its DC's provider-public /22 and does not overlap the D-134 .4-.49 / .50-.99 bands. These pools are RESERVED ipranges on the MAAS provider subnet (KI-P3-001), asserted by scripts/phase-04-network-verify.sh -- they are NOT NetBox ip-range objects (the office1 draft holds no FIP-pool range). The re-IP therefore touches MAAS ipranges at build time; NetBox has a standing record gap here.

3.7 MAAS rack-controller statics (D-124 / D-120 static band)

4. NetBox objects to re-scope (from vr1-office1-current-20260801.json)

Counts of objects whose value lies in 10.12 and would shift to 10.13 under the 1:1 rule:

Two structural observations (feed OQ (b), not defects):

• The dc1 /19 supernet 10.12.64.0/19 has no NetBox prefix object -- only its six child /22s are present. If the plan wants the supernet represented, that is a new object either way.
• The FIP pools have no NetBox ip-range object (Section 3.6) -- they live only as MAAS reserved ipranges.

5. Consumer inventory BEYOND NetBox (repo grep sweep, 10.12. literals)

The re-IP is not a NetBox-only change. lib-net.sh names its own twins-of-record (opentofu/variables.tf vr1_dc1_planes; overlays/vr1-dc*-vips.yaml; provider-bundle-check.py's independent octet band). Grouped literal-bearing LIVE surfaces (historical asbuilt/ snapshots and docs/audit/osd-carve-* frozen captures EXCLUDED -- those are verbatim records, not to be edited):

Discipline note: each script change ships with its tests/<name>/run-tests.sh green, repo-lint clean, and a changelog entry (per CLAUDE.md). The two-file twins (lib-net.sh <-> opentofu/variables.tf, and lib-net.sh <-> overlays/*-vips.yaml via tests/dc-selector) must change in the SAME commit. This inventory is scope visibility for the ruling, NOT a per-line remediation plan.

Stale 10.13 reference already in-repo (pre-D-115): netbox/README.md:49 still shows VR1_DC1_V4_SUPERNET=10.13.0.0/19, an importer default that D-115 superseded (dc1 became 10.12.64.0/19). Reusing 10.13 as the rebuild /16 is unrelated to that old /19 default, but the stale line should be reconciled so the two 10.13 meanings do not confuse.

6. What does NOT shift

Caveat -- transit ADDRESSES stay, transit ROUTES do not. The 172.31.0.x /30 endpoint addresses are unchanged, but the routes carried OVER them point at 10.12.* DC destinations today and must be re-pointed to 10.13.* at rebuild. Flagged so "transit unchanged" is not misread as "transit needs no work."

7. Dependent surfaces beyond IPAM (for the redeploy plan, not this draft)

• Vault-issued cert SANs / IP SANs on every API endpoint and VIP -- reissued against the new addresses at redeploy (D-052 TLS).
• MAAS DHCP ranges on the provisioning planes -- re-declared on 10.13. (Currency note: the measured dc1 DHCP range is .201-.254, not a recalled .100-.200.)
• Tailscale subnet router advertised prefix -- the whole reason for the pivot: 10.12.8.0/22 -> 10.13.8.0/22 (metal-admin), and the Headscale ACL that references the advertised metal-admin prefix per D-129(iii)(b) star model.
• OVN / neutron provider network definitions, and any external/provider network CIDR.
• Charm config / bundle VIPs (bundle.yaml, overlays) -- deploy inputs.
• /etc/hosts and internal DNS seeds (dc-node-etchosts and similar).

8. OPEN QUESTIONS for the operator (DO NOT decide here)

(a) Confirm 10.13.0.0/16 is genuinely free -- LIVE, not just in a snapshot. The 10.13 scan in this draft was against vr1-office1-current-20260801.json (a dated snapshot) -- absent there, NOT a measured live absence. Before committing, confirm 10.13.0.0/16 is free of (i) the still-online IPv4 single-DC cloud, and (ii) anything advertised on the shared tailnet (the exact class of overlap that caused the pivot). 10.14/10.15 also sit free between 10.13 and the 10.16/10.17 dev clouds, if a range choice is wanted.

(b) Exact 1:1 shift, or regularize a wart while greenfield? The 1:1 shift preserves everything but also PRESERVES dc0's non-contiguous offsets (4/8/12/16 then jump to 32/36, skipping 20/24/28) and the resulting dc0-vs-dc1 asymmetry (dc1 fits a /19; dc0 cannot). A greenfield /16 is the only cheap moment to regularize dc0 into a contiguous, /19-shaped block symmetric with dc1 -- at the cost of breaking octet-preservation and diverging further from the Roosevelt/VR0 layout D-101 was built to inherit. Presented as an option with its cost; NOT recommended here.

(c) This re-IP needs a GA-R5 ruling BEFORE any dependent work. Governed by D-101 / D-115 / D-124 / D-134 (F1). The number is deliberately NOT minted here -- grep next-free D-NNN at ruling time. Two reconciliations the ruling must make explicit:

• D-101 inheritance terminates. lib-net.sh's vr1-dc0 arm exists because D-101 rules VR1 DC0 inherits VR0 DC0's v4 layout unchanged, and the live 10.12 cloud IS vr0-dc0. Moving VR1 to 10.13 ends that inheritance: vr0-dc0 STAYS on 10.12 (live, untouched); the vr0-dc0 and vr1-dc0 case arms genuinely split for the first time, and lib-net.sh's lines 124-134 comment ("Same PLANE values as vr0-dc0 ... INHERITS VR0 DC0's v4 layout UNCHANGED") becomes FALSE and owes an update.
• D-115 rejected 10.13 as "outside every allocated block." D-115 (adopted) put the NetBox Cloud role at 10.12.0.0/16 and explicitly superseded a 10.13.0.0/19 recommendation because 10.13.x was unallocated. Its option (b) even floated a per-region /16 (VR1 = 10.15.0.0/16) and the operator chose role-based instead. Picking 10.13.0.0/16 now REVIVES 10.13 as an allocation and must decide: does the NetBox Cloud role/prefix move to 10.13.0.0/16 (leaving the live cloud's 10.12 as its own record), does 10.13 become a NEW role (e.g. "Cloud -- VR1 rebuild") coexisting with the 10.12 Cloud, and is this a D-115 amendment or a superseding decision? This is a genuine fork in the IPAM apex, not a mechanical shift.

9. Summary line

Proposed: octet-preserving 10.12.a.b -> 10.13.a.b for the entire VR1 Cloud DC space (both DCs), everything else held. Remapped: 12 planes (6 per DC), 13 prefixes, 24 ip-ranges, 80 ip-addresses (78 VIP legs + 2 MAAS rack statics), 2 FIP pools (MAAS ipranges), 2 keystone VIPs, 1 provider gateway per DC. Held: 172.31 transit addresses (routes re-point), 10.10 office, 172.30 edge, 10.16/10.17 dev, all IPv6, the 10.0.0.0/8 aggregate.

DRAFT -- proposal, not ruled, not committed.