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