Initial import from bf-network-r6.opencode — opencode migration

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://<gefundene-IP>` (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).