admin/bf-infra
1
0
Fork 0
Code Issues 21 Pull Requests Actions Packages Projects Releases Wiki Activity

Initial import from bf-network-r6.opencode — opencode migration

Browse Source
This commit is contained in:
Christoph Emsenhuber
2026-08-26 12:44:21 +02:00
commit 5ee0716dda
297 changed files with 72324 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

79
switch/ui-guides/01-trunk-ap-ports.md Normal file
View File

@@ -0,0 +1,79 @@
# ALLNET ALL-SG8316M — Web-UI-Guide: Trunk-Port für einen hAP-AP
> ✅ **STATUS 2026-06-09: gi1 (ap1) + gi2 (ap2) bereits getrunkt** — via Telnet-CLI ausgeführt
> (`switch/cli/03-trunk-ap-ports.cli`), `show vlan` POST verifiziert (gi1-2 tagged auf 10/20/30/40/90/99/100,
> vlan1 weiter untagged), `save` ok, Mgmt + APs erreichbar. Diese UI-Anleitung bleibt als **Referenz/Verifikation**
> und Vorlage für künftige Ports. Syntax `switchport trunk allowed vlan add <LIST>` am Gerät bestätigt.
> **Methode:** Claude erklärt Absicht + Klickpfad, **du klickst**. UI = Realtek-OEM (Backbone-SPA),
> FW 2.2.1.2956, erreichbar unter **https://10.40.41.239** (Login `claudecode`, PW in `switch/.secrets`).
> Labels unten sind aus der echten `lang/defLang.js` des Geräts gezogen — sollten exakt passen;
> falls eine Bezeichnung leicht abweicht, geht's um die **Absicht** (steht je Schritt dabei).
## Was wir wollen (Absicht in einem Satz)
Den Switch-Port, an dem ein hAP hängt, zu einem **Trunk** machen:
**VLAN 1 untagged (native)** = Mgmt/aktuelles Flachnetz bleibt drauf, **VLANs 10,20,30,40,90,99,100 tagged**.
So trägt der Port später die SSID→VLAN-Tags (Phase B), **und das jetzige Flach-WLAN „BF-Main" auf vlan1 läuft unverändert weiter.**
### CLI-Äquivalent (nur zum Gegenchecken — du machst es im UI)
```
interface gi<PORT>
switchport mode trunk
switchport trunk native vlan 1
switchport trunk allowed vlan add 10,20,30,40,90,99,100
```
## ⚠️ Bevor du klickst — Sicherheit (Familiennetz läuft!)
- **NUR den AP-Uplink-Port anfassen.** Finger weg von **Port 4, 8, 15, 16** (live: Wohnzimmer-/Arbeitszimmer-Switch, pve, Fritzbox).
- **VLAN 1 bleibt überall untagged** → die Switch-Mgmt-IP (.239, vlan1) bleibt erreichbar. **Kein Lockout.**
- **Management VLAN NICHT ändern** (bleibt 1). Das ist ein separater Cutover-Schritt mit Aussperr-Risiko.
- Welcher Port ist der AP? Laut Plan **ap1 = Port 2** (direkt am Core). **Bitte bestätigen** und unten `<PORT>` einsetzen.
→ **ap2** hängt aktuell hinter dem TL-SG108E an **Port 8 (live!)** — **diesen Port NICHT trunken.** Für ap2 siehe Abschnitt unten.
- Nicht dringend: Fürs aktuelle Flach-WLAN-Testen ist **gar keine** Switch-Änderung nötig. Dieser Trunk ist **Phase-B-Vorbereitung** (taggte VLANs bekommen erst nach dem Router-Cutover Gateway/DHCP).
## Klickpfad
### 0) Login & Vorprüfung
1. Browser → **https://10.40.41.239** → Login `claudecode`.
2. Menü **VLAN → Create VLAN**: prüfen, dass **10, 20, 30, 40, 90, 99, 100** in „Created VLAN" stehen.
(Sollten schon da sein — VLAN-DB + Namen sind angelegt. Falls eine fehlt: ID eintragen → **Add/Apply**.)
### 1) Port-Modus & PVID setzen — `VLAN → Port Setting`
1. Menü **VLAN → Port Setting** (Tabelle „Port Setting Table").
2. Zeile **Port `<PORT>`** auswählen → **Edit** (öffnet „Edit Port Setting").
3. Felder:
- **Mode** = **Trunk** *(falls „Trunk" zickt, geht auch **Hybrid** — alle Ports stehen eh auf Hybrid; Hybrid + Membership unten erreicht dasselbe.)*
- **PVID** = **1** *(untagged-Verkehr landet in vlan1 = Mgmt/Flachnetz)*
- **Accept Frame Type** = **All** *(tagged + untagged annehmen)*
- **Ingress Filtering** = **Enabled** *(nur Frames erlaubter VLANs — sauber; optional)*
4. **Apply/OK**.
### 2) VLAN-Mitgliedschaft des Ports — `VLAN → Membership`
Hier legst du pro VLAN fest, wie Port `<PORT>` Mitglied ist: **U**ntagged / **T**agged / leer (kein Mitglied).
1. Menü **VLAN → Membership** (Tabelle „Membership Table", Achse VLAN × Port).
2. **VLAN 1** editieren → Port `<PORT>` = **Untagged (U)** *(native; Mgmt/Flachnetz)*
3. **VLAN 10** editieren → Port `<PORT>` = **Tagged (T)**. Ebenso **20, 30, 40, 90, 99, 100** = **Tagged (T)**.
*(In der „Edit"-Maske oft per Klick durch die Zustände U → T → leer, oder Auswahl „Active/Tagged Member".)*
4. Sicherstellen: Port `<PORT>` ist bei den **anderen** VLANs **nicht** ungewollt untagged.
5. **Apply/OK** je VLAN.
### 3) Persistieren (sonst nach Reboot weg!)
- Oben rechts das **Save**-Symbol (Disketten-Icon) klicken → schreibt Running→Startup.
*(CLI-Äquivalent wäre `save`.)*
## Verifikation
- **VLAN → Membership**: Port `<PORT>` = U bei VLAN1, T bei 10/20/30/40/90/99/100.
- Switch-UI weiter erreichbar (https://10.40.41.239) → **kein Lockout**.
- WLAN **BF-Main** (vlan1) am hAP funktioniert unverändert (Client bekommt weiter FB-DHCP).
- Optional Gegencheck per CLI (Telnet, 1 VTY, sauber ausloggen): `show vlan`, `show running-config` → der Port zeigt `switchport ... vlan ...`.
## Sonderfall ap2 (Port 8 ist live!)
ap2 hängt hinter dem **TL-SG108E** am **Core-Port 8**, der **.10/.167/.247 trägt**. Optionen:
- **Jetzt nichts tun** — ap2 funkt „BF-Main" untagged auf vlan1 über den bestehenden Pfad (fürs Flach-WLAN-Testen reicht das).
- **Sauber (empfohlen vor Phase B):** ap2 in einem Wartungsfenster an einen **freien Core-Port** (z.B. Port 3) umstecken → diesen Port nach genau dieser Anleitung trunken. Dann muss der TL-SG108E nicht 802.1Q können.
- Trunk über Port 8 (TL-SG108E müsste taggen) = fummelig → **nicht empfohlen**.
## Offen / von dir bestätigen
- [ ] **ap1-Port** = wirklich Port **2**? (sonst `<PORT>` anpassen)
- [ ] **ap2-Verkabelung**: Port 8 lassen vs. an freien Core-Port umstecken?
- [ ] Jetzt schon Trunk vorbereiten (safe) oder erst zum Phase-B-Cutover?

94
switch/ui-guides/02-vlan99-mgmt-cutover.md Normal file
View File

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