diff --git a/docs/dc-dc-netbox-buildout-scope.md b/docs/dc-dc-netbox-buildout-scope.md index fa5107f..d3ca841 100644 --- a/docs/dc-dc-netbox-buildout-scope.md +++ b/docs/dc-dc-netbox-buildout-scope.md @@ -115,7 +115,7 @@ # DC1 (v4 inherited; only v6 top-level blocks required) ORG_ULA_48=fd50:840e:74e2::/48 DC_GUA_PREFIX=2602:f3e2:f02::/48 --dc dc1 # DC2 (distinct v4 supernet ALSO required -- >= /19; tool re-packs 6 sequential /22s, see 5.3) -ORG_ULA_48=fd50:840e:74e2::/48 DC_GUA_PREFIX=2602:f3e2:f03::/48 DC2_V4_SUPERNET=10.13.0.0/19 --dc dc2 +ORG_ULA_48=fd50:840e:74e2::/48 DC_GUA_PREFIX=2602:f3e2:f03::/48 DC2_V4_SUPERNET=10.12.64.0/19 --dc dc2 ``` Run `--verify-only` first. The tool creates the six-plane v4 + the D-101 family-matrix v6 legs. @@ -154,7 +154,7 @@ 3. **DC2 v4 supernet value + size.** D-101 leaves it NetBox-assigned. The import tool (`DC2_MIN_SUPERNET_PREFIXLEN = 19`) carves **six SEQUENTIAL `/22`s** from the supernet base and FAILS LOUD below `/19` (a `/19` = 8 `/22`s; six used, two spare). So a **`/19` is correct** - (e.g. `10.13.0.0/19`); DC2's planes land at sequential offsets (`.0/.4/.8/.12/.16/.20`), NOT + (`10.12.64.0/19` per D-115; was `10.13.0.0/19`); DC2's planes land at sequential offsets (`.0/.4/.8/.12/.16/.20`), NOT mirroring DC1's `.4/.8/.12/.16/.32/.36` -- fine per D-101 (same six-plane *structure*, not same offsets). Just pick a non-colliding `/19` (per D-074). @@ -185,4 +185,4 @@ | `ORG_ULA_48` | unassigned | `fd50:840e:74e2::/48` (ratify) | | `DC_GUA_PREFIX` dc1 | ambiguous | `2602:f3e2:f02::/48` (existing VR1 DC0 site block, renamed dc1) | | `DC_GUA_PREFIX` dc2 | ambiguous | `2602:f3e2:f03::/48` (existing VR1 DC1 site block, renamed dc2) | -| `DC2_V4_SUPERNET` | unassigned | `10.13.0.0/19` (distinct; tool needs >= `/19`, re-packs 6 sequential `/22`s -- see 5.3) | +| `DC2_V4_SUPERNET` | **ASSIGNED (D-115)** | **`10.12.64.0/19`** -- INSIDE the Cloud `/16`, free (DC1 holds `10.12.{4,8,12,16,32,36}`), DC1<->DC2 stay routable. The old `10.13.0.0/19` recommendation was OUTSIDE every allocated block (it would have squatted); D-115 supersedes it. Tool needs >= `/19` and re-packs 6 sequential `/22`s -- see 5.3. | diff --git a/docs/design-decisions.md b/docs/design-decisions.md index 499ad56..e0620cf 100644 --- a/docs/design-decisions.md +++ b/docs/design-decisions.md @@ -2574,7 +2574,7 @@ ## D-115: VR1 Office1 addressing -- the office carve, and the v4 role gaps it exposed -**Status:** **PROPOSED / OPEN (2026-07-13). Operator to rule.** Found during Office1 deployment +**Status:** **ADOPTED 2026-07-13 (operator ruling -- see the amendment at the end of this entry).** Originally PROPOSED/OPEN the same day. Found during Office1 deployment testing: the headend was built on address space that NetBox never assigned. Per the operator, the IPAM carve matters MORE than the deployment already standing on it -- "we can always change the current IP addressing on the deployment; getting the IPAM carve proper and correct is more @@ -2673,3 +2673,73 @@ `10.20.0.0/16` -- the reason the obvious `10.20.x` was NOT used for the compose net), `docs/dc-dc-netbox-buildout-scope.md` (whose `DC2_V4_SUPERNET = 10.13.0.0/19` recommendation this decision would supersede under option (a)), D-114 (which built the headend that exposed all of this). + +### D-115 -- AMENDMENT (2026-07-13): ADOPTED by operator ruling, with a measured constraint attached + +**Operator ruled all three questions:** +1. **v4 stays ROLE-BASED; fill in the missing roles.** Option (a). v6 keeps its region hierarchy; + v4 is pooled by function. No DC renumber; D-101's inherit-DC0-unchanged economy is preserved. +2. **`/22` per office.** VR1 Office1 = **`10.10.0.0/22`** -- which BLESSES the deployed LAN + (`10.10.0.0/24`) and LXD compose net (`10.10.1.0/24`) exactly. Zero deployment renumber. +3. **Register AND deploy dual-stack on Office1 NOW** -- Office1 becomes the first real dual-stack + proof and de-risks D-101's family matrix early. + +**THE ADOPTED CARVE** + +v4 (new roles marked): +``` +10.0.0.0/8 Corp Private + |- 10.10.0.0/16 Office <-- NEW ROLE + | |- 10.10.0.0/22 VR1 Office1 + | |- 10.10.0.0/24 office1-local (site LAN; Kea on the edge) [as deployed] + | |- 10.10.1.0/24 lxdbr0 compose net (MAAS DHCP/PXE) [as deployed] + | |- 10.10.2.0/24, 10.10.3.0/24 spare + |- 10.12.0.0/16 Cloud + | |- 10.12.{4,8,12,16,32,36}.0/22 DC1 planes [unchanged -- D-101 inheritance] + | |- 10.12.64.0/19 DC2 <-- MOVED INSIDE the Cloud /16 + |- 10.16.0.0/16 Datacenter (Willamette dev) + |- 10.17.0.0/16 Datacenter (Roosevelt dev -- the physical lab net) +172.16.0.0/12 Corp + |- 172.30.0.0/16 Edge (simulated ISP uplinks) <-- NEW ROLE, mirrors v6's fe::/48 + |- 172.30.1.0/24 office1-wan [as deployed] +``` +**This SUPERSEDES `docs/dc-dc-netbox-buildout-scope.md`'s `DC2_V4_SUPERNET = 10.13.0.0/19`**, which +sat outside every allocated block. DC2 becomes `10.12.64.0/19` -- free (DC1 occupies +`10.12.4/8/12/16/32/36`), inside the Cloud role, and still routable to DC1 over the dark fiber. + +v6 (determined by the existing pattern -- no design freedom): +``` +2602:f3e2:f01::/48 VR1 Offices [exists] + |- 2602:f3e2:f01:100::/56 VR1 Office1 <-- CREATE (+ the "VR1 Off1" site) + |- 2602:f3e2:f01:100::/64 Office1 office subnet <-- CREATE +``` + +### MEASURED CONSTRAINT (2026-07-13) -- IPv6 DOES NOT EGRESS THE LAB + +Discovered while planning ruling 3. On vcloud: +- Global v6 addresses present (`2602:f3e2:e00:100::/64` SLAAC + a `/128`), and a v6 default route + via RA. +- The v6 default gateway (link-local `fe80::e68d:8cff:fe14:7cd5`) **IS reachable** -- RA and L2 work. +- **But v6 INTERNET is UNREACHABLE**: both `2606:4700:4700::1111` and `2001:4860:4860::8888` fail, + 100% loss. v4 egress from the same host is fine. + +**Consequence, stated plainly so nobody builds on a false premise:** deploying dual-stack on Office1 +proves v6 ADDRESSING, RA, and services binding v6 -- which is most of D-101's family matrix and is +worth doing. It does **NOT** prove v6 INTERNET reachability, and it cannot: the GUA is not routed +past the lab boundary. **Public-facing GUA reachability (public API endpoints on v6, tenant GUA +egress) is UNPROVABLE in VR1 until the lab's upstream actually carries v6.** That is a network +issue OUTSIDE this cloud and outside this repo -- it needs the lab/upstream operator, not a change +here. Do not schedule a VR1 test that depends on it, and do not let a green internal-v6 result be +read as "v6 works end to end". + +`office1-wan` currently has **no v6 at all** (v4 NAT only), and `office1-local` is an addressless +isolated bridge (correct -- the OPNsense edge owns addressing on it). + +### NetBox write path -- NOT done unilaterally + +The carve above is recorded HERE (the repo) as the decision of record. Writing it into +`netbox.baldurkeep.com` is a MUTATION ON A PRODUCTION SYSTEM and is gated on explicit operator +approval; the standing architecture is read=source / write=feedback-only, with the Office1 sandbox +NetBox as the place changes are simulated first. The Office1 NetBox VM is composed and `Ready` but +not yet deployed -- so the natural sequence is: deploy it, import this carve there, verify, then +feed back to the real NetBox.