Files
bf-infra/switch/ui-guides/02-vlan99-mgmt-cutover.md

5.7 KiB

ALLNET ALL-SG8316M (sw1) — Web-UI-Guide: Management-VLAN 1 → 99 (TP19.1)

Methode: Claude erklärt Absicht + Klickpfad, du klickst. UI = Realtek-OEM (Backbone-SPA), FW 2.2.1.2956, erreichbar unter https://10.40.41.11 (Login claudecode, PW in switch/.secrets). Die VLAN-Menü-Labels unten (VLAN → Port Setting, VLAN → Membership) sind aus einer echten Scrape auf genau dieser Firmware (switch/ui-guides/01-trunk-ap-ports.md, 2026-06-09) — sollten exakt passen. Die System/IP/Management-VLAN-Labels sind NICHT live gescraped (nur aus der alten FW1.0-CGI-Map abgeleitet, switch/sg8316m-cgi-map.md) — Seitentitel können abweichen, die Absicht steht bei jedem Schritt dabei, danach suchen.

Was wir wollen (Absicht in einem Satz)

sw1s eigene Management-Adresse von 10.40.41.11 (VLAN1, interim) auf 10.40.99.11/24, GW 10.40.99.1, Management-VLAN 99 umstellen — der letzte von drei TP19.1-Kandidaten (nach ap2, vor... eigentlich zuletzt, s. Reihenfolge unten). VLAN 99 (MGMT) existiert bereits in der VLAN-DB (Name "MGMT" gesetzt), und alle Trunk-Ports (GE1/GE2/GE8 + der ap1-Uplink) tragen VLAN 99 bereits tagged (TP1 ✅) — es muss keine VLAN- oder Port-Config geändert werden, nur die switch-eigene Mgmt-Bindung.

⚠️ Bevor du klickst

  • Reihenfolge (aus docs/ip-plan.md Phase 2): ap2 zuerst, dann sw2, dann sw1 zuletzt — sw1 ist das risikoreichste Gerät (einziger Netzpfad zu sw2 hängt am sw1-Uplink; wird sw1 unerreichbar, ist auch sw2 nicht mehr über den Uplink diagnostizierbar). Wenn ap2/sw2 noch nicht durch sind: die hier lieber nicht vorziehen.
  • Telnet-CLI ist aktuell kaputt (claudecode-Login wird deterministisch abgelehnt, s. Memory project_tp19_vlan1_status_20260716) — d.h. kein CLI-Fallback, falls die Web-UI nach dem Schritt hängt. Das Web-UI-Login selbst ist unabhängig davon (anderer Login-Pfad) — trotzdem als Schritt 0 zuerst verifizieren, nicht blind loslegen.
  • Die eingebaute Sicherheitsnetz-Mechanik dieses Geräts: Änderungen wirken erst nach explizitem save in Flash. Solange du nicht speicherst, überlebt die Änderung keinen Reboot/Stromausfall — das ist hier bewusst der Rollback-Pfad (s. unten). Also: NICHT sofort speichern, erst verifizieren.
  • Kein bekannter Seriell-/Konsolen-Zugang an diesem Gerät. Physische Reset-Taste = Werksreset (komplette Config weg, alle VLANs/Trunks/Namen neu von den .cli-Skripten aufbauen) — nur allerletzter Ausweg.

CLI-Äquivalent (nur zum Gegenchecken/für später, falls Telnet wieder geht)

configure
ip address 10.40.99.11 mask 255.255.255.0
ip default-gateway 10.40.99.1
management-vlan vlan 99
end
# NICHT sofort:
save

(Quelle: switch/cli/CLI-REFERENCE.md.)

Klickpfad

0) Login & Vorprüfung

  1. Browser → https://10.40.41.11 → Login claudecode (PW switch/.secrets).
  2. VLAN → Membership: prüfen, dass VLAN 99 existiert und auf dem Port, der zu ap1 führt (laut routeros/wan-cutover-runbook.md = gi15; falls die UI andere Portnummern zeigt, den Port nehmen, der die meisten VLANs tagged trägt — das ist der AP-Uplink), als Tagged (T) gelistet ist. Falls nicht: hier abbrechen, nicht weitermachen (Physical-Path fehlt sonst).

1) IP-Adresse setzen — vermutlich System → IP Setting (Label ungescraped, s.o.)

  1. Menü mit "IP"/"Network"/"System" suchen (nicht "VLAN").
  2. Felder:
    • IP-Adresse = 10.40.99.11
    • Subnetzmaske = 255.255.255.0
    • Default Gateway = 10.40.99.1
    • Modus: Static (nicht DHCP)
  3. Noch NICHT Apply/Save drücken, wenn die Seite auch das Management-VLAN-Feld enthält — erst Schritt 2 mit auf derselben Seite ausfüllen (viele Realtek-OEM-UIs haben IP + Mgmt-VLAN auf einer gemeinsamen Seite). Falls getrennte Seiten: Apply hier ist ok, weiter zu Schritt 2.

2) Management-VLAN setzen — vermutlich gleiche Seite oder System → Management VLAN

  1. Feld Management VLAN / VLAN ID = 99.
  2. Jetzt Apply/Submit.
  3. Ab hier ist deine aktuelle Browser-Session zur alten .41.11-Adresse tot — das ist erwartet, keine Störung. Der Switch beantwortet ab jetzt nur noch auf 10.40.99.11.

3) Reconnect & Verifikation (BEVOR gespeichert wird!)

  1. Neuer Tab → https://10.40.99.11 aufrufen.
  2. Erreichbar + Login geht? → weiter zu Schritt 4 (Save).
  3. Nicht erreichbar nach ~1 Minute? → nicht weiter versuchen, nicht neu konfigurieren — stattdessen Switch stromlos machen und neu starten (Power-Cycle). Da nicht gespeichert wurde, bootet er mit der alten Config (10.40.41.11, VLAN1) wieder hoch → zurück auf Los, ohne Schaden. Danach mir Bescheid geben, bevor der nächste Versuch gestartet wird (ggf. stimmt eine Portzuordnung nicht).

4) Speichern (erst wenn Schritt 3 erfolgreich war!)

  • System → Save Config (oder Disketten-Symbol) → "Save to Flash". Ab jetzt übersteht die neue Mgmt-Adresse einen Reboot.

Verifikation (nach Save)

  • https://10.40.99.11 weiterhin erreichbar.
  • switch/.secrets SW_HOST auf 10.40.99.11 aktualisieren (für zukünftige Telnet-Versuche, falls der Login-Blocker sich klärt).
  • ap2 (sofern schon auf VLAN99 umgezogen) und sw2 weiterhin über VLAN99 erreichbar — kein Kollateralschaden am gemeinsamen MGMT-Segment.
  • docs/ip-plan.md Zeile sw1: bestätigt = ✅ setzen. CLAUDE.md-Hardwaretabelle nachziehen.

Nachziehen (nach erfolgreichem Cutover, alle drei TP19.1-Kandidaten durch)

  • docs/teilprojekte.md TP19.1 auf ✅ setzen.
  • Governance-Hinweis beachten: TP19.1 ist die letzte Ausnahme vom ap1/ap2-Config-Freeze bis TP21 (Nautobot) steht — danach keine weiteren ad-hoc-Router-Changes mehr ohne Rücksprache.