admin/bf-infra
1
0
Fork 0
Code Issues 21 Pull Requests Actions Packages Projects Releases Wiki Activity
Files
f0d1ff9377fb43e7aad6a3c958816a478aebf97b
bf-infra/PLAN.md
Christoph Emsenhuber d281a0f36f 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>
2026-08-07 22:39:29 +02:00

4.4 KiB
Raw Blame History

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.
Reference in New Issue View Git Blame Copy Permalink