admin/bf-infra
1
0
Fork 0
Code Issues 21 Pull Requests Actions Packages Projects Releases Wiki Activity
Files
a73db063544ed2a45fb3030771b3b9246e8ea3f2
bf-infra/docs/core-switch-prep.md
Christoph Emsenhuber 498fa06472 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>
2026-06-09 18:08:45 +02:00

8.2 KiB
Raw Blame History

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)

  • 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)
  • 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?
  • 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 View Git Blame Copy Permalink