Christoph Emsenhuber
d281a0f36f
- 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>
82 lines
4.4 KiB
Markdown
82 lines
4.4 KiB
Markdown
# 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.
|