Initial commit: BF Core-Switch-Prep + VLAN-Architektur + Delegations-Übergabe
- ALL-SG8316M auf FW 2.2.1.2956 geflasht; VLAN-DB 10/20/30/40/100 via Telnet-CLI (non-disruptiv) - CLI-Tooling: run-cli.exp + .cli-Files + CLI-REFERENCE (FW 2.2.1, IOS-artig) - Kanonisches Inventar: bf.csv/md + build.py (Doku-Motor), Core-Port-Map - Finaler VLAN-/Adressplan (10.40.<vlanid>.0/24), Firmware-Runbooks, Recovery-Assets - Secrets/Firmware/State/DS_Store via .gitignore ausgeschlossen Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This commit is contained in:
Christoph Emsenhuber
104
docs/core-switch-prep.md
Normal file
104
docs/core-switch-prep.md
Normal file
@@ -0,0 +1,104 @@
|
||||
# Core-Switch ALL-SG8316M — Vorbereitung (heute) + Cutover (morgen)
|
||||
|
||||
> 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.
|
||||
|
||||
## 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 |
|
||||
| PVID je Port (1–4094) | ✅ | UM |
|
||||
| STP/RSTP, LACP, Port-Mirroring, 802.3x | ✅ | UM |
|
||||
|
||||
→ **Kein Switch-Tausch nötig.** Core bleibt als VLAN-Trunk-Verteiler.
|
||||
|
||||
## 1. VLAN-Schema (User-bestätigt 2026-06-05)
|
||||
|
||||
| VLAN | Zweck | Subnetz | Gateway (hAP #1) | DHCP-Pool |
|
||||
|---|---|---|---|---|
|
||||
| **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 | — | — |
|
||||
|
||||
**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).
|
||||
|
||||
**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).
|
||||
|
||||
Phase 1 (morgen) nutzt **nur vlan10 aktiv**; 20/30/40 werden definiert, aber ohne Clients.
|
||||
|
||||
### 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.
|
||||
|
||||
## 2. Port-Map (16 Ports) — DRAFT, vom User zu bestätigen
|
||||
|
||||
| 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 |
|
||||
|
||||
> ⚠️ **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.
|
||||
|
||||
> **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.**
|
||||
|
||||
## 3. HEUTE — non-disruptive Vorbereitung (Reihenfolge!)
|
||||
|
||||
Alles hier ändert **nichts** am laufenden Flach-Netz (FB bleibt Gateway, alle Live-Ports bleiben VLAN1 untagged).
|
||||
|
||||
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.
|
||||
|
||||
**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).
|
||||
|
||||
## 4. ⚠️ Mgmt-VLAN-Lockout — Gotcha (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.
|
||||
|
||||
## 5. MORGEN — Cutover-Klickliste (Phase 1, Ziel < 30 Min Ausfall)
|
||||
|
||||
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.
|
||||
Reference in New Issue
Block a user