71 lines
5.3 KiB
Markdown
71 lines
5.3 KiB
Markdown
# 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).
|