docs 🧭 Governance „Config nur via Nautobot" + TP19.1-Stand (ap1-DNS ✅, ap2 vertagt), sw2-IP-Korrektur .41.181, VLAN99-Cutover-Guides sw1/sw2, TP15-Lieferung 17.07., TP20 an Komodo gebunden

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

switch/ui-guides/02-vlan99-mgmt-cutover.md

@@ -0,0 +1,94 @@
+# 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.