# TP15 Core-Swap — Session-Handover (Prep → Cutover)

> **Von:** Prep-Session 2026-07-23 (kein Netz-Eingriff). **An:** die Cutover-Session (eigenes Wartungsfenster).
> **Erster Prompt der neuen Session:** „Lies `docs/tp15-core-swap-session-handover.md` und führe den Core-Swap
> im Wartungsfenster durch." Der ausführliche Auftrag/Runbook liegt zusätzlich in
> `docs/tp15-core-swap-session-handoff-prompt.md`; dieses Doc ist der aktuellere Einstieg.

---

## Was ist passiert (Prep-Session)
ap1s komplette Live-L3-Config wurde gelesen und **fertig als staged Config materialisiert**:
`routeros/tp15-core-l3-staged.rsc` — alles Betriebsumlenkende `disabled=yes`, im Cutover in EINEM Rutsch `enable`.
Runbook/Rollback/Verifikation stehen im Plan; die drei Fenster-Entscheide sind gefällt. **Kein Gerät angefasst.**

## Locked decisions (gelten, nicht neu diskutieren)
1. **WG-Hub (TP10 FM/DW-VPN) migriert MIT** in dasselbe Fenster. (Hing im Handoff-Prompt nicht drin — er sitzt auf
   ap1s Public-Edge und kann dort nicht bleiben.)
2. **Governance = frische Direkt-Ausnahme #3** (REST/MikroMCP), danach Ist-Stand als *intended* → Nautobot.
   ⚠️ **User muss die Ausnahme #3 zu Fensterbeginn formal erteilen.**
3. **Rettungspfad = iPhone-Hotspot** am Notebook (nicht über sw1/ap1).

## Endpoint-Frage (war der letzte offene Rechercheposten) — ✅ GEKLÄRT
- Spokes adressieren den Hub über **`bf4.emsenhuber.net:51821`** = **Cloudflare-A-Record** (proxied=false, TTL 120,
  aktuell `90.146.35.38` = ap1s Public-IP). **Kein DDNS-Updater auf ap1** (nur WANTEST/mac-clone-Scripts) → nichts
  zu migrieren. `/ip/cloud` = MikroTik-DDNS `update-interval=none`, irrelevant (andere Domain).
- **Cutover-Konsequenz:** Liwests Lease ist sticky → core zieht am WAN sehr wahrscheinlich **dieselbe** IP → `bf4`
  passt weiter → FM/DW kommen von selbst hoch. **Falls doch neue IP:** per `CF_API_TOKEN` nachziehen —
  (a) `bf4`-A-Record **und** (b) CF-Access-Policy `bf4-home-ip` (`90.146.35.38/32`). (CF-MCP ist read-only!)
- **Chance:** core ist **nicht** `device-mode=home` → **scheduler+fetch gehen** → den `bf4`-DDNS-Auto-Updater bauen,
  den ap1 nie konnte → schließt den offenen TP10-Follow-up (`docs/teilprojekte.md:289`).

## Bekannte Prep-Gotchas (im Fenster einplanen)
- **MikroMCP kann core noch NICHT schreiben:** `ROUTER_CRS326_CORE_USER/PASS` sind im MCP-Prozess nicht geladen
  → **vor dem Fenster MikroMCP neu starten** (ENV `CRS326_CORE_*` aus `~/.secrets/credentials.env`) **oder**
  REST-curl gegen `http://10.40.41.211/rest` (wie beim Bring-up).
- **core-Mgmt `.99.11` ist tot** (sw1 #12 trägt kein 99T) — erreichbar nur VLAN1-Temp **`10.40.41.211`**.
- **WG-Privkey:** ap1s `wg-hub`-Private-Key im Fenster von ap1 holen und auf core setzen (Platzhalter im `.rsc`),
  damit core denselben Public Key hält → FM/DW brauchen keine Reconfig. **Secret → nicht committen.**
- **vlan99:** core-GW wird `.1`; Bring-up-`.11` dadurch redundant → im Fenster reconcilen (Secondary behalten oder droppen).
- **VLAN1 raus:** Hybrid-VLAN1-Drops sw1 GE3/GE7/GE10 (+ GE1) beim Umstecken echtem VLAN zuordnen oder stilllegen.

## Pre-Window-Checkliste (was Christoph parat haben muss)
- [ ] Wartungsfenster gewählt (Vollausfall Haus), iPhone-Hotspot am Notebook aktiv.
- [ ] Governance-Ausnahme #3 formal erteilt.
- [ ] MikroMCP neu gestartet (core schreibbar) **oder** REST-curl bereit.
- [ ] Port-Umzugsplan sw1→core final (Anker: **#4=ap1, #8=branch, #16=WAN**; Rest gegen Verkabelung prüfen).
- [ ] ap1-Voll-Backup (`/export`, `create_backup`) frisch gezogen.

## Cutover-Schritte (Kurzform — Detail im Plan/Handoff-Prompt)
1. Staged core-Config bauen (`.rsc`, alles disabled) + Reservierungen maschinell von ap1 heben
   (`/ip/dhcp-server/lease/export`, nur `dynamic=no`) + WG-Privkey einsetzen.
2. ap1 als Router stilllegen (DHCP/DNS/NAT/GW-IPs/WAN-DHCP-Client/`wg-hub` down; Config bleibt restorbar).
3. Kabel sw1→core umstecken (ap1 `ether2`→`ether1`/PoE, `poe-out=off`), sw1 stromlos.
4. core-L3 in einem Rutsch `enable` (GW-IPs, DHCP-Server, WAN-DHCP-Client, WG, DNS/NAT/Firewall).
5. **Abnahme:** je VLAN Lease/GW-Ping/Internet · DNS `*.bf.lan` · branch über core #8 · **WG fm+dw Handshake <2m** +
   Ping in `10.101.0.0/24`/`10.95.10.0/24` · CF/WARP · Public-IP==bf4 (sonst CF nachziehen) · VLAN1 endgeräte-frei.
6. **Rollback jederzeit:** Kabel zurück auf sw1 + ap1 wieder `enable` → Netz wie zuvor.

## Nach erfolgreichem Cutover
- Mgmt-Renumber (branch `.99.13`→`.99.12`, core `.99.11`-Reconcile), VLAN1-Temp-IPs (`.41.211`/`.41.213`) entfernen.
- Ist-Stand als *intended* → **Nautobot** (core `Planned`→`Active`, finale Ports, GraphQL-verifiziert).
- Doku: `teilprojekte.md` TP15/TP4, `CLAUDE.md`, `docs/ip-plan.md` (core produktiv, ap1 = AP). Commit + Push.
- **Danach TP3** — WLAN-Neuprovisionierung ohne CAPsMAN (ap1/ap2 reine APs, aus Nautobot generiert). Eigene Session.
- Optional gleich mitnehmen: `bf4`-DDNS-Auto-Updater auf core (TP10-Follow-up).

## Artefakte
- `routeros/tp15-core-l3-staged.rsc` — die staged L3-Config (Vorlage = ap1-Live 2026-07-23).
- `docs/tp15-core-swap-session-handoff-prompt.md` — ausführlicher Original-Auftrag/Runbook.
- `nautobot/ingest-crs326-ports.py` — sw1-Belegung (`:190`) + core-Ziel-Layout (`:167`).
- `~/.secrets/credentials.env` — `CRS326_CORE_*` (REST/MCP), `CF_API_TOKEN` (CF-Writes).