Files

Christoph Emsenhuber d8c8c3b828 TP15: WG-Endpoint (bf4) geklaert + Session-Handover

- bf4.emsenhuber.net = CF-A-Record (proxied=false, TTL120, 90.146.35.38),
  KEIN Updater auf ap1 -> nichts zu migrieren. Bei WAN-IP-Wechsel via
  CF_API_TOKEN nachziehen (bf4-Record + Access-Policy bf4-home-ip). Core
  ist nicht device-mode=home -> DDNS-Auto-Updater dort baubar (TP10-Follow-up).
- docs/tp15-core-swap-session-handover.md: Einstieg fuer die Cutover-Session
  (locked decisions, Pre-Window-Checkliste, Kurz-Runbook, Gotchas).
- staged .rsc + teilprojekte.md entsprechend fortgeschrieben.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

2026-07-23 18:02:10 +02:00

5.3 KiB

Raw Blame History

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)

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.)
Governance = frische Direkt-Ausnahme #3 (REST/MikroMCP), danach Ist-Stand als intended → Nautobot. ⚠️ User muss die Ausnahme #3 zu Fensterbeginn formal erteilen.
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)

Staged core-Config bauen (.rsc, alles disabled) + Reservierungen maschinell von ap1 heben (/ip/dhcp-server/lease/export, nur dynamic=no) + WG-Privkey einsetzen.
ap1 als Router stilllegen (DHCP/DNS/NAT/GW-IPs/WAN-DHCP-Client/wg-hub down; Config bleibt restorbar).
Kabel sw1→core umstecken (ap1 ether2→ether1/PoE, poe-out=off), sw1 stromlos.
core-L3 in einem Rutsch enable (GW-IPs, DHCP-Server, WAN-DHCP-Client, WG, DNS/NAT/Firewall).
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.
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).

5.3 KiB Raw Blame History