5.8 KiB
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. Memoryfeedback_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.mdPhase 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.mdSchritt 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
- Browser → https://10.40.41.181 (oder
http://, falls https nicht angeboten wird) → Loginadmin(PW insw2/.secrets, dort noch von dir einzutragen falls leer). - 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.
- Dort (oder unter einem "Port"/"Membership"-Unterpunkt) prüfen: Port 1 + Port 2 = Tagged Member von VLAN 99.
- 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
- Menü System suchen, darin nach IP-bezogenen Einträgen.
- 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:
99eintragen. - 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.
- IP-Adresse =
- Übernehmen/Apply.
- Ab hier ist deine aktuelle Session zur
.41.181-Adresse vermutlich tot (erwartet, kein Fehler).
2) Reconnect & Verifikation
- Neuer Tab → https://10.40.99.12.
- Erreichbar + Login geht? → weiter (ggf. Save, falls es diesen Schritt gibt, s.o.).
- 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.12erreichbar, ap2-Mgmt weiterhin erreichbar (falls schon auf VLAN99).sw2/.secretsSW2_HOSTauf10.40.99.12aktualisieren.docs/ip-plan.mdZeile sw2 bestätigen,CLAUDE.md-Hardwaretabelle nachziehen.
Nachziehen (nach erfolgreichem Cutover, alle drei TP19.1-Kandidaten durch)
docs/teilprojekte.mdTP19.1 auf ✅ setzen.- Governance-Hinweis: TP19.1 ist die letzte Ausnahme vom ap1/ap2-Config-Freeze bis TP21 (Nautobot) steht.