diff --git a/docs/teilprojekte.md b/docs/teilprojekte.md index 7dc0d53..9e6340e 100644 --- a/docs/teilprojekte.md +++ b/docs/teilprojekte.md @@ -73,6 +73,13 @@ Kontrolle: MikroMCP (MikroTik) live · ALLNET = Klickanleitungen · Omada → Co - **→ TP4 wird vorgezogen:** Alle VLANs im Controller definiert (status=false = kein Management-IP, normal). Traffic läuft noch auf VLAN 1 bis TP4 die L3-Interfaces + DHCP-Server je VLAN aktiviert. +### TP2.1 — Omada-Switch (sw2/ES208G) → Standalone-Recovery (kein Controller) ▸ 🔜 AKTIV (2026-07-15) — `docs/tp2.1-omada-switch-standalone-runbook.md` +- **Root Cause:** beim VLAN20-Umzug des Omada-Controllers (TP14.1, 2026-07-10) ist die Controller↔sw2-Verbindung zerbrochen (sw2 seither „Disconnected", ursprünglich als reiner Mgmt-Loss vertagt). Beim Rettungsversuch hat der User versehentlich einen **Werks-Reset** am Switch ausgelöst. Ein anschließender Wiederherstellungsversuch (durch Claude) hat Teile der Config **unbemerkt halluziniert** — der damalige „wiederhergestellte" Stand ist **nicht vertrauenswürdig**. +- **Entscheidung (User 2026-07-15): Controller-Zustand als invalid betrachten, sw2 komplett neu — diesmal OHNE Managementsoftware.** Kein Omada-Controller-Re-Adopt, kein Omada-Ecosystem-Anschluss (s. TP15-Korrektur — Omada bekommt generell keine Rolle mehr, auch nicht WLAN). sw2 wird direkt über sein eigenes Web-UI/CLI konfiguriert, wie ein eigenständiger Switch. +- **sw2 bleibt Solo:** „bekommt nie Geschwister" — keine weiteren Omada-Geräte geplant. Interimslösung bis zur Ablösung durch CRS326 (TP15). +- **TP2 = Playbook**, nicht 1:1 übernehmen: gleicher VLAN-Bedarf (VLAN-Modell unverändert), aber **neue Portbelegung** wird gemeinsam mit User neu definiert (nicht ungeprüft aus der alten TP2-Tabelle übernommen) — offener nächster Schritt dieser Session. +- Abh.: TP1 ✅ (VLAN-Trunk am Uplink). Verwandt: TP15 (löst sw2 mittelfristig durch CRS326 ab), TP14.1 (Auslöser). + ### TP3 — WLAN / CAPsMAN ▸ ✅ KERN FERTIG (2026-06-18) — `routeros/tp3-capsman.rsc` - ✅ **5 sichtbare SSIDs live, beide APs, beide Bänder, je SSID→VLAN** (wifi datapath vlan-id): `dirtyvader-main`(10, WPA3-only, FT), `-iot`(30, **nur 2,4 GHz**, WPA2+3), `-media`(40, WPA2+3, **FT=no** wg. Sonos), @@ -321,17 +328,17 @@ 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 + WLAN-Ecosystem + DC-USV ▸ 🟡 ENTSCHIEDEN, Beschaffung läuft (2026-07-14) — `docs/hw-refresh-requirements.md`, Memory `project_mikrotik_commit_nautobot_gc` -- **🧭 Grundsatzentscheid (2026-07-14): Ecosystem-Split nach Layer.** **MikroTik = config-gemanagter Kern** (Routing/L3/CAKE + alle Switches), **Omada = ausschließlich WLAN**. Begründung: Projektziel #1 **CAKE** nur RouterOS/OpenWrt/OPNsense (Omada-Gateway kann kein CAKE); WLAN = Schmerzpunkt → Omada-EAP; Switching = MikroTik. Grenze **„MikroTik = Kabel+Routing, Omada = Funk"** deckt sich mit den 2 bestehenden Control-Planes (MikroMCP + Omada-Controller). Verworfene Vollvarianten (Omada-only, MikroTik-only) samt Begründung + Ansible/Nautobot-Recherche → Memory. -- **🛒 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 raus aus Switching-Rolle) + Cudy ab. +### 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` +- **🧭 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.) - - ⚠️ **kein PoE** → Omada-EAPs + Sonoff via **PoE-Injektoren**. -- **📶 WLAN → Omada EAPs** (ersetzt hAP-Funk + CAPsMAN): löst CAP-ARP/Broadcast-Quirks (P750W-Fall), reifes 802.11k/v/r-Roaming, VLAN→SSID im bereits laufenden Controller. hAP ax² werden Reserve. (Ersetzt die alte hAP-be³-Linie dieses Docs.) + - ⚠️ **kein PoE** (Sonoff/PoE-Verbraucher via Injektor, falls nötig). +- **📶 WLAN bleibt hAP ax²/CAPsMAN** — kein Hardware-/Ecosystem-Wechsel. Coverage-Schwachstellen (P750W-Fall, Terrasse/Kanten) bleiben Platzierungs-/Roaming-Thema von **TP3.3**, nicht durch neue Hardware gelöst. - **🧭 Router → RB5009 (mittelfristig):** L3/CAKE/Firewall vom hAP ax² lösen (device-mode=home blockt scheduler/fetch; „AP=Router"-Fragilität) → dedizierte RouterOS-Box, in MikroMCP + Nautobot. hAP ax² danach nur noch WLAN/Reserve. -- **🔋 DC-USV** (unverändert gültig): MeanWell LRS-150-48 + DDR-120-48 + LiFePO4 20Ah (~€190), 48V-Bus; CSS326 DC-input passt. -- **Offen:** PoE-Injektor-Auswahl (EAP-Wattage); RB5009-Beschaffung; EAP-Modell (WiFi6 EAP6xx vs WiFi7 EAP7xx); Standort-Zuordnung der 2 Switches (Diele/OG) nach TP19-VLAN1-Retirement. -- **Hinweis:** die A/B/C/D-Switch-Varianten in `hw-refresh-requirements.md` sind durch die CSS326-Beschaffung überholt (Doc = Recherche-Archiv + USV/Energie-Referenz). -- Abh.: TP14 ✅ (IP-Migration). Verzahnt: **TP20** (Platform-DB), **TP21** (Nautobot GC). +- **🔋 DC-USV** (unverändert gültig): MeanWell LRS-150-48 + DDR-120-48 + LiFePO4 20Ah (~€190), 48V-Bus; CRS326 DC-input passt. +- **Offen:** RB5009-Beschaffung; Standort-Zuordnung der 2 CRS326 (Diele/OG) nach TP19-VLAN1-Retirement; ob/wann sw2 durch einen 3. CRS326 abgelöst wird. +- **Hinweis:** die A/B/C/D-Switch-Varianten in `hw-refresh-requirements.md` sind durch die CRS326-Beschaffung überholt (Doc = Recherche-Archiv + USV/Energie-Referenz). +- Abh.: TP14 ✅ (IP-Migration). Verzahnt: **TP20** (Platform-DB), **TP21** (Nautobot GC), **TP2.1** (sw2-Standalone-Recovery). ### TP16 — CF-Tunnel: Round-Robin killen + reziprokes HA ▸ ✅ KERN UMGESETZT (2026-07-10) — `docs/cf-tunnel-mapping.md §10`, #1033 > **✅ Umgesetzt (2026-07-10, eigene Session):** reziprokes **3-Tunnel-HA** live (bf-nas `70d6a4cf` / bf-pve `f7fdf3a6` / bf-mm `7a322261`), 6 Connectoren (2/Host, je Fremdhost), 19 FQDNs Loop-Smoke **0×530**, HA per Host-Ausfall-Sim bewiesen. Round-Robin-#1033 **strukturell weg**. As-Built = `docs/cf-tunnel-mapping.md §10`. **Offen: Schritt 5 Access-Strang (`vw` bypass→geschützt via WARP, `hass`/`ha-mcp` 400/403 → iPhone-WARP-Enrollment) = user-gated; `gateway-dw` (WG→404) klären.** @@ -394,17 +401,18 @@ FT kaschierte das bisher als „Roaming" statt „schwache Abdeckung". ### TP19 — cudy-Teardown + VLAN1-Client-Retirement ▸ 🔜 AKTIV (nächste Priorität, User 2026-07-13) - **Ziel (Kapstein der Segmentierung, s. Zeile 27):** altes **cudy-WLAN weg** + **VLAN1 als Client-Netz stilllegen** (`defconf`/pool-v1-Client-DHCP zurückziehen). **Nicht** VLAN1 komplett: Switch-/AP-Mgmt (sw1 `.11`/sw2 `.12`/ap2 `.2`) bleiben **by design** in VLAN1 (statisch, kein DHCP nötig) bis zum separaten **MGMT-VLAN99-Cutover** (eigener TP). cudy1/cudy2 = `.41.246`/`.247` (Teardown-Ziele). -- 🎯 **User-Gate (2026-07-13): sobald die verlorene Shelly + SwitchBot laufen → VLAN1 + cudy-WLAN außer Betrieb.** Twinkly nebenher (saisonal). +- 🎯 **User-Gate (Update 2026-07-14): Shelly ist wieder da (kein Blocker mehr) — SwitchBot ist KEIN Prereq mehr, funktioniert laut User erst NACH VLAN1-Retirement (Reihenfolge ggü. 2026-07-13 umgedreht) → wandert in die Teardown-Nachlese.** TP19 damit direkt startbereit. Twinkly nebenher (saisonal). - **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). - - **Recovery-Plan (remote, für neue Session, NACH SwitchBot — User-Reihenfolge):** 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: 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. - ⚠️ **Prereqs — restliche VLAN1-Clients umziehen, SONST verwaisen sie beim cudy-Tod** (live ap1-ARP 2026-07-13): 1. **Christophs Endgeräte → VLAN10** (`dirtyvader-main`): MacBook-Air `.41.182` (`c0:c7:db:de:71:be` — **= Claude-Sandbox-Client!** vor cudy-Abschuss umhängen, sonst Zugangs-Verlust), iPhone `.41.186` (aktuell off/asleep). 2. **2 UNIDENTIFIZIERTE VLAN1-Geräte (2026-07-13):** `.41.133` (`02:11:32:22:1e:25`, lokal-administrierte/randomisierte MAC — Phone-Random? VM?) + `.41.198` (`34:2b:6e:6f:1f:ef`) → **vor Teardown identifizieren + verorten.** 3. **Media → VLAN40 verifizieren:** Apple TV 4K + Philips TV 50PUS7304 (beide **aus**) einschalten, prüfen VLAN40 vs cudy/VLAN1. ⚠️ **Apple TV = vmtl. Thread-Border-Router** der 22-Matter-Flotte → nicht sorglos stromlos (TP17.1). 4. **Saisonale Shellys s1/s2/s3/s12** (aus): nach cudy-Tod zeigt `sta` auf tote cudy-SSID → beim Einstecken AP-Mode statt Join. **Empfehlung: vor cudy-Abschuss** kurz einstecken + `migrate.py`, sonst AP-Onboarding später. 5. **pve-Interim-IP `.41.100`** (bewusst als Fallback belassen) beim Teardown mit abräumen. Streu-Reste final per ARP/DHCP-Sweep auf 0. -- **Teardown-Sequenz (nach Prereqs):** VLAN1-Client-Sweep = leer (nur Mgmt bleibt) → cudy1/cudy2 stromlos/Reset/ausbauen → ap1 `defconf`/pool-v1-Client-DHCP zurückziehen (VLAN1-Mgmt-Reachability für sw1/sw2/ap2 erhalten) → Interim-Krücken aufräumen (ap2 `frame-types=admit-only-vlan-tagged` = auto-weg mit VLAN1; `st-main rrm/wnm` Roaming-Provisorium neu bewerten) → Inventar/`ip-plan`/DNS `.41→Ziel` final. +- **Teardown-Sequenz (nach Prereqs):** VLAN1-Client-Sweep = leer (nur Mgmt bleibt) → cudy1/cudy2 stromlos/Reset/ausbauen → **SwitchBot floor-lamp via App/BLE auf VLAN30 provisionieren (jetzt erst möglich, Res. `.30.227`)** → ap1 `defconf`/pool-v1-Client-DHCP zurückziehen (VLAN1-Mgmt-Reachability für sw1/sw2/ap2 erhalten) → Interim-Krücken aufräumen (ap2 `frame-types=admit-only-vlan-tagged` = auto-weg mit VLAN1; `st-main rrm/wnm` Roaming-Provisorium neu bewerten) → 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), **VLAN99-MGMT-Cutover** (Folge-TP, entkoppelt), TP5 (Deny-by-default danach sauberer). SSoT hier + Runbook. ### TP20 — Platform-Datenbank (Postgres Precious-Tier + MariaDB Tier-2) ▸ 🔜 KONZEPT (2026-07-14) — Memory `project_mikrotik_commit_nautobot_gc` diff --git a/docs/tp2.1-omada-switch-standalone-runbook.md b/docs/tp2.1-omada-switch-standalone-runbook.md new file mode 100644 index 0000000..e36eea9 --- /dev/null +++ b/docs/tp2.1-omada-switch-standalone-runbook.md @@ -0,0 +1,143 @@ +# TP2.1 — Omada-Switch (sw2/ES208G) Standalone-Recovery — Runbook + +**Stand: 2026-07-15.** Steuerung/Scope: `docs/teilprojekte.md` → TP2.1 (Playbook-Referenz: TP2). +Für eine frische Session gedacht — kein Vorwissen aus der Vorgänger-Session vorausgesetzt. + +--- + +## TL;DR +sw2 (TP-Link Omada ES208G) ist faktisch **jungfräulich** (Werks-Reset). Er wird **diesmal ohne +Omada-Controller/Managementsoftware** direkt über sein eigenes lokales Web-UI eingerichtet — +Omada bekommt in diesem Netz generell keine Rolle mehr (auch nicht WLAN, s. TP15-Korrektur). +sw2 bleibt Solo (keine weiteren Omada-Geräte) und ist ohnehin nur Interim bis zur CRS326-Ablösung (TP15). +**Vor jeder Config-Änderung:** Portbelegung mit Christoph gemeinsam finalisieren (Draft unten) — +das war der letzte offene Punkt der Vorgänger-Session. + +--- + +## Root Cause (kurz, für Kontext — nicht Teil der Ausführung) +Beim VLAN20-Umzug des Omada-Controllers (TP14.1, 2026-07-10) ist die Controller↔sw2-Verbindung +zerbrochen (sw2 seither "Disconnected" im Controller). Beim Rettungsversuch hat der User versehentlich +einen **Werks-Reset** am Switch ausgelöst. Ein anschließender Wiederherstellungsversuch durch Claude +hat Teile der Config **unbemerkt halluziniert** — der damalige "wiederhergestellte" Stand ist nicht +vertrauenswürdig. Christoph hat 2026-07-15 entschieden: **Controller-Zustand = invalid**, sw2 wird +sauber neu aufgesetzt, diesmal **ohne** Controller/Managementsoftware-Abhängigkeit. + +--- + +## Zugang + +- **Modell:** TP-Link Omada ES208G ("Easy Managed" Tier — Basis-VLAN/QoS lokal möglich, kein CLI + bekannt, nur Web-UI, im Gegensatz zu ALLNET/sw1 das Telnet-CLI hat). +- **Bekannte MAC (verifiziert via ap1-ARP, TP17-Runbook 2026-07-11):** `a8:29:48:ee:b9:04` — nutzen, + um den Switch nach dem Reset wiederzufinden, egal welche IP er gerade trägt. +- **Letzte bekannte statische IP (vor Adoption):** `10.40.41.12` (VLAN1). +- **Standalone-Creds (vor Controller-Adoption, aus `omada/.secrets`, gitignored):** + `OMADA_USER=admin`, `OMADA_PASS=` siehe `omada/.secrets` im Repo-Root. **Nach Werks-Reset vermutlich + ungültig** (Reset setzt i.d.R. auch Login auf Default zurück — TP-Link-Standard meist `admin`/`admin` + bei Erstzugriff, Passwort-Setup-Wizard beim ersten Login). Verifizieren, nicht blind annehmen. +- **Omada-Controller-UI** (`https://10.40.20.175:8043`) wird für diese Aufgabe **nicht** mehr gebraucht + — Login-Problem dort ist damit ohnehin gegenstandslos (Controller-Pfad wird verlassen). + +## Schritt 0 — Switch nach dem Reset finden + +TP-Link Easy-Smart/Omada-Switches fallen nach Werks-Reset typischerweise auf DHCP-Client zurück +(mit Fallback auf eine statische Default-IP, falls kein DHCP antwortet — Gerätehandbuch/Label am +Switch prüfen, meist `192.168.0.1`). Da VLAN1-DHCP (`defconf`/pool-v1) auf ap1 noch aktiv ist +(TP19 hat VLAN1 noch nicht abgeschaltet) und der Uplink-Port (sw1 GE8 → sw2 Port1, vermutlich +weiterhin Trunk mit VLAN1 native/untagged) das durchreicht, ist eine frische DHCP-Lease der +wahrscheinlichste Fall: + +1. **Per MAC suchen:** `mikromcp list_dhcp_leases` (ap1) nach `a8:29:48:ee:b9:04` filtern → liefert + die aktuell vergebene IP. Alternativ `list_arp_entries`/`list_neighbors` auf ap1. +2. **Falls keine Lease sichtbar:** Switch braucht ggf. direkten Trunk-/Access-Pfad zum DHCP-Server + (VLAN1 muss durchgängig sein von sw2 bis ap1) — sonst Fallback auf TP-Link **SDM/Discovery- + Utility** (Broadcast-basiert, L2-only, braucht einen Rechner im selben Segment) oder physische + Default-IP `192.168.0.1` (Laptop temporär auf `192.168.0.x` setzen, direkt an einen freien + Switch-Port). +3. **Erstlogin:** Browser → `http://` (TP-Link Easy-Smart-Switches sind oft nur HTTP, + nicht HTTPS wie der ES208G-Controller-Pfad — beides probieren). Login-Screen prüfen: Default-Creds + oder Passwort-Setup-Assistent? +4. **Firmware-Stand notieren** (Werks-Reset ändert die Firmware nicht, nur die Config). + +## Schritt 1 — Portbelegung gemeinsam finalisieren (BLOCKIEREND, zuerst!) + +**Das war der letzte offene Punkt der Vorgänger-Session — nicht ungeprüft übernehmen.** Draft unten +basiert auf der TP2-Tabelle (2026-06-15) + bekannten Änderungen seither (Mac mini/NAS jetzt mit +VLAN20-IPs). Vor jeder Port-Config-Änderung mit Christoph durchgehen: + +| Port | Alt-Rolle (TP2, 2026-06-15) | Alt-Profil | Vermutlich noch aktuell? | +|---|---|---|---| +| 1 | uplink → ALLNET GE8 | Trunk-ALL | ja, kritisch (einziger Netz-Pfad zu sw2) | +| 2 | ap2 (hAP ax² #2) | Trunk-ALL | ja, kritisch (TP3.1 braucht 10/30/40/50/90 tagged + VLAN1 untagged) | +| 3 | frei | Access-MAIN | zu bestätigen | +| 4 | dock/monitor (Docking-Station) | Access-MAIN | **"Lifeline-Port" laut TP2 — zu bestätigen, ob noch live** | +| 5 | drucker | Access-MAIN | zu bestätigen | +| 6 | frei | Access-MAIN | zu bestätigen | +| 7 | macmini | Access-INFRA (→ VLAN20 heute) | Mac mini hat jetzt `.20.167` — falls noch hier eingesteckt, Profil bleibt sinngemäß gleich | +| 8 | ds923+ (NAS, 2. Port) | Access-MAIN | **"nicht anfassen" laut TP2 — zu bestätigen, ob noch live** | + +**Offene Fragen an Christoph, bevor Port 3-8 angefasst werden:** +- Hängt an jedem Port noch das, was TP2 sagt, oder hat sich seither was am Verkabelungsplan geändert? +- Soll die Portbelegung 1:1 aus TP2 übernommen werden, oder gibt es neue Geräte/Bedarf? +- Bleiben Port 4 (Docking-Station) und Port 8 (NAS) "nicht anfassen"-Ports, oder dürfen die jetzt + sauber neu durchkonfiguriert werden (kein Controller mehr im Weg)? + +**Kein Portstatus wird geändert, bevor diese Tabelle final ist.** + +## Schritt 2 — VLAN-Datenbank anlegen + +VLAN-Modell ist unverändert (kanonisch, s. `CLAUDE.md`): 10/20/30/40/50/90/99/100 (+ VLAN1 als +Mgmt/Legacy bis TP19 abgeschlossen). Analog zum ALLNET-Vorgehen (`switch/ui-guides/01-trunk-ap-ports.md`): + +1. Im Switch-Web-UI: VLAN-Sektion → alle 8 VLANs anlegen (IDs, optional Namen wie am Controller + vorher: MAIN/INFRA/IOT/MEDIA/UNTRUSTED/GUEST/MGMT/WAN — WAN(100) vermutlich nicht relevant an + diesem Access-Switch, prüfen ob er ihn überhaupt braucht). +2. **VLAN1 bleibt überall untagged/native** bis TP19 den VLAN1-Rückbau macht — kein Lockout-Risiko + eingehen (siehe ALLNET-Gotcha: "mgmt-VLAN-Wechsel = Lockout-Risiko, VLAN muss existieren + Port + muss es tragen, in einem Schritt"). + +## Schritt 3 — Ports nach finalisierter Tabelle konfigurieren + +Je Port: Mode (Trunk/Access), PVID, VLAN-Membership (Untagged/Tagged) — analog zum ALLNET-Klickpfad +(`switch/ui-guides/01-trunk-ap-ports.md`, Schritte 1-2), aber im Omada-Easy-Smart-UI (Menüführung +kann leicht abweichen, Absicht ist identisch: Trunk-Ports = VLAN1 untagged + Ziel-VLANs tagged, +Access-Ports = PVID auf Ziel-VLAN, restliche VLANs nicht Mitglied). + +⚠️ **Port 1 (Uplink) und Port 2 (ap2) zuletzt/vorsichtig anfassen** — das sind die einzigen Pfade, +über die der Switch selbst und ap2 erreichbar bleiben. Bei jedem Zwischenschritt Erreichbarkeit +(Switch-UI + ap2-Mgmt `10.40.41.2`) verifizieren, bevor der nächste Port angefasst wird. + +## Schritt 4 — Persistieren + +Save/Apply im UI (Config-Persistenz nicht vergessen — sonst nach Stromausfall/Reboot wieder weg, +analog zum ALLNET-`save`-Gotcha). + +## Schritt 5 — Verifikation + +- Switch-UI weiterhin erreichbar (kein Lockout). +- ap2-Mgmt (`10.40.41.2`) weiterhin erreichbar (Port 2 nicht kaputt konfiguriert). +- Je Access-Port: angeschlossenes Gerät bekommt weiterhin eine passende IP/ist erreichbar + (Docking-Station, Drucker, Mac mini, NAS — je nachdem was laut Schritt 1 noch dranhängt). +- `mikromcp list_neighbors`/ARP-Sweep zur Gegenprobe, dass nichts verwaist ist. + +## Rollback + +- **Kein Controller mehr im Spiel** → kein "Re-Adopt"-Rollback-Pfad. Bei Fehlkonfiguration: einzelne + Port-/VLAN-Settings im lokalen UI zurückdrehen, oder im Notfall erneuter Werks-Reset (Switch dann + wieder bei Schritt 0). +- **Physischer Zugriff nötig, falls Web-UI durch eigene Fehlkonfiguration unerreichbar wird** (z.B. + Mgmt-VLAN versehentlich von einem live erreichbaren Port entfernt) — Reset-Taster am Gerät. + +## Nachziehen (nach erfolgreichem Abschluss) + +- `docs/teilprojekte.md` TP2.1 auf ✅ setzen, finale Portbelegung dokumentieren. +- `docs/ip-plan.md` Zeile sw2 aktualisieren (falls IP sich geändert hat). +- `CLAUDE.md` Hardware-Tabelle (Zeile Omada Access-Switch) aktualisieren — "Adoption pending" ist + obsolet, durch "Standalone, kein Controller" ersetzen. +- `omada/.secrets` mit neuen Creds aktualisieren (falls Passwort sich geändert hat), Berechtigung + `chmod 600` sicherstellen. +- Prüfen, ob `mcp/omada/.env`/omada-mcp irgendwo noch sw2-spezifische Annahmen hat, die jetzt falsch + sind (omada-mcp spricht ohnehin nur noch mit dem Controller für andere Zwecke, falls der überhaupt + noch gebraucht wird — zu klären, ob der Controller-Container jetzt komplett überflüssig ist und + abgebaut werden kann, da Omada keine Rolle mehr im Netz hat).