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

Docs: core-switch-prep auf aktuellen Stand bringen

Browse Source 
- Phase A als ABGESCHLOSSEN markiert (Firmware 2.2.1, VLAN-DB+Names, Save)
- Alte DRAFT-Inhalte (172.20/30/40-Schema, FW-Update 'heute', Web-UI-Skripting) entfernt
- Neue Struktur: Status/Phase-A/Phase-B-Cutover-Plan/Gotchas/Offene-Punkte
- Telnet-VTY-Lockout, Mgmt-VLAN-Lockout, Gateway-Migration, end-vs-exit dokumentiert
- README: SSOT-Link auf HANDOVER.md, Struktur-Übersicht, aktueller Stand
This commit is contained in:
Christoph Emsenhuber
2026-06-09 19:01:14 +02:00
parent bb31625d8f
commit 1f6e2a000b
2 changed files with 106 additions and 76 deletions
Download Patch File Download Diff File Expand all files Collapse all files

19
README.md
View File

@@ -1,4 +1,21 @@
# bf-network-r6
BF-Netzwerk-Migration (Variante R6+C2). 2× MikroTik hAP ax² + Core ALL-SG8316M.
Plan-SSOT: ~/.claude/plans/welche-kosteng-nstigen-alternativen-zu-memoized-sparkle.md
**SSOT & Übergabe:** [`HANDOVER.md`](HANDOVER.md) — kompletter Status, Architektur + Begründungen, Phasen, Gotchas, Zugänge.
**Plan-Origin:** ~/.claude/plans/welche-kosteng-nstigen-alternativen-zu-memoized-sparkle.md
**Struktur:**
- `docs/vlan-plan.md` — VLAN-/Adressplan (final)
- `docs/core-switch-prep.md` — Core-Switch Status & Phasen
- `docs/firmware-flash-runbook.md` — FW-Flash Historie
- `switch/cli/CLI-REFERENCE.md` — bestätigte CLI-Syntax
- `switch/cli/*.cli` / `*.exp` — reproduzierbare Konfig-Scripts
- `inventory/bf.csv` / `bf.md` — IP-Doku (aus IPs.xlsx gespiegelt)
- `inventory/bf-core-ports.csv` / `.md` — Switch-Port-Map
**Aktueller Stand (2026-06-09):**
- Phase A (VLAN-Vorbereitung) ✅ abgeschlossen
- Phase B (hAP-Cutover) ⏳ wartet auf MikroTik-Lieferung
- Phase C (Firewall) + Phase D (Adress-Migration) ausstehend

163
docs/core-switch-prep.md
View File

