admin/bf-infra
1
0
Fork 0
Code Issues 21 Pull Requests Actions Packages Projects Releases Wiki Activity
Files
bca8f6e27e536725b9794ea7e292dffc2b896f9e
bf-infra/PLAN.md

8.6 KiB
Raw Blame History

TP21-Plan — Nautobot Golden Config + AP-Neuprovisionierung

Stand: 2026-08-08. Der CRS326-Core-Cutover (TP15) ist vollzogen (crs326-core ist produktiver L3-Router). TP21 muss die Control-Plane (Nautobot) wieder flott bekommen, die 4 MikroTik-Geräte sauber in Nautobot/GC erfassen und die APs als reine Access-Points neu aufsetzen.

Caveats aus dem aktuellen Zustand (docs/tp15-session-summary-20260808.md):

  • bf4.emsenhuber.net zeigt auf 90.146.33.177 — das ist die aktuelle Public-IP des core-WAN (vlan100). ✅ passt.
  • Der WireGuard-Hub läuft bereits auf crs326-core; FM-Spoke ist connected, DW/Geli-Spoke ist down, weil deren Peer noch das alte ap1-Hub-Public-Key hat.
  • Nautobot ist down (10.40.20.30:8080 → HTTP 500). Gestern liefen 2 Nautobot-Container auf der DS923 in eine Restart-Schleife; du hast sie gestoppt.
  • AP-Zugang blockiert: ap1 REST antwortet mit 401 (Passwort-Mismatch); ap2 ist unter .41.2 nicht mehr erreichbar (erwartete Mgmt-IP .99.2 noch nicht konfiguriert).
  • Passwort-Konsolidierung nötig: Die für meine Tools verwendeten Credentials scheinen nicht die zu sein, die du für UI/SSH erwartest.
  • WG-Privkey-Entscheidung: Wir verwenden den bestehenden ap1-Private-Key weiter, damit DW/Geli keine Reconfig brauchen. FM hat offenbar bereits den neuen core-Key akzeptiert — das muss geprüft/korrigiert werden.

Ziele dieser TP21-Session

  1. Credentials sauber konsolidieren — RouterOS-Admin-Passwörter für ap1/ap2/core/branch auf einen bekannten Satz bringen (SSoT ~/.secrets/credentials.env + Nautobot SecretsGroup, nie in Git).
  2. Nautobot wieder hochfahren und heilen — Ursache für die Restart-Schleife finden, Stack/Healthcheck fixen, auf aktuellen Ist-Stand bringen.
  3. Alle 4 MikroTik-Geräte sauber in Nautobot modellieren — Datenmodell + Plattform + Secrets + Golden-Config-fähig. Live-Config der Switches wird heute nicht via GC geändert, aber das Setup muss für späteres Provisioning stehen.
  4. Endgültige MikroTik-Mgmt-IPs vergeben:
    • crs326-core: 10.40.99.1 (ist gleichzeitig VLAN99-Gateway)
    • crs326-branch: 10.40.99.2 (renumber von .99.13)
    • ap1: 10.40.99.11
    • ap2: 10.40.99.12
  5. ap1 + ap2 als identische, standalone APs neu aufsetzen — keine L3-Leichen, CAPsMAN abbauen, VLAN-Trunk, VLAN99-Mgmt, SSIDs. WiFi-PSKs werden lokal auf den APs von dir hinterlegt, nicht im Nautobot-Template.
  6. WG-Hub auf den alten ap1-Private-Key zurückdrehen — damit FM/DW ohne Reconfig weiterlaufen.
  7. Dokumentation + SSoT aktualisieren — docs/teilprojekte.md, CLAUDE.md, docs/ip-plan.md, Nautobot-Models, Memory.

Reihenfolge

Phase 1 — Vorbereitung & Credentials (15–30 Min, kein Netz-Eingriff)

  1. Backups ziehen

    • crs326-core, crs326-branch, ap1: jeweils /export + /system backup.
    • ap2: sobald erreichbar.

  2. Passwort-Konsolidierung

    • Option A (empfohlen und vorgesehen): Einheitliches neues Admin-Passwort für alle 4 MikroTik-Geräte; ich setze es via meiner Tool-Session durch.
    • SSoT: ~/.secrets/credentials.env + Nautobot SecretsGroup.
    • Keine Credentials in Git.

  3. MikroMCP/REST-Zugänge prüfen

    • crs326-core und crs326-branch testen.
    • ap1: aktuell 401 → Passwort-Konsolidierung löst das.
    • ap2: aktuell .41.2 nicht erreichbar → temporär VLAN1-Zugang via crs326-branch ether24 prüfen; alternativ Factory-Reset.

Phase 2 — Nautobot heilen (15–45 Min)

  1. Container-Diagnose auf DS923

    • Portainer ep14 Logs für nautobot, nautobot-worker, nautobot-scheduler, nautobot-redis prüfen.
    • Fokus: Warum liefen 2 Container in Restart-Schleife? (Memory-Druck, DB-Connect, Healthcheck-Timeout?)
    • NAS-Ressourcen prüfen.

  2. Stack reparieren

    • docs/nas-vlan20/stacks/210-nautobot.yml anpassen: Restart-Policy, Memory-Limits, Healthcheck-Timeouts, depends_on.
    • Falls DB-Problem: nautobot-server post_upgrade oder DB prüfen.

  3. Nautobot auf aktuellen Stand bringen

    • nautobot/ingest-crs326-core-l3.py erneut laufen lassen (Planned → Active).
    • crs326-core, crs326-branch, ap1, ap2 sauber als GC-fähige Devices modellieren.
    • crs326-branch Mgmt-IP auf .99.2 renumbern.
    • ap1/ap2: Rolle Wireless AP, Mgmt-IP .99.11/.99.12, VLAN-Trunk.

