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