@@ -1,104 +1,117 @@
# Core-Switch ALL-SG8316M — Vorbereitung (heute) + Cutover (morgen)
# Core-Switch ALL-SG8316M — Vorbereitung & Status
> Status: **DRAFT** — Port-Map + Subnetze müssen vom User bestätigt werden (markierte `??`).
> Switch: ALLNET ALL-SG8316M, 16× Gigabit, Smart-Managed (Web + SNMP), lüfterlos.
> Stand: **2026-06-09** — Phase A (VLAN-Vorbereitung) abgeschlossen.
> Phase B (hAP-Cutover) wartet auf die MikroTik hAP ax².
> Vollständige Übergabe/Architektur: `HANDOVER.md` im Repo-Root.
> CLI-Referenz: `switch/cli/CLI-REFERENCE.md`.
Switch: **ALLNET ALL-SG8316M**, 16× Gigabit, Smart-Managed. **FW 2.2.1.2956** (geflasht am 2026-06-08 von 1.0/2014).
Mgmt-IP: **10.40.41.239** (statisch, im MAIN-Subnetz bis zum Cutover → wandert nach vlan99/10.40.99.2).
Login: `claudecode` (Creds in `switch/.secrets`).
## 0. Capability-Check (verifiziert)
Laut Hersteller-Handbuch erfüllt der ALL-SG8316M alle R6-Anforderungen:
| Anforderung | ALL-SG8316M | Quelle |
|---|---|---|
| IEEE 802.1Q VLAN tagged | ✅ | UM, VLAN-Kapitel |
| Port-Modus **Trunk** (1 untagged + n tagged) | ✅ | UM: "Trunk = untagged member of one VLAN at most, tagged member of zero or more" |
| Port-Modus **Access** (nur untagged) | ✅ | UM |
| Port-Modus **Hybrid** | ✅ | UM |
| Port-Modus Trunk (1 untagged + n tagged) | ✅ | UM |
| Port-Modus Access (nur untagged) | ✅ | UM |
| Port-Modus Hybrid | ✅ | UM (default auf allen Ports!) |
| PVID je Port (1–4094) | ✅ | UM |
| STP/RSTP, LACP, Port-Mirroring, 802.3x | ✅ | UM |
| Web-UI skriptbar (FW 1.0) | ✅ | Realtek `dispatcher.cgi` |
| Web-UI skriptbar (FW 2.2.1) | ❌ | cmd-Codes geändert (`cmd=2` → 404) |
| SSH | ❌ | nur Telnet (Port 23) |
| Telnet-VTY-Lines | **1** | ⚠️ reapt stale Sessions schlecht |
→ **Kein Switch-Tausch nötig.** Core bleibt als VLAN-Trunk-Verteiler.
## 1. VLAN-Schema (final — User-bestätigt 2026-06-09)
## 1. VLAN-Schema (User-bestätigt 2026-06-05)
Siehe `docs/vlan-plan.md` für die ausführliche Version mit Begründungen.
| VLAN | Zweck | Subnetz | Gateway (hAP #1) | DHCP-Pool |
| VLAN | Name | Subnetz (Ziel) | Interim | Zweck |
|---|---|---|---|---|
| **10** | **Server/Main (bestehend, unangetastet)** | **10.40.41.0/24** | .1 (neu, war FB) | #1: .50–.150 / #2: .151–.250 |
| 20 | Docker/Container (`default_internal`-Ziel) | 172.20.0.0/24 | .1 | später (Container-Migration) |
| 30 | IoT | 172.30.0.0/24 | .1 | später (Phase 2) |
| 40 | Guest (*mit Vorbehalt*) | 172.40.0.0/24 | .1 | später (Phase 2) |
| 100 | WAN (→ FB) | FB-Subnetz (z.B. 192.168.178.0/24) | — (DHCP-Client der hAP#1 zur FB) | von FB |
| 1 | **Lifeboat/Default** | nur Switch-Mgmt-Zugang während Transition | — | — |
| 10 | MAIN | 10.40.10.0/24 | **10.40.41.0/24** | Trusted-Clients + Media (Discovery!) |
| 20 | INFRA | 10.40.20.0/24 | 172.x | Server, VMs, Docker, NAS, HA |
| 30 | IOT | 10.40.30.0/24 | — | Smart-Home (HA-managed) |
| 40 | UNTRUSTED | 10.40.40.0/24 | — | Spielekonsole, Low-Trust-Internet |
| 90 | GUEST | 10.40.90.0/24 | — | nur Internet (abgesetzt; 50–89 frei) |
| 99 | MGMT | 10.40.99.0/24 | Switch vorerst .239 | Switch/AP/Hypervisor-Mgmt |
| 100 | WAN | (FB-Transfer) | — | zur Fritzbox |
| 1 | default | — | aktuell alle Ports untagged | Lifeboat bis Cutover |
**Schlüssel-Vereinfachung:** vlan10 = **das bestehende 10.40.41.0/24**. Geräte behalten ihre IPs;
Cutover = reiner **Gateway-Wechsel** FB→hAP#1, **kein Re-IP**. Switch-Mgmt-IP kann auf 10.40.41.x
bleiben → Lockout-Risiko stark reduziert (Mgmt-VLAN wechselt 1→10, IP-Subnetz bleibt gleich).
**Adress-Konvention:** 3. Oktet = VLAN-ID (10.40.<vlanid>.0/24). Gateway je VLAN = `.1` (hAP#1). Switch-Mgmt = `10.40.99.2` (nach Cutover).
**Gateway-Konvention (User-Entscheid):** **.1 wird Standard** für alle Netze → hAP#1 = **10.40.41.1**.
Heute ist die **FB Gateway/DHCP auf 10.40.41.254** (suboptimal, aber heute unangetastet). Beim Cutover
verlässt die FB das LAN-Subnetz (→ WAN/vlan100), .254 wird frei. Switch-Mgmt = **10.40.41.2** (statisch).
## 2. Port-Map (16 Ports) — Ist vs. Soll
Phase 1 (morgen) nutzt **nur vlan10 aktiv**; 20/30/40 werden definiert, aber ohne Clients.
**Ist** (`inventory/bf-core-ports.csv`):
| Port | Heute |
|---|---|
| 4 | Wohnzimmer-Switch |
| 8 | Arbeitszimmer-Switch (`.10`/`.167`/`.247`) |
| 15 | pve (Mac mini) |
| 16 | FB (`.246` auf FB-LAN4) |
### vlan20 / Docker — eigener Workstream (NICHT Switch-Prep heute)
Die Container (`default_internal` u.a. auf pve/fm) sollen perspektivisch auf 172.20.0.0/24 (vlan20).
Übergangs-**Brücke** nötig, damit Container vorerst unter alten IPs erreichbar bleiben; Migration
schrittweise. → Eigenes Doc/Phase, hier nur vermerkt. Switch muss vlan20 nur **definiert** haben.
**Soll** (nach Phase-B-Cutover):
| Port | Ziel | Modus |
|---|---|---|
| 16 | FB-Uplink | Access untagged vlan100 |
| 2 oder 3 | hAP ax² #1 (Trunk) | Trunk tagged 10,20,30,40,90,100 |
| 2 oder 3 | hAP ax² #2 (Trunk) | Trunk tagged 10,20,30,40,90 |
| 4, 8, 15 | interim MAIN | Access untagged vlan10 |
| 1 oder 16 | Lifeboat bis Mgmt sicher | Access untagged vlan1 |
## 2. Port-Map (16 Ports) — DRAFT, vom User zu bestätigen
> ⚠️ **Port-Map noch nicht final** — wird beim Cutover ausgefüllt, abhängig von hAP-Standorten.
| Port | Heute (flach VLAN1) | Ziel (nach Cutover) | Modus Ziel |
|---|---|---|---|
| 1 | FB-Uplink (Gateway) `??` | WAN ↔ FB | **Access untagged vlan100** |
| 2 | — | Trunk ↔ hAP ax² #1 | **Trunk: tagged 10,20,30,40,100** `??` |
| 3 | — | Trunk ↔ hAP ax² #2 | **Trunk: tagged 10,20,30,40** |
| 4–15 | lokale Geräte `??` | lokale Geräte | **Access untagged vlan10** |
| 16 | **Mgmt-Lifeboat** (PC für Switch-Zugang) | Mgmt-Lifeboat | **Access vlan1** bis Mgmt sicher auf vlan10 |
## 3. Phase A (VLAN-Vorbereitung) — ✅ ABGESCHLOSSEN 2026-06-09
> ⚠️ **FÜLLE DIESE TABELLE MIT DER ECHTEN BELEGUNG.** Welcher Port = FB? Welche Ports haben kritische Dauer-Geräte (NAS, Drucker, AV)? Das entscheidet, welche Ports beim Cutover umgehängt werden.
Alles hier änderte **nichts** am laufenden Flach-Netz (FB blieb Gateway, alle Live-Ports blieben VLAN1 untagged).
> **Trunk-native-VLAN-Frage:** Auf hAP#1-Trunk liegt zusätzlich das WAN. Sauberste Variante: WAN als **eigenes Tag (vlan100)** auch über den Trunk zu hAP#1 führen statt als native — dann ist auf dem Switch _kein_ Port untagged-WAN nötig und Port 1 (FB) wird Access-untagged-vlan100, der Trunk trägt vlan100 **tagged**. RouterOS macht tagged-WAN problemlos. → Bevorzugt: **Port1 Access-untagged-vlan100 (zur FB), Trunk zu #1 tagged 10,20,30,40,100.**
1. ✅ **Config-Backup:** `show running-config` → `switch/cli/running-PRE.txt` (Netzmasken-Syntax `mask 255.255.255.0` bestätigt)
2. ✅ **Firmware-Update:** 1.0 (2014) → 2.2.1.2956 (2018). Details: `docs/firmware-flash-runbook.md`
3. ✅ **VLAN-DB angelegt + benannt:** 10=MAIN, 20=INFRA, 30=IOT, 40=UNTRUSTED, 90=GUEST, 99=MGMT, 100=WAN. **Alle Static, keine Port-Membership → null Disruption.**
4. ✅ **Save** (Success), `show vlan` verifiziert.
5. ✅ CLI-Reference (`switch/cli/CLI-REFERENCE.md`) mit bestätigter Syntax aktualisiert.
## 3. HEUTE — non-disruptive Vorbereitung (Reihenfolge!)
**Reproduzierbar:**
```bash
cd ~/dev/bf-network-r6/switch
. ./.secrets
expect cli/02-vlan-names.exp # benennt die VLANs (idempotent)
# ODER: manuell:
# expect cli/01-vlan-db.exp # legt VLANs an (aus 01-vlan-db.cli)
```
Alles hier ändert **nichts** am laufenden Flach-Netz (FB bleibt Gateway, alle Live-Ports bleiben VLAN1 untagged).
## 4. Phase B (hAP-Cutover) — AUSSTEHEND (MikroTik hAP ax² bestellt, noch nicht da)
1. **Config-Backup ZUERST** — aktuelle Konfig exportieren/sichern (Web-UI → Maintenance/Backup). Datei nach `bf-network-r6/switch/all-sg8316m-backup-PRE.cfg`.
2. **Mgmt-IP dokumentieren** — aktuelle Switch-IP + Login notieren (heute auf FB-Subnetz, z.B. 192.168.178.x). **Nicht ändern** — sonst Zugang weg.
3. **Firmware-Update HEUTE** (User-Entscheid: voll inkl. FW). Aktuelle FW von ALLNET ziehen (Produktseite ALL-SG8316M → Downloads), Version notieren, in ruhigem Zeitfenster flashen. ⚠️ **Reboot = ~1–2 Min Gesamtausfall** fürs BF-Netz → ankündigen. Backup (Schritt 1) MUSS davor liegen. Nach Reboot Config-Integrität prüfen (VLAN-DB ggf. neu anlegen, falls FW Settings resettet).
4. **VLAN-DB anlegen**: VLANs 10, 20, 30, 100 erstellen — **ohne** Port-Membership-Änderungen an Live-Ports. Reines Anlegen im VLAN-Table ist forwarding-neutral, solange alle aktiven Ports untagged member von VLAN1 bleiben.
5. **Leere Trunk-Ports vorkonfigurieren**: Die _für die hAPs vorgesehenen, aktuell unbelegten_ Ports (z.B. 2 & 3) schon auf **Trunk** stellen (tagged 10,20,30,100). Kein Link dran → keine Disruption. Morgen nur noch hAP einstecken.
6. **Physisch vorbereiten**: 2× Cat6e-Trunk-Kabel zu den hAP-Standorten ziehen + Ports labeln (FB / Trunk#1 / Trunk#2 / Lifeboat).
7. **Lifeboat-Port festlegen** (z.B. Port 16, VLAN1) — bleibt während der ganzen Transition als Notzugang zum Switch-Mgmt.
**Voraussetzungen:**
- 2× MikroTik hAP ax² produktiv
- Technitium-DNS läuft (pve + fm)
- Switch-Phase-A abgeschlossen ✅
**Heute NICHT anfassen:** PVID/Membership der Live-Geräte-Ports, FB-Port, Mgmt-IP/Mgmt-VLAN, Global-VLAN-Filtering-Enable falls es Live-Traffic bricht (Verhalten gerätespezifisch → im Backup-Zustand testen).
**Schritte (geplant, Details in `HANDOVER.md` §5.B):**
1. Trunk-Ports (2 & 3) am Switch auf Trunk tagged 10,20,30,40,90,100 konfigurieren
2. hAP #1 + #2 einstecken
3. hAP #1 = Router/Gateway (10.40.<vlan>.1), DHCP, DNS, CAKE/SQM, CAPsMAN
4. FB umstellen: DHCP aus, "Exposed Host" → hAP#1-WAN-IP. FB-Port (16) → Access untagged vlan100.
5. Live-Ports (4, 8, 15) → Access untagged vlan10 (PVID 10).
6. Switch-Mgmt → vlan99, IP 10.40.99.2.
7. **Gateway-Migration .254 → .1** via Secondary-IP auf hAP#1 (siehe Gotcha §6).
## 4. ⚠️ Mgmt-VLAN-Lockout — Gotcha (Cutover-kritisch)
## 5. ⚠️ Gotchas (Cutover-kritisch)
Entschärft durch vlan10=10.40.41.0/24 (= bestehendes Subnetz): die Mgmt-**IP** muss **nicht** wechseln,
nur die Mgmt-**VLAN-Zuordnung** 1→10. Trotzdem Reihenfolge-kritisch.
**Regel:** Switch-Mgmt **am Cutover** auf **vlan10**, IP bleibt z.B. 10.40.41.2 (statisch, außerhalb DHCP-Pool .50–.250) `??` — und **erst nachdem** Zugang über vlan10 bestätigt ist, den Lifeboat-Port (VLAN1) ziehen. Reset-Button ist die einzige Fallback-Option (kein serieller Konsolen-Port) → langsam & sorgfältig.
- **Telnet-VTY-Lockout:** Nur 1 VTY-Line. Stale Sessions blockieren ~15 min. **Immer serialisiert, sauber ausloggen.** Bei "busy" warten statt hämmern. Recovery: Switch rebooten.
- **Mgmt-VLAN-Lockout:** Ziel-VLAN muss existieren UND der Mgmt-Port muss es tragen, sonst Reachability weg. Reset-Button ist einziger Fallback (kein serieller Konsolen-Port).
- **Gateway-Migration .254 → .1:** Alt-Lease-Clients zeigen noch auf .254. FB verlässt aber das LAN → Clients tot. **Mitigation:** hAP#1 temporär Secondary-IP `.254` bis alle Leases renewen.
- **CLI-Semantik:** In `expect`-Scripts `exit` aus `(config-vlan)` benutzen, nicht `end` (`end` aus config-vlan geht DIREKT zu `sw1#` und überspringt die config-Ebene).
- **Web-UI skripten ist tot:** FW 2.2.1 hat die Realtek-`dispatcher.cgi`-cmd-Codes geändert. Telnet-CLI ist der einzige automatisierbare Weg.
## 5. MORGEN — Cutover-Klickliste (Phase 1, Ziel < 30 Min Ausfall)
## 6. Offene Punkte
Voraussetzung: hAP #1 & #2 geflasht + Basis-Config (siehe `routeros/`), Technitium läuft (pve+fm).
1. hAP #1 per Trunk an Switch-Port 2 (schon Trunk-konfiguriert) → Link prüfen.
2. hAP #2 per Trunk an Switch-Port 3 → Link prüfen.
3. **hAP#1 als Gateway**: vlan10-IP = **10.40.41.1**, DHCP-Server an (.50–.150), Option-6 = Technitium (pve+fm).
⚠️ **Gateway-Migration-Gotcha (.254→.1):** Bestehende Clients haben per alter FB-Lease noch **Gateway .254** —
die FB ist nach Schritt 4 aber weg → Clients tot bis Lease-Renew. **Mitigation:** hAP#1 temporär **2. Adresse
10.40.41.254/24** geben (Secondary-IP), damit Alt-Lease-Clients weiterrouten; nach Renew aller Leases auf .1 wieder entfernen.
(Alternativ: DHCP-Lease-Time vorher kurz stellen / Clients renewen/rebooten — passt ins 30-Min-Fenster.)
4. **FB umstellen**: FB-DHCP aus, "Exposed Host" → hAP#1-WAN-IP. FB-Port am Switch (Port 1) → **Access untagged vlan100**. FB verlässt damit 10.40.41.0/24 (.254 frei).
5. **Lokale Geräte-Ports** (4–15) → **Access untagged vlan10** (PVID 10). _Disruptiver Moment_ → zügig durchziehen.
6. **Switch-Mgmt** → vlan10, IP **10.40.41.2** statisch. Zugang vom neuen LAN testen, **dann** Lifeboat ziehen.
7. Verifikation: DHCP von hAP#1 (.50–.150), Gateway .1, DNS via Technitium, Internet, CAKE/Bufferbloat-Test, WLAN-Roaming #1↔#2.
## 6. Offene Punkte (vom User)
- [x] Subnetz-Schema: vlan10=10.40.41.0/24 (bestehend), 20=172.20/24 (Docker), 30=172.30/24 (IoT), 40=172.40/24 (Guest, Vorbehalt)
- [x] Firmware: heute updaten (User-Entscheid, Reboot akzeptiert)
- [ ] **Echte Port-Belegung** (Tabelle §2 füllen) — v.a. FB-Port + kritische Dauer-Geräte
- [ ] **Switch-Mgmt-Zugang**: aktuelle IP + Login (für Backup/FW/VLAN-Anlage heute)
- [ ] **Zugriffsweg**: Web-UI Klick-für-Klick mit meiner Anleitung (Default für Smart-Switch) — ok?
- [x] **Aktuelles BF-Gateway**: FB = 10.40.41.254 (heute). Künftig Standard **.1** → hAP#1=10.40.41.1. Gateway-Migration-Gotcha in §5 erfasst.
- [x] VLAN-Schema final (mit 90=GUEST statt 40=Guest — eigene ID für Spielekonsole als IoT-Verschärfung)
- [x] Firmware geflasht (1.0 → 2.2.1.2956)
- [x] VLAN-DB angelegt + benannt + saved
- [ ] **MikroTik hAP ax²** (bestellt, Lieferung ausstehend)
- [ ] **Echte Port-Belegung finalisieren** (hAP-Standorte unbekannt → Trunk-Port-Wahl offen)
- [ ] **Phase B:** Trunk-Config, hAP-Bestückung, Cutover-Plan detail
- [ ] **Phase C:** Firewall Least-Privilege-Regelwerk
- [ ] **Phase D:** Adress-Migrationen (MAIN 10.40.41 → 10.40.10, INFRA 172.x → 10.40.20, NAS .10 → INFRA)