TP15: CRS326-Core als L3-Router aktiviert

- crs326-core nimmt Routing/DHCP/DNS/NAT/WAN/WireGuard von ap1 ueber.
- L2-Portplan korrigiert (ap1 #15, Arris WAN #16, branch #8, Sonos #2/3/5/6,
  IoT #14, VLAN10-Access #11, VLAN1-Hybrid #3/7/9/10/12/17-24).
- Backup-RSC gefixt (ether3-24 disabled) und via fixed-RSC eingespielt.
- Gestagede L3-Config enabled in einem Rutsch.
- Falsche statische Default-Route 0.0.0.0/0 -> 10.40.41.1 entfernt,
  WAN-DHCP via 90.146.33.177/24 aktiv.
- SFP-Ports bleiben disabled (Stromersparnis).
- ap1 ist L3-stillgelegt und wird in naechster Session reiner AP.

Backup-Dateien (*.backup) und leases-export.json bleiben lokal.

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

PLAN.md

@@ -0,0 +1,81 @@
+# TP15/TP21 Kritischer Pfad — Plan (Stand 2026-08-05, aktualisiert)
+
+> **User-Entscheidung:** Cutover morgen (2026-08-06). Heuteiger Fokus = **Nautobot-Datenmodell für `crs326-core` ausbauen**, damit der Cutover über Nautobot Golden Config geplant/gesteuert werden kann. Governance-Ausnahme #3 damit obsolet für den Config-Teil; die physischen Cutover-Schritte bleiben ein geplantes Wartungsfenster.
+
+## Aktueller Stand (Read-only Checks)
+
+| Komponente | Befund |
+|---|---|
+| **ap1** | Noch aktiver L3-Router, 53 DHCP-Reservierungen, Public-IP `90.146.35.38`, WG-Hub live. RouterOS 7.23.2. |
+| **crs326-core** | Erreichbar nur über VLAN1-Temp `10.40.41.211`. **Keine L3-Config** auf dem Gerät. `10.40.99.11` tot, weil sw1 #12 kein VLAN99 tagged trägt. |
+| **crs326-branch** | Produktiv auf `10.40.99.13`, läuft. |
+| **Nautobot** | App live (`10.40.20.30:8080`), Golden-Config-App installiert, Git-Repo zu Gitea verbunden. **Aber:** `crs326-core` nur rudimentär modelliert (7 Interfaces, keine VLAN-SVIs, keine SecretsGroup), GC-Templates/Regeln nur PoC-Niveau, Scheduler+Worker unhealthy. |
+| **MikroMCP** | In dieser Session **nicht** für core/branch geladen — Env-Variablen-Mismatch (`~/.secrets` exportiert `CRS326_*`, `routers.yaml` erwartet `ROUTER_CRS326_*`). |
+| **Portainer ep14** | API-Token stale/ungültig → Docker-Management auf NAS gestört. |
+| **Postgres / pve-mcp / Gitea / CF-Token** | Grün. |
+
+## Heutiges Ziel (2026-08-05)
+
+**Nautobot-Datenmodell für `crs326-core` so weit vervollständigen, dass morgen ein Config-Render für den L3-Router möglich ist.**
+
+Konkrete Arbeitspakete:
+1. MikroMCP reparieren & neu starten (core/branch schreibbar für Tests).
+2. Portainer-Token rotieren (damit Nautobot-Container-Logs/Health prüfbar sind).
+3. Nautobot worker/scheduler healen.
+4. `crs326-core` Device-Modell in Nautobot vervollständigen:
+   - Interfaces `ether6`–`ether24`, `sfp-sfpplus1`, `sfp-sfpplus2`.
+   - VLAN-SVIs (`vlan10`–`vlan100`) + IP-Adressen (GW `.1` je VLAN).
+   - Access/Trunk-Ports mit korrekten untagged/tagged VLANs gemäß Ziel-Layout.
+   - `SecretsGroup` mit RouterOS-Credentials.
+   - `Platform` = RouterOS.
+   - Status = `Planned` (morgen nach Cutover `Active`).
+5. DHCP-Scopes, statische DNS-Einträge, Firewall-Zonen/-Regeln, NAT, WireGuard-Peers, CAKE-Parameter im Datenmodell abbilden (Custom Fields oder native Modelle, je nach Nautobot-Möglichkeit).
+6. Golden-Config SoT-Aggregation Query erweitern.
+7. RouterOS-Jinja-Template für L3-Core vervollständigen (ggf. anhand von `routeros/tp15-core-l3-staged.rsc`).
+8. GC Compliance-Features/Regeln für kritische Bereiche definieren.
+9. Backup/Intended-Job auf `crs326-branch` testen (Proof-of-Concept für MikroTik-Switch).
+10. ap1-Reservierungen + WG-Privkey maschinell exportieren (Input für Datenmodell + Template).
+
+## Morgiges Ziel (2026-08-06) — Cutover
+
+Voraussetzungen vor dem Fenster:
+- `crs326-core` in Nautobot vollständig modelliert.
+- Golden Config kann ein `intended`-Config für core rendern.
+- MikroMCP schreibbar, dryRun auf core erfolgreich.
+- ap1-Voll-Backup frisch gezogen.
+- Port-Umzugsplan final: core #4=ap1, #8=branch, #16=Arris/WAN; sw1-Rest stilllegen.
+- iPhone-Hotspot als Rettungspfad parat.
+- Wartungsfenster mit Hausmitteilung (ca. 60 Min).
+
+Cutover-Ablauf:
+1. Nautobot `intended` Config für core rendern/exportieren.
+2. ap1 als Router stilllegen (DHCP/DNS/NAT/GW-IPs/WAN-Client/WG-Hub disable).
+3. ap1-Uplink `ether2` → `ether1` (PoE), `poe-out=off`.
+4. Kabel von sw1 auf core umstecken.
+5. core-L3-Config aktivieren (Nautobot-Deploy oder REST/MikroMCP-Apply).
+6. Abnahme je VLAN, branch, WG-Handshake, CF/WARP, Public-IP.
+7. Rollback-Test (optional, aber empfohlen).
+
+## Nach dem Cutover
+
+- Mgmt-Renumber (branch `.99.13` → `.99.12`, core `.99.11` konsolidieren).
+- VLAN1-Temp-IPs entfernen.
+- Nautobot: core `Planned` → `Active`.
+- Doku aktualisieren (`teilprojekte.md`, `CLAUDE.md`, `ip-plan.md`).
+- WLAN-Neuprovisionierung (CAPsMAN-Abbau) als eigene Session.
+- TP5/TP6 danach.
+
+## Rollback (während Cutover)
+
+1. core-L3 deaktivieren / Config zurückziehen.
+2. Kabel zurück auf sw1.
+3. ap1 DHCP/DNS/NAT/GW-IPs/WAN-Client/WG-Hub wieder aktivieren.
+4. Netz wieder im heutigen Zustand.
+
+## Erste Schritte jetzt
+
+1. Task-Liste anlegen.
+2. MikroMCP envPrefix/Secrets fixen + Neustart.
+3. Portainer-Token rotieren.
+4. Nautobot worker/scheduler healen.
+5. Dann in das `crs326-core`-Datenmodell einsteigen.