Initial import from bf-network-r6.opencode — opencode migration

docs/tp15-core-swap-session-handoff-prompt.md

@@ -0,0 +1,92 @@
+# TP15 — Handoff-Prompt: Core-Tausch = L3-Umzug ap1 → crs326-core (neue Session)
+
+> **Zweck:** Kopierfertiger Auftrag für eine frische Session, die `crs326-core` produktiv setzt:
+> sw1 (ALLNET) physisch ablösen **und gleichzeitig** Routing/DHCP/DNS von ap1 auf den CRS326 umziehen.
+> **Das ist ein geplantes Vollausfall-Ereignis** — nicht nebenbei, sondern mit Wartungsfenster.
+>
+> **Voraussetzung erfüllt (2026-07-23):** Branch-Tausch ist durch, `crs326-core` ist grundkonfiguriert und
+> erreichbar. Diese Session ist der zweite, riskantere Teil.
+>
+> **So übergibst du es:** Neue Session, erster Prompt:
+> „Lies `docs/tp15-core-swap-session-handoff-prompt.md` und arbeite den Auftrag darin ab."
+
+--- PROMPT ---
+
+```
+TP15 — Core-Tausch: crs326-core wird L3-Router (ersetzt sw1) + L3-Umzug von ap1.
+
+‼️ DAS IST EIN VOLLAUSFALL ‼️
+An sw1 hängt auf #15 ap1 = Gateway/DHCP/DNS/WAN fürs GANZE Haus. sw1 zu tauschen UND L3 von ap1
+wegzuziehen ist EIN Ereignis. Während des Cutovers ist das komplette Netz offline, inklusive des
+eigenen Management-Pfads. Vorher: Wartungsfenster ansagen, Rettungspfad klären (Notebook-Zugang der
+NICHT über den zu tauschenden Kern läuft), Rollback-Plan bereitlegen (sw1 + ap1-Config bleiben bis
+zum Beweis unangetastet/zurückspielbar).
+
+KONTEXT ZUERST LESEN:
+1. docs/teilprojekte.md — TP15 (As-built Bring-up/Branch-Tausch 2026-07-23), TP4 (ap1 heutige
+   L3/DHCP/DNS/NAT-Config = die Vorlage, die umzieht), TP16.1 (CF-Mesh terminiert künftig auf core),
+   TP5/TP6 (Firewall + CAKE landen auf core), TP3 (WLAN-Neuprovisionierung DANACH).
+2. CLAUDE.md — Hardware/Zugänge (crs326-core = 10.40.99.11 / VLAN1-Temp 10.40.41.211, admin/~/.secrets).
+3. nautobot/README.md — GraphQL-Verifikation. Nautobot hat core als "Planned" mit tentativem Layout.
+
+IST-STAND core (aus dem Bring-up 2026-07-23):
+- crs326-core an sw1 #12, RouterOS 7.19.5, identity gesetzt, vlan-filtering=yes, volle Bridge-VLAN-
+  Tabelle 1/10/20/30/40/50/90/99/100 (ether1 Uplink-Trunk, ether2 war Temp-Downlink zu branch).
+- Mgmt 10.40.99.11 (VLAN99) — erreichbar erst, wenn sw1 #12 VLAN99 tagged trägt (aktuell nur VLAN1);
+  Arbeitskanal diese Session bisher = 10.40.41.211 (VLAN1) über sw1 #12 native.
+- NUR Switching. KEIN L3 (keine /ip address je VLAN außer Mgmt, kein DHCP, kein DNS, kein NAT).
+
+ZIEL-LAYOUT core (User-Survey, "neu"-Vorgabe 2026-07-22 — VLAN99 pro Port noch am Gerät gegenprüfen):
+- #4  ap1-Uplink-Trunk (ap1 wandert von sw1 #15 auf core #4; ap1-seitig Uplink ether2→ether1/PoE-Port)
+- #2/#3/#5 Sonos VLAN40 untagged (+ die weiteren Sonos-/Hybrid-/pve-/sonoff-Ports aus der sw1-Survey,
+  s. Nautobot sw1 GE1-16 Beschreibungen = die verifizierte Alt-Belegung, die auf core abgebildet wird)
+- #16 Arris → WAN VLAN100 (Access); der WAN-Trunk-Pfad zu ap1 entfällt, WAN terminiert künftig auf core
+- #8 → crs326-branch (Uplink zur OG-Branch)
+- Kapazität/Ports final beim Umstecken festklopfen.
+
+WAS UMZIEHT (ap1 → core), Vorlage = ap1s heutige Config (TP4):
+- VLAN-Subinterfaces vlan10..vlan99 auf der core-Bridge + GW-IP .1 je VLAN.
+- DHCP-Server je VLAN (Pools .100-.200, GW+DNS = VLAN-GW) inkl. aller MAC-Reservierungen (Sonos, Shelly,
+  NAS/macmini/pve statisch, Drucker …) — 1:1 von ap1 exportieren.
+- DNS-Resolver (allow-remote-requests, DoH-Upstream Cloudflare Gateway, 13 statische bf.lan-A-Records).
+- NAT srcnat masquerade out=vlan100 (Public-Edge wandert auf core).
+- Routing: Default via Liwest-GW auf vlan100; Connected-Routes je VLAN.
+- WAN-Input-Firewall-Seal (TP10) + später Deny-by-default (TP5) + CAKE (TP6).
+- CF-Mesh WG-Node (TP16.1) — NACH dem Cutover, eigener Schritt.
+
+ABLAUF-EMPFEHLUNG (reversibel bauen, dann in EINEM Fenster cutovern):
+1. core L3 VORBEREITEN, solange ap1 noch Router ist: VLAN-Interfaces + IPs auf core anlegen, ABER die
+   GW-IPs .1 NICHT doppelt aktiv fahren (IP-Konflikt mit ap1). Trick: DHCP/DNS auf core bauen aber
+   disabled, VLAN-GW-IPs erst im Cutover-Moment aktivieren. Alternativ core-L3 komplett scripten und
+   als ein Import-Block bereitlegen.
+2. sw1-Kabel-Umzugsplan festklopfen (welcher sw1-Port → welcher core-Port), ap1 #15→#4.
+3. CUTOVER-Fenster: ap1 als Router stilllegen (DHCP/DNS/NAT/VLAN-GW-IPs runter ODER ap1 direkt auf
+   reinen AP zurückbauen), sw1-Kabel auf core umstecken, core-L3 aktivieren, WAN (Arris) auf core #16.
+4. Verifizieren: je VLAN DHCP-Lease + GW-Ping + Internet; DNS bf.lan; NAT; branch weiterhin über core;
+   WARP/CF. Rollback = Kabel zurück auf sw1 + ap1-Config-Restore.
+5. ap1/ap2 werden reine APs → danach WLAN-Neuprovisionierung ohne CAPsMAN (TP3, eigene Session).
+
+GOVERNANCE: Die Bring-up-Ausnahme #2 (2026-07-22) deckte NUR den Grundconfig-Bring-up. Für den
+produktiven L3-Umzug braucht es entweder Nautobot Golden Config (TP21) ODER eine neu zu erteilende
+Ausnahme (User fragen). Ergebnis danach als intended nach Nautobot zurückschreiben.
+
+MGMT-RENUMBER (User-Vorgabe): nach Austausch BEIDER Switches erben die neuen die Alt-IPs —
+core bleibt 10.40.99.11, branch 10.40.99.13 → 10.40.99.12. VLAN1-Temp-IPs (.41.211/.41.213) entfernen.
+
+NICHT ANFASSEN bis Cutover: die produktive branch-Config (läuft), die Lifeline-Ports.
+
+ABNAHME: alle VLANs bekommen DHCP+GW+Internet über core; DNS/NAT/WAN auf core; branch + alle OG/UG-
+Geräte erreichbar im korrekten VLAN; ap1/ap2 reine APs; Nautobot bildet core produktiv ab (GraphQL).
+
+DOKU (Pflicht): teilprojekte.md TP15/TP4 fortschreiben, CLAUDE.md/ip-plan.md (core produktiv, ap1 = AP),
+Nautobot nachziehen, Gotchas. Commit + Push (deutsch, Bullet, Co-Authored-By).
+```
+
+--- ENDE PROMPT ---
+
+## Was Christoph zur Session parat haben sollte
+- **Wartungsfenster** (komplettes Netz offline während des Cutovers).
+- **Rettungspfad**, der NICHT über sw1/ap1 läuft (z.B. Notebook direkt an core, oder Handy-Hotspot).
+- **Entscheidung Governance:** L3-Umzug via Nautobot GC (TP21) oder frische Direkt-Ausnahme.
+- **sw1-Port→core-Port-Umzugsplan** final (ap1 #15→#4, Arris #16, pve, sonoff, cudy1, Sonos …).
+- **DC-USV** (falls parallel geplant, TP15 HW-Teil).