diff --git a/README.md b/README.md index 03940e7..76172e4 100644 --- a/README.md +++ b/README.md @@ -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 diff --git a/docs/core-switch-prep.md b/docs/core-switch-prep.md index a8015bd..7c9207b 100644 --- a/docs/core-switch-prep.md +++ b/docs/core-switch-prep.md @@ -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..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..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)