From 9611d47ef38e27d2251660e2765811294f79e63e Mon Sep 17 00:00:00 2001 From: Christoph Emsenhuber Date: Thu, 16 Jul 2026 09:58:09 +0200 Subject: [PATCH] =?UTF-8?q?docs=20=F0=9F=A7=AD=20Governance=20=E2=80=9ECon?= =?UTF-8?q?fig=20nur=20via=20Nautobot"=20+=20TP19.1-Stand=20(ap1-DNS=20?= =?UTF-8?q?=E2=9C=85,=20ap2=20vertagt),=20sw2-IP-Korrektur=20.41.181,=20VL?= =?UTF-8?q?AN99-Cutover-Guides=20sw1/sw2,=20TP15-Lieferung=2017.07.,=20TP2?= =?UTF-8?q?0=20an=20Komodo=20gebunden?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-Authored-By: Claude Opus 4.8 --- CLAUDE.md | 2 +- docs/ip-plan.md | 2 +- docs/teilprojekte.md | 24 ++++-- sw2/ui-guides/01-vlan99-mgmt-cutover.md | 80 ++++++++++++++++++ switch/ui-guides/02-vlan99-mgmt-cutover.md | 94 ++++++++++++++++++++++ 5 files changed, 192 insertions(+), 10 deletions(-) create mode 100644 sw2/ui-guides/01-vlan99-mgmt-cutover.md create mode 100644 switch/ui-guides/02-vlan99-mgmt-cutover.md diff --git a/CLAUDE.md b/CLAUDE.md index a99c10e..aa8ac52 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -28,7 +28,7 @@ GW je VLAN = `.1` · APs: ap1=`.1`, ap2=`.2` · Switches: ALLNET=`.11`, Omada=`. | Gerät | IP | Zugang | |---|---|---| | ALLNET Core-Switch (sw1) | 10.40.41.11 (interim, VLAN1) | `telnet 10.40.41.11` · User: `claudecode` · PW: `switch/.secrets` | -| Omada Access-Switch (sw2) | 10.40.41.12 (zuletzt bekannt, nicht neu verifiziert) | Web-UI HTTPS, **standalone ohne Controller** (TP2.1 ✅ 2026-07-16, User hat Recovery nach Werks-Reset komplett selbst gemacht) · Creds `omada/.secrets` (ggf. neu nach Reset, ungeprüft) | +| Omada Access-Switch (sw2) | **10.40.41.181** (post-TP2.1-Reset, VLAN1 — Korrektur 2026-07-16, alte `.12` war stale) | Web-UI HTTPS, **standalone ohne Controller** (TP2.1 ✅ 2026-07-16, User hat Recovery nach Werks-Reset komplett selbst gemacht) · Creds `sw2/.secrets` (löst `omada/.secrets` ab, dort als obsolet markiert) | | hAP ax² #1 (ap1) | 10.40.41.1 (bridge/VLAN1 Mgmt) | MikroMCP (live) · **TP4 ✅: L3-Router, GW je VLAN = .1** | | hAP ax² #2 (ap2) | 10.40.41.2 | MikroMCP (live) · **Port 2 am Omada-Switch** | | NAS (nas-bf, DS923) | 10.40.41.10 | SSH · Docker (Portainer endpointId=14) | diff --git a/docs/ip-plan.md b/docs/ip-plan.md index 045e563..9e77fbf 100644 --- a/docs/ip-plan.md +++ b/docs/ip-plan.md @@ -21,7 +21,7 @@ | ap1 (Router/hAP) | 10.40.41.1 | Router/GW | alle (.1) + Mgmt | bleibt `.1` je VLAN; Mgmt `10.40.99.1` | ⬜ | ist GW, kein „Umzug" | | ap2 (hAP) | 10.40.41.2 | AP | 99 MGMT | `10.40.99.2` | ⬜ | | | sw1 ALLNET (Core) | 10.40.41.11 | Switch-Mgmt | 99 MGMT | `10.40.99.11` | ⬜ | Mgmt-VLAN-Wechsel = Lockout-Risiko, sorgsam | -| sw2 Omada (ES208G) | 10.40.41.12 | Switch-Mgmt | 99 MGMT | `10.40.99.12` | ⬜ | | +| sw2 Omada (ES208G) | **10.40.41.181** (post-TP2.1-Reset, Korrektur 2026-07-16 — alte `.12` war stale) | Switch-Mgmt | 99 MGMT | `10.40.99.12` | ⬜ | | | NAS nas-bf (DS923) | ~~10.40.41.10~~ | INFRA | 20 INFRA | `10.40.20.10` | ✅ **live** | TP14.1 2026-07-10; DNS `nas.bf.lan` nachgezogen 2026-07-16 | | ~~Omada-Controller~~ | — | Service (macvlan/DS923) | — | — | ❌ **entfernt** | User hat den Container 2026-07-16 gelöscht (overkill für 1 Switch auf der Abschussliste, s. TP2.1/TP15). DNS-Eintrag `omada.bf.lan` entfernt | | ~~omada-mcp~~ | — | Service (pve-LXC) | — | — | ❌ **entfernt** | mit dem Controller zusammen gelöscht 2026-07-16 (MCP-Server verwaist, in Claude-Settings noch registriert — Aufräumen offen). DNS-Eintrag `omada-mcp.bf.lan` entfernt | diff --git a/docs/teilprojekte.md b/docs/teilprojekte.md index 5c51480..f4f9a08 100644 --- a/docs/teilprojekte.md +++ b/docs/teilprojekte.md @@ -27,6 +27,7 @@ Kontrolle: MikroMCP (MikroTik) live · ALLNET = Klickanleitungen · Omada → Co > 🎯 **Ziel: sauberes System „from scratch", keine Leichen/Altlasten.** Migrations-Session-Endstand = **VLAN1 + altes cudy-WLAN komplett weg** (VLAN1 nur noch Mgmt, `defconf`-Client-DHCP zurückgezogen, cudy-Uplinks aufs Ziel-Client-VLAN getaggt oder cudy abgebaut). **Unterpunkte/Aufräum-Liste bei Migration:** (a) die Interim-Härtung ap2 `wifi1/wifi2 frame-types=admit-only-vlan-tagged` (TP3.1, 2026-07-06) bleibt gültig — verschwindet automatisch mit VLAN1; (b) `st-main rrm/wnm` = reines Roaming-Provisorium, prüfen ob nach Migration noch nötig; (c) **cudy1 = verbleibender aktiver VLAN1-Leak** (Dual-DHCP-Race, Doku Memory `project_vlan1_dhcp_incident`). Bis dahin sind diese Griffe Krücken, kein Zielzustand. > ⚠️ **HW-Constraint hAP ax²:** 1 GB RAM, aber nur **128 MB Flash + KEIN USB** → **Container auf dem Router NICHT praktikabel**. > Folge: **native RouterOS-Features bevorzugen** (z.B. Built-in-mDNS statt Container); Container (mDNS-Reflector, BIND9-DNS, Omada-Controller) laufen auf **NAS/pve**, nicht am hAP. +> 🔒 **Governance-Entscheid (User, 2026-07-16, ausgeweitet 2026-07-16): Config ausschließlich über Nautobot — keine Direkt-Changes mehr an einzelnen im Netz verstreuten Geräten.** Ursprünglich als ap1/ap2-Config-Freeze bis TP21 formuliert, noch am selben Tag verallgemeinert: **jede** Netz-Gerätekonfiguration (Router, APs, künftig auch die CRS326-Switches) läuft ab jetzt exklusiv über Nautobot Golden Config (TP21), sobald das steht — keine ad-hoc MikroMCP-Writes/UI-Klicks mehr an Einzelgeräten. **TP19.1 war die letzte Ausnahme** (ap1-DNS-Fix + ap2/sw1/sw2-Mgmt-VLAN-Umzug, s.u.) — davon ist nur der risikolose ap1-Teil noch direkt gemacht worden, ap2 wurde bewusst auf „nach Nautobot" vertagt. **Macht Nautobot + alle Prerequisites (TP18→TP20→TP20.1→TP21, jetzt auch Komodo) zum aktuell kritischen Pfad**, vor TP5/TP6. Betrifft nicht Software-Migrationen auf NAS/pve (anderes Substrat) und die Frage, ob sw1/sw2 vor der CRS326-Ablösung noch angefasst werden (offen, s. TP15/TP19.1). --- @@ -336,7 +337,8 @@ FT kaschierte das bisher als „Roaming" statt „schwache Abdeckung". ### TP14.5 — Session E: Freigabe-Gate → TP5-Firewall ▸ 🔜 (ZULETZT) - Erst wenn TP14.1–14.3 durch (alle Origins/Connectoren in VLAN20) → dann TP5 (Deny-by-default) starten. Reines Reihenfolge-Gate, kein eigener Change. -### TP15 — HW-Refresh: Switching + Router + DC-USV ▸ 🟡 ENTSCHIEDEN, Beschaffung läuft (2026-07-14, WLAN-Punkt korrigiert 2026-07-15) — `docs/hw-refresh-requirements.md`, Memory `project_mikrotik_commit_nautobot_gc` +### TP15 — HW-Refresh: Switching + Router + DC-USV ▸ 🟡 Beschaffung läuft, **Lieferung 2026-07-17 (morgen)** — `docs/hw-refresh-requirements.md`, Memory `project_mikrotik_commit_nautobot_gc` +- 📦 **2× CRS326-24G-2S+RM werden morgen (2026-07-17) geliefert.** Sequenzierung ggü. Nautobot (TP21, noch Wochen entfernt: TP18→TP20→TP20.1→TP21 + jetzt Komodo-Abh.) **noch zu klären** — Governance-Regel „Config exklusiv über Nautobot" (s. oben) steht in Spannung zu „Config vorab machen" (User-Wunsch 2026-07-16): offen ist, ob (a) nur Config-as-Code/Intended-Config **vorbereitet** wird (Hardware bleibt bis Nautobot steht ungenutzt/eingelagert), oder (b) die Switches zeitnah klassisch von Hand eingebaut werden (verstößt gegen die frische Regel, Nautobot importiert später den Ist-Stand), oder (c) alles wartet bis Nautobot steht. Ebenfalls offen: lohnt sich der TP19.1-sw1/sw2-VLAN99-Umzug noch, wenn die CRS326-Ablösung so nah ist? - **🧭 Grundsatzentscheid (2026-07-14, korrigiert 2026-07-15): reines MikroTik-Ecosystem — Routing + Switching + WLAN.** **Omada bekommt KEINE Rolle** (weder Switching noch WLAN — der ursprüngliche „Omada=WLAN"-Satz war ein Fehlschluss beim Dokumentieren, User-Korrektur 2026-07-15: „WLAN war NIE von Omada die Rede"). Begründung Switching: Projektziel #1 **CAKE** nur RouterOS/OpenWrt/OPNsense (Omada-Gateway kann kein CAKE) → Switching = MikroTik CRS. WLAN bleibt auf hAP ax²/CAPsMAN (kein EAP-Kauf), Coverage-Fix bleibt Platzierungsfrage (TP3.3). Verworfene Vollvarianten (Omada-only, MikroTik-only) samt Begründung + Ansible/Nautobot-Recherche → Memory. **Anlass der Korrektur:** Omada-Controller↔sw2-Link beim VLAN20-Umzug (TP14.1) zerbrochen, versehentlicher Werks-Reset bei Rettungsversuch, fehlerhafter Wiederherstellungsversuch → sw2 wird standalone neu eingerichtet, s. **TP2.1**. - **🛒 Switches: 2× CRS326-24G-2S+RM bestellt (2026-07-14 — CSS326-Fehlbestellung storniert → CRS).** 24×1G + 2×SFP+, lüfterlos, DC-input (USV-tauglich). Lösen ALLNET-Core (sw1) + Omada-ES208G (sw2, s. TP2.1 — Solo/Interim bis CRS-Tausch) + Cudy ab. - ✅ **CRS = RouterOS-fähig → in-model:** MikroMCP-Write + Nautobot Golden Config (TP21) managen auch die **Switches**, nicht nur den Router → config-as-code deckt den **ganzen Kabel-Fabric**. (SwOS-Boot bliebe als Fallback möglich, aber nicht genutzt.) @@ -384,7 +386,7 @@ FT kaschierte das bisher als „Roaming" statt „schwache Abdeckung". - ✅ **Recon durch (`mcp/shelly/discover.py`, read-only /shelly-Sweep):** 16 live, **alle Gen3/Gen4** (uniforme RPC-API `WiFi.SetConfig`, auth=off — kein Gen1-Sonderfall). 10 „offline" = **weihnachten_\*** (s1/s2/s3, saisonal ausgesteckt Juli) + s12/s14/s16/s18/s22/s23 (aus/DHCP-drift). ⚠️ **Inventar-Fix:** s6 (kueche_kuehlschrank, `.213`) MAC falsch erfasst (`0c:72:74:36:90:9e`) → real **`d0:cf:13:d8:18:fc`**. s24 hat gar keine MAC. - **Mechanismus je Gerät:** Gen2+ RPC `WiFi.SetConfig {sta:{ssid,pass,enable}}` → Reboot → landet `.30.x`. ⚠️ **Risiken:** falsches PSK → AP-Mode (physischer Reset); Gerät kurz offline; HA/ioBroker-Refs brechen bis re-pointed; WPA3-mixed ggf. zickig auf alter FW; ap1 2,4-GHz-Master `wifi2` `running:false` → Coverage v.a. via ap2 prüfen. - ✅ **Live-Abgleich 2026-07-11 (go-ready):** (a) `shelly-mcp` (`server.py`) fertig — discover/get/set_sta/verify/reservation_plan, PSK in `.env` gesetzt (noch nicht als MCP registriert, optional). (b) **Alle VLAN30-DHCP-Reservierungen liegen** (`.30.2xx`, Oktett erhalten, außerhalb Pool `.100–.200`); **s6-Reservierung `.30.213` MAC gefixt** (falsch `0C:72…9E` → real `D0:CF:13:D8:18:FC`). (c) **IOT-SSID live verifiziert:** ap1 `w2-iot` `running:true`, 8 Clients −26…−68 dBm (ap1-`wifi2`-„running:false" ist kosmetisch). (d) **Migration bereits ~5/26 durch:** s14/16/18/22/23 seit ~2,5 d stabil auf reservierten `.30.221/.223/.225/.202/.203` (+ `.30.204` unbekannt, evtl. s24) → **Pilot faktisch bestanden**. -- ✅ **HA-Cross-Check 2026-07-11 (alle IPv4-Geräte in HA):** Shellys deckungsgleich; **`.30.204` = Shelly „Bad/Spiegelschrank" (Plus RGBW PM, `14:33:5c:d8:2d:7c`) = vmtl. s24** → 6 statt 5 schon migriert. **Netzweite Aufstellung + VLAN1-Leerstand-Analyse** im Runbook: nach TP17 + pve-Host→VLAN20 + Christophs Endgeräte→VLAN10 ist VLAN1 **endgeräte-frei**; es bleiben nur Switch-/AP-Mgmt (sw1/sw2/ap2 → VLAN99-Cutover, eigener Schritt) + **1 unidentifiziertes Gerät `.41.246`** (morgen klären). **Nicht-Shelly-VLAN30-Mover (User-bestätigt):** SwitchBot floor-lamp `.41.184` (Res. `.30.227` steht) + Twinkly-Girlande (`.30.228`, saisonal) + Creality Ender (fehlt noch, off). **Withings schon übersiedelt; Tasmota existiert nicht mehr** (kein aktives Gerät → stale HA-Eintrag). EOS-Smartwatches/eBook-Reader später + von Christoph selbst (eBook eher VLAN50). +- ✅ **HA-Cross-Check 2026-07-11 (alle IPv4-Geräte in HA):** Shellys deckungsgleich; **`.30.204` = Shelly „Bad/Spiegelschrank" (Plus RGBW PM, `14:33:5c:d8:2d:7c`) = vmtl. s24** → 6 statt 5 schon migriert. **Netzweite Aufstellung + VLAN1-Leerstand-Analyse** im Runbook: nach TP17 + pve-Host→VLAN20 + Christophs Endgeräte→VLAN10 ist VLAN1 **endgeräte-frei**; es bleiben nur Switch-/AP-Mgmt (sw1/sw2/ap2 → VLAN99-Cutover, eigener Schritt) + **1 unidentifiziertes Gerät `.41.246`** (morgen klären). **Nicht-Shelly-VLAN30-Mover (User-bestätigt):** ✅ SwitchBot floor-lamp `.41.184` + ✅ Twinkly-Girlande `.30.228` (beide 2026-07-16 übersiedelt, s. TP19) + Creality Ender (fehlt noch, off). **Withings schon übersiedelt; Tasmota existiert nicht mehr** (kein aktives Gerät → stale HA-Eintrag). EOS-Smartwatches/eBook-Reader später + von Christoph selbst (eBook eher VLAN50). - **Scope-Erweiterung (User 2026-07-11):** je Gerät **3 Änderungen** — WLAN→`dirtyvader-iot` + IP (`.41.2xx`→`.30.2xx`) **+ einheitliches Geräte-Passwort** (`Shelly.SetAuth`, User `admin`, realm-individueller ha1 → Tool `set_auth` in `server.py` nachrüsten). **PW entschieden: eigenes Shelly-Admin-PW** (getrennt vom WLAN-PSK) → `SHELLY_DEVICE_PW` in `.env` (Christoph liefert Wert). **HA-Entities unverändert** (keyt per MAC). **HA-Entities bleiben unverändert** (HA keyt per MAC). **Projektion TP17.1 (experimentell, nachrangig):** Gen4 (~11 St.) auf **Thread/Matter** flashen (Firmware-Verfügbarkeit + Thread-Border-Router offen) — Konflikt mit „Entities unverändert" (Matter = neue Entities) → erst WiFi-Migration stabilisieren. - ✅ **Reservierungs-/Pool-Konvention (User 2026-07-11):** alle Shellys bekommen **statische IP** (`10.40.30.`, gw/dns `.30.1`) **+ in-pool DHCP-Reservierung** als Backup. `pool-v30` auf `.100-.250` erweitert (Reservierungen jetzt in-pool); `set_sta` auf `static=true` umgestellt; s24-Inventar + `.30.204`-Reservierung angelegt. **Vollständiger HA-MAC-Scan:** 2 verpasste Media-Geräte **Apple TV 4K + Philips TV** (aus, → VLAN40) — **vor cudy-Abschuss** VLAN verifizieren; **Apple TV = vmtl. Thread-Border-Router** (TP17.1). **`.41.246/.247 = cudy1/cudy2`** (Teardown-Ziele). Tasmota bestätigt tot. - **Offene Schritte (morgen, „nur noch go", Runbook `docs/tp17-shelly-go-runbook.md`):** die **16 verbliebenen VLAN1-Shellys** (s4–s11, s13, s15, s17, s19–s21, s25, s26 auf `10.40.41.2xx`) per `WiFi.SetConfig`→`dirtyvader-iot` umklemmen (Batch, je Gerät `.30.x` verifizieren) → Geräte-PW setzen → HA/ioBroker-Re-Point → SwitchBot/Tasmota/3. Nicht-Shelly → saisonale s1/s2/s3/s12 beim nächsten Einstecken → cudy-Alt-WLAN abbauen → DNS/Inventar/`ip-plan` nachziehen. @@ -422,20 +424,24 @@ FT kaschierte das bisher als „Roaming" statt „schwache Abdeckung". - **Verlorene Shelly — IDENTIFIZIERT via HA 2026-07-13** (User-Hinweis „du siehst ihn im HA"): HA-Device `shellyplugsg3-e4b063e41ab8`, **Modell = Shelly Plug S Gen3**, **MAC `e4:b0:63:e4:1a:b8`**, HA-device_id `7a21e8f3349e6660f8b35974fc989a7b`. **NICHT im 26er-Inventar** (Spare/Küchen-Steckdose, die Christoph beim Einrichten verbockt hat; er nannte sie „küche s20", aber s20=`98:a3:16:7c:5f:ec` läuft sauber auf `.30.206` — Verwechslung). **KEIN AP-Mode, nicht tot:** assoziiert am **Altnetz `elektrosmog.c`** (cudy → untagged VLAN1-L2), aber mit **bogus-IP `10.95.10.206`** (Fremd-Subnetz, User-Fehler) → unrouting-bar, daher weder in VLAN1/30-Sweep noch normal per IP erreichbar, aber **per MAC in HA/WiFi-Table sichtbar**. Der `.219/s12`-Verdacht war Sackgasse (s12 nur saisonal aus). - **Update 2026-07-14: Shelly wieder da** (User-Meldung) — Live-Status (noch bogus-IP `10.95.10.206` oder inzwischen normal erreichbar?) **zu Sessionbeginn per HA/ARP verifizieren**; Recovery-Plan unten ggf. obsolet, falls sich das Gerät selbst erholt hat. - **Recovery-Plan (falls beim Verify noch nötig):** ap1 bekommt **temporäre Zweit-IP `10.95.10.1/24` auf der Bridge** → `10.95.10.206` per L2 erreichbar → **ein** `WiFi.SetConfig {sta: ssid=dirtyvader-iot, pass=IOT-PSK, static, ip=10.40.30.}` + `Shelly.Reboot` → Gerät kommt auf VLAN30 hoch → temp-IP entfernen. Danach `.30.x`-Reservierung + Inventar (MAC `e4:b0:63:e4:1a:b8`) + eco-Policy. Umgeht die „blutige Nase" (IP am Gerät ändern während man drauf hängt = Verbindungsverlust) — vom Router aus in einem Rutsch. Christophs manueller Direkt-Versuch (AP-IP auf 10.40.30 „verdrehen") war genau deshalb gescheitert. - - **SwitchBot floor-lamp** `.41.184` (`b8:f8:62:09:f2:04`, live auf VLAN1/cudy) → **VLAN30 via SwitchBot-App** (kein Local-WiFi-API, nur App/BLE-Provisioning), Res. `.30.227` liegt. = Christoph-App-Task. ⚠️ **Update 2026-07-14: KEIN Prereq mehr — funktioniert laut User erst NACH VLAN1-Retirement** → verschoben in die Teardown-Nachlese (s.u.), blockiert den cudy-Abschuss nicht mehr. + - ✅ **SwitchBot floor-lamp** `.41.184` (`b8:f8:62:09:f2:04`) → **erfolgreich auf VLAN30 übersiedelt (2026-07-16, Christoph via App/BLE)**, Res. `.30.227`. - **Prereqs-Status (live nachgezogen 2026-07-16, s. Live-Sweep oben):** 1. ✅ **Christophs Endgeräte → VLAN10/20 erledigt:** MacBook-Air (`c0:c7:db:de:71:be`, Claude-Sandbox-Client) hat aktive Leases nur noch auf `dhcp-v10`/`dhcp-v20`, keine `defconf`-Lease mehr. iPhone `.41.186` nicht im aktuellen Sweep erneut geprüft (zuletzt off/asleep) — kurz vor Cutover gegenchecken. 2. ✅ **2 unidentifizierte VLAN1-Geräte (`.41.133`/`.41.198`) aus dem ARP verschwunden** — kein aktueller Eintrag mehr, gelten als nicht mehr blockierend (entweder migriert oder abgeklungen). 3. ⏳ **Media → VLAN40 weiterhin offen:** Apple TV 4K + Philips TV nicht in diesem Sweep verifiziert. 4. ⏳ **Saisonale Shellys s1/s2/s3/s12 weiterhin offen** — nicht blockierend, kann übersprungen werden (Re-Onboarding-Aufwand akzeptiert). 5. ⏳ **pve-Interim-IP `.41.100` weiterhin aktiv/reachable** — Host-seitiger Cleanup auf pve selbst noch offen (nicht Router-Config). -- **Teardown-Sequenz (angepasst an den Live-Stand):** VLAN1-Client-Sweep ist **schon fast leer** (nur sw1-Mgmt + pve-Interim reachable) → `defconf`/pool-v1 ist **bereits disabled** → cudy-Abbau **entfällt** (cudy1 umgenutzt statt abgebaut, cudy2 tot) → **verbleibt:** SwitchBot floor-lamp via App/BLE auf VLAN30 (Res. `.30.227`), Media-Check (B1.3), pve-`.41.100` abräumen (B1.5), Interim-Krücken bewerten (ap2 `frame-types=admit-only-vlan-tagged`, `st-main rrm/wnm`), Inventar/`ip-plan`/DNS `.41→Ziel` final. +- **Teardown-Sequenz (angepasst an den Live-Stand):** VLAN1-Client-Sweep ist **schon fast leer** (nur sw1-Mgmt + pve-Interim reachable) → `defconf`/pool-v1 ist **bereits disabled** → cudy-Abbau **entfällt** (cudy1 umgenutzt statt abgebaut, cudy2 tot) → ✅ **SwitchBot + Twinkly erledigt (2026-07-16)** → **verbleibt:** Media-Check (B1.3), pve-`.41.100` abräumen (B1.5), Interim-Krücken bewerten (ap2 `frame-types=admit-only-vlan-tagged`, `st-main rrm/wnm`), Inventar/`ip-plan`/DNS `.41→Ziel` final. - Abh.: **TP14 ✅** (Hosts raus aus VLAN1), **TP17 ✅** (Shellys raus). Verwandt: `project_vlan1_dhcp_incident` (cudy-Dual-DHCP-Leak), TP5 (Deny-by-default danach sauberer). SSoT hier + `docs/tp19-vlan1-cudy-teardown-runbook.md`. Folge: **TP19.1**. -#### TP19.1 — VLAN99-MGMT-Cutover (sw1/sw2/ap2-Mgmt VLAN1 → VLAN99) ▸ 🔜 TODO (angelegt 2026-07-16, Unterpunkt von TP19) -- **Scope:** die einzigen Dinge, die TP19s Hauptteil bewusst in VLAN1 belässt — sw1 (`.41.11`), sw2 (`.41.12`), ap2-Mgmt (`.41.2`) — auf VLAN 99 (MGMT, `10.40.99.0/24`) umziehen. Erst danach ist VLAN1 wirklich **komplett** weg, nicht nur als Client-Netz. +#### TP19.1 — VLAN99-MGMT-Cutover (sw1/sw2/ap2-Mgmt VLAN1 → VLAN99) ▸ ⏳ ap1-Teil ✅, ap2 auf Nautobot vertagt, sw1/sw2 offen (Stand 2026-07-16) +- **Scope:** die einzigen Dinge, die TP19s Hauptteil bewusst in VLAN1 belässt — sw1 (`.41.11`), sw2 (`.41.181`), ap2-Mgmt (`.41.2`) — auf VLAN 99 (MGMT, `10.40.99.0/24`) umziehen. Erst danach ist VLAN1 wirklich **komplett** weg, nicht nur als Client-Netz. - **User-Entscheid (2026-07-16):** kein eigenständiges TP-Nummer — bewusst als **Unterpunkt von TP19** geführt („VLAN1 killen"), nicht als TP22 o.ä. -- **Bereits vorbereitet:** `docs/ip-plan.md` Phase 2 hat schon einen Entwurf (ap2→`10.40.99.2`, sw2→`10.40.99.12`, sw1→`10.40.99.11`, „Lockout-Risiko, sorgsam", sw1 zuletzt). ap1s DNS-Statics (`ap1.bf.lan`/`ap2.bf.lan`) tragen schon den Kommentar „update to `.99.x` after MGMT migration" (seit TP4). +- ✅ **ap1-Teil erledigt (2026-07-16):** ap1 brauchte keinen funktionalen Umzug (vlan99-Interface/GW `.99.1` läuft schon seit TP4) — nur der kosmetische DNS-Static-Nachtrag `ap1.bf.lan` `10.40.41.1`→`10.40.99.1` war offen, per MikroMCP erledigt (dry-run→apply, `manage_dns_entry`). +- 🔜 **ap2-Teil bewusst vertagt (User-Entscheid 2026-07-16): erst NACH Nautobot (TP21).** Nautobot übernimmt dann in einem Rutsch ap1 + ap2 + die neuen CRS326-Switches (TP15) als config-as-code-Fleet — der ap2-Mgmt-VLAN-Umzug wird also nicht mehr isoliert von Hand gemacht, sondern Teil der Nautobot-Erstadoption. `ap2.bf.lan`-DNS-Static bleibt bewusst auf `10.40.41.2` bis dahin. +- 🔒 **TP19.1 war die letzte Ausnahme vom ap1/ap2-Config-Freeze — der jetzt (2026-07-16) zur generellen Regel ausgeweitet wurde** (s. Governance-Entscheid oben): **jede** Gerätekonfiguration künftig ausschließlich über Nautobot, keine direkten Änderungen mehr an einzelnen im Netz verstreuten Geräten. Der ap1-DNS-Fix oben war die letzte direkte MikroMCP-Write-Aktion unter der alten (engeren) Regel. +- ⏳ **sw1/sw2-Teil: Status offen, hängt an der CRS326-Sequenzierung.** Klickanleitungen liegen fertig vor (`switch/ui-guides/02-vlan99-mgmt-cutover.md`, `sw2/ui-guides/01-vlan99-mgmt-cutover.md`), aber ob sie noch ausgeführt werden oder obsolet sind, hängt davon ab, wie TP15 (CRS326-Lieferung 2026-07-17) gehandhabt wird — s. TP15. +- **Bereits vorbereitet:** `docs/ip-plan.md` Phase 2 hat schon einen Entwurf (ap2→`10.40.99.2`, sw2→`10.40.99.12`, sw1→`10.40.99.11`, „Lockout-Risiko, sorgsam", sw1 zuletzt). - **Abh.:** TP19-Hauptteil (VLAN1-Client-Retirement) — logisch danach, da VLAN99 als eigenes Mgmt-Netz erst dann wirklich nötig wird, wenn VLAN1 sonst leer ist. sw1-Teil braucht sw1-Telnet-Zugriff (User macht sw1-Changes direkt, s. Feedback-Memory) — Lockout-Risiko am größten bei sw1 (einziger Netzpfad zu sw2 hängt am Uplink). ### TP20 — Platform-Datenbank (Postgres Precious-Tier + MariaDB Tier-2) ▸ 🔜 KONZEPT (2026-07-14) — Memory `project_mikrotik_commit_nautobot_gc` @@ -447,7 +453,8 @@ FT kaschierte das bisher als „Roaming" statt „schwache Abdeckung". - **Substrat:** Postgres in **LXC auf pve** (DB-Klasse, nicht Docker). - **Scope TP20 = Plattform:** Cluster hoch, Tiering, Backup/PITR, **Nautobot-DB** anlegen. **vw-Migration + Cross-Site-HA = TP20.1** (ausgelagert). - **Offene Sub-Steps:** pgBackRest-Bucket in Garage (Abh. TP18-Startpfad ①); PG-Version final (16 vs 17); Rollen/DB-Anlage Nautobot. -- Abh.: **TP18** (Garage-S3 für Backups — mind. BF-Node ①). **Blockt TP21 + TP20.1.** +- ⚠️ **Neue Abh. (User 2026-07-16): TP20 (Postgres-LXC) + weitere neue Softwarepakete sollen über Komodo deployt werden, nicht mehr direkt/Portainer.** Komodo hat aber aktuell **keine eigene TP-Nummer** — bislang nur als „Eigener Task" unter TP2 (Portainer-Ablösung, Zeile 72) und in CLAUDE.md-Tooling erwähnt. Noch zu klären: eigenes TP (z.B. TP22) heraustrennen, oder unter TP11 (Monitoring & Mgmt-Control-Plane) hängen? Bis geklärt: TP20 gilt als **an Komodo-Rollout gebunden**, nicht mehr eigenständig startbar. +- Abh.: **TP18** (Garage-S3 für Backups — mind. BF-Node ①), **Komodo-Rollout** (s.o., TP-Nummer offen). **Blockt TP21 + TP20.1.** #### TP20.1 — Vaultwarden → Platform-Postgres + Cross-Site-HA ▸ 🔜 KONZEPT (2026-07-14, ausgelagert aus TP20) - **Ziel:** `vw` (`.20.127`, heute MariaDB) auf den Precious-Tier holen **und** das eigentliche User-Ziel erfüllen: **DB-Replikation über 2 Sites** (Standort-Verlust überlebbar). @@ -475,6 +482,7 @@ FT kaschierte das bisher als „Roaming" statt „schwache Abdeckung". --- ## Reihenfolge / Abhängigkeiten +> 🎯 **AKTUELLER KRITISCHER PFAD (Stand 2026-07-16, überschreibt die Reihenfolge unten):** TP18 (Garage-S3, mind. BF-Node ①) → TP20 (Platform-Postgres, jetzt zusätzlich an Komodo-Rollout gebunden, TP-Nummer offen) → TP20.1 (Vaultwarden) ∥ TP21 (Nautobot Golden Config) → danach erst TP19.1-Rest (ap2/sw1/sw2) + TP5/TP6. Grund: Governance-Entscheid „Config exklusiv über Nautobot" (s. oben) macht Nautobot zur Voraussetzung für praktisch jede weitere Router-/Switch-Änderung. Die Punkte 3-4 unten (Omada-PVID-Fix etc.) sind **historisch/überholt** (Omada spielt seit TP15-Korrektur keine Rolle mehr) — ganze Liste braucht mal eine Aufräum-Session, hier nur der aktuelle Fokus vorangestellt. > ✅ **TP16 (CF-Tunnel Round-Robin/macvlan-Host-Isolation → reziprokes 3-Tunnel-HA)** KERN UMGESETZT 2026-07-10 (#1033 strukturell weg). Offen nur Access-Strang (WARP/`vw`) = user-gated. As-Built `docs/cf-tunnel-mapping.md §10`. 1. ~~**TP1 (GE8) → TP2 (Omada Controller).**~~ ✅ erledigt 2026-06-15. 2. ~~**TP4 (Router-Cutover L3-Infra + WAN-Edge).**~~ ✅ erledigt 2026-06-15 (L3) + 2026-07-01 (Edge-Cutover, FB physisch weg). diff --git a/sw2/ui-guides/01-vlan99-mgmt-cutover.md b/sw2/ui-guides/01-vlan99-mgmt-cutover.md new file mode 100644 index 0000000..76c9d12 --- /dev/null +++ b/sw2/ui-guides/01-vlan99-mgmt-cutover.md @@ -0,0 +1,80 @@ +# Omada ES208G (sw2, Standalone) — Web-UI-Guide: Management-VLAN 1 → 99 (TP19.1) + +> ⚠️ **Labels in diesem Dokument sind NICHT verifiziert.** Anders als beim ALLNET-Guide +> (`switch/ui-guides/02-vlan99-mgmt-cutover.md`, dort echte Scrape derselben Firmware) habe ich +> **keinen CLI/API-Zugriff auf sw2** und keine aktuelle Live-Ansicht seines Standalone-Web-UIs seit +> dem TP2.1-Reset. Was unten steht, ist die **typische** Menüstruktur von TP-Link-Easy-Smart/ +> Easy-Managed-Switches (System/Switching/VLAN/Monitoring/Maintenance) — Absicht + Zielwerte stimmen, +> **die genauen Seiten-/Feldnamen können abweichen**. Bitte nach jedem Klick kurz gegenprüfen, ob die +> Seite tut, was der Schritt beabsichtigt — nicht blind Feld für Feld folgen. Bei Unklarheit lieber +> stoppen und mir beschreiben/screenshotten, was tatsächlich da ist, statt zu raten. (Hintergrund: die +> vorige sw2-Session hat genau an einer zu selbstsicheren Config-Rekonstruktion gehangen — s. Memory +> `feedback_hw_config_trust_after_incident`. Diesmal lieber zu vorsichtig als zu forsch.) + +## Was wir wollen (Absicht in einem Satz) +sw2s eigene Management-Adresse von `10.40.41.181` (VLAN1, aktueller Live-Stand seit dem TP2.1-Reset, +s. `sw2/.secrets`) auf **`10.40.99.12/24`, GW `10.40.99.1`, Management-VLAN 99** umstellen. + +## ⚠️ Bevor du klickst +- **Reihenfolge (`docs/ip-plan.md` Phase 2): ap2 zuerst, DANN sw2, dann sw1 zuletzt.** Wenn ap2 noch + nicht auf VLAN99 ist, lieber damit anfangen — sw2 hängt zwar nicht direkt an ap2s Erreichbarkeit, + aber die Reihenfolge minimiert, wie viele Dinge gleichzeitig "in Bewegung" sind. +- **Kein Controller mehr im Spiel** (TP2.1) → **kein Adopt/Re-Adopt-Rollback-Pfad**, falls etwas + schiefgeht. Der einzige Fallback ist lokal am Gerät. +- **Vor-Check zuerst, nicht überspringen:** existiert VLAN 99 überhaupt schon in sw2s VLAN-DB (nach dem + Werks-Reset + Solo-Recovery)? Und trägt **Port 1** (Uplink → ALLNET sw1 GE8) sowie **Port 2** (→ ap2) + VLAN 99 **tagged**? Beide sind laut CLAUDE.md als "Trunk-ALL" konfiguriert, sollten es also haben — + aber das war TP2.1s Solo-Recovery, hier nicht ungeprüft von TP1/TP2 übernehmen. Wenn eins von beiden + fehlt: **hier abbrechen**, erst die VLAN-Membership nachziehen (analog `docs/tp2.1-omada-switch- + standalone-runbook.md` Schritt 2-3), dann erst die Mgmt-Adresse anfassen. +- **Prüfen, ob dieses Gerät ein "Save"/"Apply"-Konzept mit getrenntem Persistenz-Schritt hat** (viele + Easy-Smart-Switches wenden Änderungen sofort UND dauerhaft an, ohne Zwischenschritt — anders als beim + ALLNET-Switch gibt es hier möglicherweise **kein** "ändern-aber-nicht-speichern"-Sicherheitsnetz). + Falls du im Menü einen expliziten "Save Config"/"Apply"-Schritt siehst: wie beim ALLNET-Guide **nicht + sofort speichern**, erst auf der neuen IP verifizieren. Falls alles sofort permanent wird: dann ist die + neue IP sofort scharf — sei entsprechend vorsichtig beim Eintippen der Werte. + +## Klickpfad (Struktur typisch für Easy-Smart/Easy-Managed-UI — bitte gegenprüfen) + +### 0) Login & Vorprüfung +1. Browser → **https://10.40.41.181** (oder `http://`, falls https nicht angeboten wird) → Login + `admin` (PW in `sw2/.secrets`, dort noch von dir einzutragen falls leer). +2. Menü **VLAN** (evtl. Unterpunkt "802.1Q VLAN") → prüfen: VLAN 99 vorhanden? Falls eigene Namen + vergeben wurden (MAIN/INFRA/…/MGMT analog ALLNET) sollte 99 = "MGMT" heißen. +3. Dort (oder unter einem "Port"/"Membership"-Unterpunkt) prüfen: Port 1 + Port 2 = Tagged Member von + VLAN 99. +4. Falls beides passt → weiter zu Schritt 1. Falls nicht → hier abbrechen (s.o.). + +### 1) IP-Adresse + Management-VLAN — vermutlich unter `System → IP Setting` oder `System → Network` +1. Menü **System** suchen, darin nach IP-bezogenen Einträgen. +2. Felder (Namen können abweichen, Absicht zählt): + - **IP-Adresse** = `10.40.99.12` + - **Subnetzmaske** = `255.255.255.0` + - **Gateway** = `10.40.99.1` + - Modus: **Static** (nicht DHCP) + - Falls ein separates Feld **"Management VLAN"** oder **"VLAN ID"** existiert: `99` eintragen. + - **Falls es KEIN separates Management-VLAN-Feld gibt:** dann bestimmt bei diesem Gerät vermutlich + die **PVID des Ports, über den du gerade zugreifst** (oder eine switch-globale VLAN-Zuordnung), + welches VLAN die Mgmt-IP bedient — in dem Fall bitte **stoppen und mir Bescheid geben**, bevor du + weitermachst. Das ist ein Gerätekonzept, das ich vorher nicht zuverlässig kenne, und falsch geraten + hier ist genau das Muster vom letzten Incident. +3. Übernehmen/Apply. +4. **Ab hier ist deine aktuelle Session zur `.41.181`-Adresse vermutlich tot** (erwartet, kein Fehler). + +### 2) Reconnect & Verifikation +1. Neuer Tab → **https://10.40.99.12**. +2. Erreichbar + Login geht? → weiter (ggf. Save, falls es diesen Schritt gibt, s.o.). +3. **Nicht erreichbar?** Kein Save-Schritt bekannt heißt: Änderung ist wahrscheinlich schon dauerhaft + → **Power-Cycle bringt hier vermutlich KEIN automatisches Rollback** (anders als beim ALLNET-Switch). + Fallback dann: physischer Zugriff, Reset-Taste (**Werksreset, komplette Config weg** — TP2.1 müsste + nochmal gemacht werden). Bevor du das auslöst: kurz Ping/ARP von einem VLAN10/20-Host aus probieren + (`10.40.99.12`, `10.40.41.181`) — vielleicht ist nur der Browser-Cache/DNS das Problem, nicht der Switch. + +## Verifikation (nach erfolgreichem Wechsel) +- `https://10.40.99.12` erreichbar, ap2-Mgmt weiterhin erreichbar (falls schon auf VLAN99). +- `sw2/.secrets` `SW2_HOST` auf `10.40.99.12` aktualisieren. +- `docs/ip-plan.md` Zeile sw2 bestätigen, `CLAUDE.md`-Hardwaretabelle nachziehen. + +## Nachziehen (nach erfolgreichem Cutover, alle drei TP19.1-Kandidaten durch) +- `docs/teilprojekte.md` TP19.1 auf ✅ setzen. +- Governance-Hinweis: TP19.1 ist die letzte Ausnahme vom ap1/ap2-Config-Freeze bis TP21 (Nautobot) steht. diff --git a/switch/ui-guides/02-vlan99-mgmt-cutover.md b/switch/ui-guides/02-vlan99-mgmt-cutover.md new file mode 100644 index 0000000..0d6a772 --- /dev/null +++ b/switch/ui-guides/02-vlan99-mgmt-cutover.md @@ -0,0 +1,94 @@ +# ALLNET ALL-SG8316M (sw1) — Web-UI-Guide: Management-VLAN 1 → 99 (TP19.1) + +> **Methode:** Claude erklärt Absicht + Klickpfad, **du klickst**. UI = Realtek-OEM (Backbone-SPA), +> FW 2.2.1.2956, erreichbar unter **https://10.40.41.11** (Login `claudecode`, PW in `switch/.secrets`). +> Die VLAN-Menü-Labels unten (`VLAN → Port Setting`, `VLAN → Membership`) sind aus einer echten Scrape +> auf **genau dieser Firmware** (`switch/ui-guides/01-trunk-ap-ports.md`, 2026-06-09) — sollten exakt passen. +> Die **System/IP/Management-VLAN-Labels sind NICHT live gescraped** (nur aus der alten FW1.0-CGI-Map +> abgeleitet, `switch/sg8316m-cgi-map.md`) — Seitentitel können abweichen, die **Absicht** steht bei +> jedem Schritt dabei, danach suchen. + +## Was wir wollen (Absicht in einem Satz) +sw1s eigene Management-Adresse von `10.40.41.11` (VLAN1, interim) auf **`10.40.99.11/24`, GW `10.40.99.1`, +Management-VLAN `99`** umstellen — der letzte von drei TP19.1-Kandidaten (nach ap2, vor... eigentlich +**zuletzt**, s. Reihenfolge unten). VLAN 99 (MGMT) existiert bereits in der VLAN-DB (Name "MGMT" gesetzt), +und alle Trunk-Ports (GE1/GE2/GE8 + der ap1-Uplink) tragen VLAN 99 bereits **tagged** (TP1 ✅) — es muss +**keine VLAN- oder Port-Config** geändert werden, nur die switch-eigene Mgmt-Bindung. + +## ⚠️ Bevor du klickst +- **Reihenfolge (aus `docs/ip-plan.md` Phase 2): ap2 zuerst, dann sw2, dann sw1 zuletzt** — sw1 ist das + risikoreichste Gerät (einziger Netzpfad zu sw2 hängt am sw1-Uplink; wird sw1 unerreichbar, ist auch + sw2 nicht mehr über den Uplink diagnostizierbar). Wenn ap2/sw2 noch nicht durch sind: die hier lieber + nicht vorziehen. +- **Telnet-CLI ist aktuell kaputt** (`claudecode`-Login wird deterministisch abgelehnt, s. Memory + `project_tp19_vlan1_status_20260716`) — d.h. **kein CLI-Fallback**, falls die Web-UI nach dem Schritt + hängt. Das Web-UI-Login selbst ist unabhängig davon (anderer Login-Pfad) — trotzdem als Schritt 0 zuerst + verifizieren, nicht blind loslegen. +- **Die eingebaute Sicherheitsnetz-Mechanik dieses Geräts: Änderungen wirken erst nach explizitem `save` + in Flash.** Solange du **nicht speicherst**, überlebt die Änderung keinen Reboot/Stromausfall — das ist + hier bewusst der Rollback-Pfad (s. unten). **Also: NICHT sofort speichern, erst verifizieren.** +- Kein bekannter Seriell-/Konsolen-Zugang an diesem Gerät. Physische Reset-Taste = **Werksreset** (komplette + Config weg, alle VLANs/Trunks/Namen neu von den `.cli`-Skripten aufbauen) — nur allerletzter Ausweg. + +## CLI-Äquivalent (nur zum Gegenchecken/für später, falls Telnet wieder geht) +``` +configure +ip address 10.40.99.11 mask 255.255.255.0 +ip default-gateway 10.40.99.1 +management-vlan vlan 99 +end +# NICHT sofort: +save +``` +(Quelle: `switch/cli/CLI-REFERENCE.md`.) + +## Klickpfad + +### 0) Login & Vorprüfung +1. Browser → **https://10.40.41.11** → Login `claudecode` (PW `switch/.secrets`). +2. **VLAN → Membership**: prüfen, dass **VLAN 99** existiert und auf dem Port, der zu ap1 führt + (laut `routeros/wan-cutover-runbook.md` = **gi15**; falls die UI andere Portnummern zeigt, den Port + nehmen, der die meisten VLANs tagged trägt — das ist der AP-Uplink), als **Tagged (T)** gelistet ist. + Falls nicht: **hier abbrechen**, nicht weitermachen (Physical-Path fehlt sonst). + +### 1) IP-Adresse setzen — vermutlich `System → IP Setting` (Label ungescraped, s.o.) +1. Menü mit "IP"/"Network"/"System" suchen (nicht "VLAN"). +2. Felder: + - **IP-Adresse** = `10.40.99.11` + - **Subnetzmaske** = `255.255.255.0` + - **Default Gateway** = `10.40.99.1` + - Modus: **Static** (nicht DHCP) +3. **Noch NICHT Apply/Save drücken, wenn die Seite auch das Management-VLAN-Feld enthält** — erst + Schritt 2 mit auf derselben Seite ausfüllen (viele Realtek-OEM-UIs haben IP + Mgmt-VLAN auf einer + gemeinsamen Seite). Falls getrennte Seiten: Apply hier ist ok, weiter zu Schritt 2. + +### 2) Management-VLAN setzen — vermutlich gleiche Seite oder `System → Management VLAN` +1. Feld **Management VLAN / VLAN ID** = `99`. +2. **Jetzt Apply/Submit.** +3. **Ab hier ist deine aktuelle Browser-Session zur alten `.41.11`-Adresse tot** — das ist erwartet, + keine Störung. Der Switch beantwortet ab jetzt nur noch auf `10.40.99.11`. + +### 3) Reconnect & Verifikation (BEVOR gespeichert wird!) +1. Neuer Tab → **https://10.40.99.11** aufrufen. +2. Erreichbar + Login geht? → weiter zu Schritt 4 (Save). +3. **Nicht erreichbar nach ~1 Minute?** → **nicht weiter versuchen, nicht neu konfigurieren** — stattdessen + Switch stromlos machen und neu starten (Power-Cycle). Da **nicht gespeichert wurde**, bootet er mit der + alten Config (`10.40.41.11`, VLAN1) wieder hoch → zurück auf Los, ohne Schaden. Danach mir Bescheid + geben, bevor der nächste Versuch gestartet wird (ggf. stimmt eine Portzuordnung nicht). + +### 4) Speichern (erst wenn Schritt 3 erfolgreich war!) +- **System → Save Config** (oder Disketten-Symbol) → "Save to Flash". Ab jetzt übersteht die neue + Mgmt-Adresse einen Reboot. + +## Verifikation (nach Save) +- `https://10.40.99.11` weiterhin erreichbar. +- `switch/.secrets` `SW_HOST` auf `10.40.99.11` aktualisieren (für zukünftige Telnet-Versuche, falls + der Login-Blocker sich klärt). +- ap2 (sofern schon auf VLAN99 umgezogen) und sw2 weiterhin über VLAN99 erreichbar — kein Kollateralschaden + am gemeinsamen MGMT-Segment. +- `docs/ip-plan.md` Zeile sw1: `bestätigt` = ✅ setzen. `CLAUDE.md`-Hardwaretabelle nachziehen. + +## Nachziehen (nach erfolgreichem Cutover, alle drei TP19.1-Kandidaten durch) +- `docs/teilprojekte.md` TP19.1 auf ✅ setzen. +- Governance-Hinweis beachten: TP19.1 ist die **letzte Ausnahme** vom ap1/ap2-Config-Freeze bis TP21 + (Nautobot) steht — danach keine weiteren ad-hoc-Router-Changes mehr ohne Rücksprache.