Phase 3 — Golden Config Proof-of-Life (15–30 Min)

  1. GC Backup-Job auf core/branch testen

    • Beweist, dass Nautobot → RouterOS-API funktioniert.
    • Falls Backup scheitert: RouterOS-Dispatcher/SecretsGroup/Platform fixen.

  2. GC Setup für alle 4 MikroTik-Geräte vervollständigen

    • Golden-Config-Regeln, Features, SoT-Aggregation Query für RouterOS definieren.
    • Template nautobot/mikrotik_routeros.j2 für reine APs erweitern (Identity, VLAN-Trunk, Mgmt-VLAN99, SSIDs, keine DHCP/DNS/NAT/L3).
    • WiFi-PSKs kommen nicht ins Template — du hinterlegst sie lokal auf den APs.

Phase 4 — WG-Hub auf alten Key zurückdrehen (10–15 Min)

  1. ap1-Original-Privkey aus Backup holen

    • routeros/ap1-pre-core-cutover-20260806-073616.rsc enthält /interface/wireguard mit altem Private-Key.
    • Oder: routeros/ap1-wg-hub.privkey prüfen (war das der alte Key?).

  2. Core-Hub auf alten Privkey umstellen

    • wg-hub auf crs326-core neu anlegen mit altem Private-Key.
    • Dadurch ändert sich der Public-Key auf den alten ap1-Wert → FM/DW brauchen keine Reconfig.
    • FM-Verbindung prüfen (sollte weiterhin funktionieren oder nach kurzem Reconnect funktionieren).
    • DW/Geli-Verbindung prüfen (sollte wieder kommen).

Phase 5 — AP-Neuprovisionierung (30–90 Min, WLAN-Ausfall-Fenster)

  1. ap1 als reiner AP neu aufsetzen

    • Kein Zurückbau — frische Config einspielen.
    • Identity ap1, Mgmt-IP 10.40.99.11/24 auf vlan99.
    • Uplink-Port ether1 (PoE), poe-out=off.
    • VLAN-Trunk auf Uplink: native VLAN1 interim + VLAN99 tagged + Client-VLANs 10/20/30/40/50/90 tagged.
    • SSIDs: dirtyvader-main(10), -infra(20), -iot(30), -media(40), -untrusted(50), -guest(90).
    • WiFi-PSKs von dir lokal auf dem AP hinterlegt.
    • DHCP-Server, DNS, NAT, WAN-Client, WG-Hub, VLAN-GW-IPs entfernen/nicht anlegen.

  2. ap2 identisch neu aufsetzen

    • Falls unter .41.2 nicht erreichbar: temporär VLAN1-Zugang via crs326-branch ether24 (VLAN1 untagged) oder Factory-Reset.
    • Identity ap2, Mgmt-IP 10.40.99.12/24 auf vlan99.
    • Gleiche Config wie ap1 (bis auf Identity/Mgmt-IP).

  3. WLAN-Verifikation

    • dirtyvader-main/iot/media/... je VLAN und AP testen.
    • IOT-Geräte (Shellys etc.) reconnecten.

Phase 6 — Aufräumen & Dokumentation (15–30 Min)

  1. VLAN1-Temp-IPs endgültig entfernen

    • core .41.211, branch .41.213.
    • ⚠️ Nur nachdem VLAN99-Mgmt sicher funktioniert.

  2. Nautobot + Doku aktualisieren

    • docs/teilprojekte.md: TP15 ✅, TP21 Status.
    • CLAUDE.md: core produktiv, ap1/ap2 = reine APs, finale Mgmt-IPs.
    • docs/ip-plan.md: core .99.1, branch .99.2, ap1 .99.11, ap2 .99.12.
    • Memory-Eintrag project_tp21_ap_provisioning anlegen.

  3. Commit + Push (deutsch, Bullet, Co-Authored-By).

Offene Entscheidungen (vor Go zu klären)

# Entscheidung Gewählt
1 RouterOS-Admin-Passwort Einheitliches neues Passwort für alle 4 Geräte
2 ap2-Erreichbarkeit Erst temporären VLAN1-Zugang via crs326-branch prüfen; falls nicht: Factory-Reset
3 WG-Hub-Privkey ap1-Original-Private-Key weiterverwenden, damit FM/DW keine Reconfig brauchen
4 WiFi-PSKs Du hinterlegst sie lokal auf den APs, nicht im Nautobot-Template
5 VLAN1-Temp-IPs Endgültig entfernen, sobald VLAN99-Mgmt stabil ist

Risiken & Rollback

  • ap1-Provisioning: Vor dem L3-Abbau am ap1 frisches Backup haben. Rollback = Backup laden → ap1 ist wieder L3-Router, Kabel zurück auf sw1 (falls sw1 noch verkabelt ist).
  • ap2-Factory-Reset: Physischer Zugang zum Gerät nötig. Recovery = Power-Cycle, falls Config fehlerhaft.
  • WG-Key-Wechsel: Wenn FM bereits auf den neuen core-Key umgestellt ist, bricht FM kurz, bis es den alten Key wieder sieht. Sollte aber funktionieren.
  • VLAN1-Temp-IP-Entfernung: Nur nachdem VLAN99-Mgmt sicher funktioniert. Sonst Lockout.
  • Nautobot-Down: Falls Nautobot nicht schnell heilbar, APs direkt konfigurieren (Governance-Ausnahme, da Nautobot die Control-Plane sein soll).

Erste Schritte sofort nach Go

  1. Task-Liste anlegen.
  2. Passwort-Setzen auf core/branch/ap1/ap2 (einheitlich).
  3. Backups ziehen.
  4. Nautobot-Logs prüfen.
Reference in New Issue View Git Blame Copy Permalink