# 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).