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:

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.
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).
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?
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):

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

8.8 KiB Raw Blame History