admin/bf-infra
1
0
Fork 0
Code Issues 21 Pull Requests Actions Packages Projects Releases Wiki Activity
Files
4335287e9694978fd8601ed5efdd8425ae643181
bf-infra/HANDOVER.md
Christoph Emsenhuber 3ae7321865 CLAUDE.md: auto-geladener Session-Kontext (VLAN, HW, Tooling, Gotchas) 
Ersetzt manuelles Referenzieren von Zusatzdateien beim Sessionstart.
HANDOVER.md als Archiv-Dokument markiert; teilprojekte.md bleibt kanonisch.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
2026-06-15 10:45:42 +02:00

13 KiB
Raw Blame History

BF-Netzwerk — Übergabe (Netzwerk · Routing · VLAN · Sprachtelefonie)

Archiv-Dokument (Stand: Phase A abgeschlossen). Aktuelle Projektsteuerung → docs/teilprojekte.md. Session-Kontext → CLAUDE.md (wird automatisch geladen).

Referenzen (Historie, optional): Ursprungs-Vergleich ~/.claude/plans/welche-kosteng-nstigen-alternativen-zu-memoized-sparkle.md · Projekt-Memory project_bf_network_r6 · Repo ~/dev/bf-network-r6/ (Git).

0. Auftrag der nächsten Session

  1. Phase A jetzt umsetzen (Switch-VLAN-Vorbereitung, non-disruptiv) — siehe §9.
  2. Phasen B–D planen & ausführen, sobald die 2× MikroTik hAP ax² produktiv sind (hAP-Cutover, Firewall, Adress-Migration).
  3. Doku/Memory aktuell halten (inventory/build.py, Memory project_bf_network_r6). Kickoff-Prompt zum Starten: §15.

1. Ziel & Treiber

Günstige, lokal/kostenlos verwaltete Alternative zu UniFi/Omada über Router+WiFi+Switch. K.O.-Kriterien: lokaler Gratis-Controller · VLAN · QoS · Multi-SSID→VLAN · DNS/DHCP-Redundanz · (6 GHz – bewusst zurückgestellt). Konkrete Treiber am Standort BF:

  • Sprachtelefonie/Call-Qualität (Hauptmotiv): Cable-Upload sättigt → Bufferbloat → Jitter in Telefonie/Calls. Lösung = echtes WAN-QoS (CAKE/SQM) am neuen Router. (Bezug: ungelöstes Thema aus project_network_calls_openwrt.)
  • AdGuard-Forwarder an BF ablösen: lokaler Router/DNS soll DoH→Cloudflare + lokale Rewrites selbst können.
  • Familienverträglichkeit: WLAN + Telefon dürfen beim Umbau nur minimal/kurz ausfallen.

2. Architektur-Entscheidung „R6+C2" (kompakt, mit Begründung)

  • Kein Anbieter bietet einen gratis lokalen Single-Pane über Router+WiFi+Switch + 6 GHz + Router-HA. Router-HA entfällt (DNS/DHCP-Redundanz genügt) → Feld öffnet sich.
  • Gewählt: MikroTik (RouterOS). Gründe: kann CAKE/SQM (Call-Fix), DNS (DoH/Rewrites), VLAN/QoS, CAPsMAN (zentrale WiFi-Config ohne Extra-Controller), nativer DHCP; günstig; minimale Box-Zahl.
  • Hardware: 2× hAP ax² (WiFi 6 2,4+5 GHz, kein 6 GHz — bewusst, spart €, Refresh in 3–4 J.; 5×1G).
  • Core-Switch behalten: ALLNET ALL-SG8316M kann 802.1Q (Trunk/Access/Hybrid + PVID) → tauglich, kein Tausch.
  • FB6660 bleibt Cable-Modem + Telefonanlage; Routing/DHCP/DNS/QoS wandert auf hAP#1.
  • C2 = DNS/DHCP-Strategie: DHCP nativ RouterOS (Split-Scope); DNS = Technitium-Container auf pve + fm.

3. Topologie

Ist (heute): FB6660 = Router/Gateway 10.40.41.254, alles flach in VLAN 1; Core-Switch verteilt nur L2.

Internet ─ FB6660 (Modem+Telefon+Router .254) ─ Core-Switch sw1 (10.40.41.239, flach) ─ Clients/Server/NAS/pve

Ziel (nach Cutover):

Internet ─ FB6660 (Modem+Telefon, "Exposed Host"→hAP#1)        Telefon bleibt an FB
                         │ (WAN-VLAN untagged)
                  Core-Switch sw1 (VLAN-Trunk-Verteiler, 802.1Q)
                   ├─ Trunk → hAP ax² #1 (Router: NAT/DHCP/DNS/Firewall/CAKE, CAPsMAN-Manager)
                   ├─ Trunk → hAP ax² #2 (AP, CAPsMAN-managed)
                   └─ Access-Ports je VLAN (lokale Geräte)

Geräte: FB6660 · sw1 10.40.41.239 · 2× hAP ax² (erwartet) · Mac mini pve 10.40.41.167 (macOS, L2-lokal zu sw1) · NAS nas-bf 10.40.41.10. Switch-Ports Ist (inventory/bf-core-ports.csv): 4→Wohnzimmer-Switch, 8→Arbeitszimmer-Switch (.10/.167/.247), 15→pve, 16→FB (.246 auf FB-LAN4). 4/8/15/16 behalten (4+8 interim bis neue Switches da).

4. VLAN-Modell · Adressplan · Firewall

VLAN Name Subnetz (Ziel) Interim Zweck
10 MAIN 10.40.10.0/24 vorerst 10.40.41.0/24 Trusted-Clients + Media (Sonos/AppleTV/TV/SAT/Drucker)
20 INFRA 10.40.20.0/24 vorerst vorhandene 172.x Server, VMs, Docker, NAS-Workloads, 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 für künftige VLANs)
99 MGMT 10.40.99.0/24 Switch vorerst .239 Switch/AP/Hypervisor-Mgmt-Interfaces
100 WAN (FB-Transfer) — zur Fritzbox

Konventionen: Gateway je VLAN = .1 (hAP#1) · Switch-Mgmt = 10.40.99.2 · 3. Oktet = VLAN-ID · alles RFC1918. Warum so (Kurz-Begründung der Diskussion):

  • INFRA ≠ MGMT (Workloads vs. Steuer-Interfaces = andere Vertrauensstufe).
  • Media auf MAIN (nicht aus Vertrauen, sondern weil mDNS/SSDP nicht über VLANs quert; Sonos-Steuerung vom Handy soll trivial bleiben).
  • UNTRUSTED (40) ≠ IOT (30): Konsole ist kein IoT → Name nicht verwässern.
  • Adressierung 10.40.<vlanid>.0/24: altes 172.40/50/99 lag außerhalb RFC1918 (privat=172.16–31) = öffentlicher Raum → korrigiert.

Firewall = Least-Privilege (NICHT „Main→alle", sonst wäre INFRA entwertet):

  • Default deny inter-VLAN, dann gezielt erlauben.
  • Main→Infra: nur Whitelist-Dienste (NAS-Shares, HA-UI, Proxmox-UI auf def. Ports).
  • Infra→Main: grds. deny (Ausnahmen gezielt: Backups/Notifications).
  • IoT/Guest/Untrusted→intern: deny — nur Internet.
  • MGMT (99): aus Main nicht erreichbar.
  • mDNS-Strategie: discovery-abhängige Media auf MAIN (kein Reflector nötig); Nicht-Discovery-Zugriff (NAS-UI/HA) via Firewall + DNS/Hostname.

IP-Detailentscheide: VPNchristoph zieht von .1 weg (wird Gateway; IP egal). vpnjoern .2 gekickt → frei. .10 nas-bf bleibt vorerst (Umzug nach INFRA später). .246/.247 bleiben. FB=.254.

5. Routing / DHCP / DNS

  • Router: hAP#1 = NAT, Inter-VLAN-Routing, Firewall (§4), CAKE auf WAN (§6).
  • DHCP: nativ RouterOS je VLAN. Split-Scope für Redundanz: #1 .50–.150, #2 .151–.250. Option 6 (DNS) = beide Technitium-IPs.
  • DNS: 2× Technitium-Container auf pve (10.40.41.167) + fm (DS415+). DoH→Cloudflare (Filterprofil je Wunsch), lokale Rewrites/Split-Horizon (aus AdGuard-Bestand migrieren). Adlists in Technitium AUS — CF-DoH filtert. Sync zwischen den 2 Instanzen. → AdGuard-Forwarder an BF wird damit obsolet (Original-Ziel). Mac mini nicht im kritischen Pfad (DHCP/DNS-Failover über 2 Instanzen).

6. Sprachtelefonie / Call-Qualität (Kern-Treiber)

  • Telefon bleibt an der FB6660 (DOCSIS-Telefonie tief verdrahtet) → beim Cutover nicht anfassen, Anrufe laufen weiter.
  • Call-/Video-Jitter kommt vom Bufferbloat am Cable-Upload (typ. ~1000/50, Upload sättigt schnell). → CAKE/SQM auf dem WAN-Interface (vlan100) des hAP#1, Upload-Rate ~85–95 % der real gemessenen FB-Upload-Linerate, iterativ via waveform.com/dslreports kalibrieren. Switches können das NICHT (kein Packet-Scheduling); FB-QoS reicht nicht.
  • Cutover-Priorität „Familie muss telefonieren": Phase B startet mit WiFi + CAKE innerhalb von Stunden, nur vlan10 aktiv; volle Segmentierung danach. Max. ~30 min Ausfall einplanen/ankündigen.
  • Verifikation: Bufferbloat-Test unter parallelem Upload-Stress bleibt niedrig; reale Telefonie ohne Jitter.

7. WiFi

  • CAPsMAN auf hAP#1 (Manager), hAP#2 als CAP → zentrale Wireless-Config, gleiche SSIDs, Roaming.
  • 3 SSIDs → VLAN-Mapping (MAIN/IOT/GUEST; UNTRUSTED je nach Bedarf). Phase B startet mit einer SSID „BF-Main"→vlan10.
  • WiFi 6 auf 2,4+5 GHz (kein 6 GHz).

8. Aktueller Stand (erledigt)

  • ✅ Switch sw1 auf FW 2.2.1.2956 geflasht (von 1.0). IP blieb .239; Cred-Store gewiped → claudecode-Account wiederhergestellt.
  • ✅ VLAN-DB 10/20/30/40/100 angelegt + save (alle Ports noch VLAN 1 → null Disruption, Netz läuft).
  • ✅ Repo + Tooling: CLI-Runner, .cli-Files, CLI-Referenz, kanonisches Inventar (bf.csv/build.py), Port-Map, VLAN-Plan, Runbooks.
  • ⚠️ FW 2.2.1 hat Web-UI umgebaut → alte dispatcher.cgi-cmd-Codes tot. Konfig nur via Telnet-CLI (kein SSH).

9. Implementierungs-Phasen

Phase A — Switch-VLAN-Vorbereitung (JETZT, non-disruptiv, kein Reboot, kein Port-Move)

Tooling: cd ~/dev/bf-network-r6/switch && . ./.secrets && expect cli/run-cli.exp cli/<datei>.cli

  1. show running-config → switch/cli/running-PRE.txt sichern (klärt zugleich Netzmasken-Syntax von ip address).
  2. vlan 90, vlan 99 anlegen (neues cli/02-vlan-extend.cli, analog 01-vlan-db.cli).
  3. VLAN-Namen setzen (MAIN/INFRA/IOT/UNTRUSTED/GUEST/MGMT) — Namens-Syntax erst per ? erkunden.
  4. save; mit show vlan verifizieren.

Vor Schritt 2 Mini-Entscheid bestätigen: Guest=90 (empfohlen) vs 50.

Phase B — hAP-Cutover (wenn hAP ax² produktiv) — DISRUPTIV, ankündigen

  • Trunk-Ports sw1→hAP#1/#2 (tagged 10/20/30/40/90/100); FB-Port = Access untagged WAN.
  • hAP#1: Gateway .1 je VLAN, DHCP (Split-Scope), DNS→Technitium, CAKE auf WAN, CAPsMAN, SSID(s).
  • FB: DHCP aus, „Exposed Host" → hAP#1-WAN. Telefon unangetastet.
  • Start „nur vlan10" für schnelles WLAN+Telefon, dann Segmentierung.
  • Switch-Mgmt nach vlan99 ziehen: management-vlan vlan 99 + ip address 10.40.99.2 (Reihenfolge-Gotcha → Reachability!).

Phase C — Firewall (Least-Privilege) am hAP — Regelwerk §4.

Phase D — Adress-Migrationen (behutsam): MAIN 10.40.41→10.40.10; INFRA 172.x→10.40.20; NAS .10→INFRA.

Backlog / weitere Planung

  • 4G/5G-WAN-Failover (USB-Modem an hAP#1 oder separater MikroTik-LTE) — optional, nachrüstbar.
  • 6E/WiFi7-Hardware-Refresh in 3–4 J.
  • Switch-Upgrade auf 2,5G (Branch/Core) bei Bedarf.
  • Container-Konsolidierung Docker→vlan20/INFRA (mit Übergangs-Brücke für alte IPs).
  • Restliche Switch-Ports erfassen (mit User), Port→VLAN-Zuordnung finalisieren.

10. Switch-CLI (FW 2.2.1, Telnet, IOS-artig) — Kompakt

Login claudecode (Passwort in switch/.secrets). Prompts sw1>→sw1#→sw1(config)#. Nur 1 VTY-Line!

  • mgmt-IP ansehen (enable): show ip · setzen (config): ip address <ip> + ip default-gateway <ip> (Maske-Syntax noch bestätigen)
  • mgmt-VLAN (config): management-vlan vlan <id> · ansehen show management-vlan
  • VLANs (config): vlan <liste> z.B. vlan 10,20,30,40,100 · ansehen show vlan
  • Ports: interface gi<n> → switchport mode {access|hybrid|trunk} · switchport access vlan <id> · switchport trunk native/allowed ...
  • Persistieren: save · Dump: show running-config (Paging --More--→Space) · Version: show version
  • NICHT vorhanden: interface vlan, show ip interface, terminal datadump. Details: switch/cli/CLI-REFERENCE.md.

11. Gotchas

  • Switch: nur 1 Telnet-VTY, reapt stale Sessions schlecht (~15 min „busy") → seriell, sauber ausloggen, bei busy warten statt hämmern.
  • save nicht vergessen (sonst nach Reboot weg).
  • FW-Flash-Default wäre 192.168.1.1/admin/admin (hier blieb IP; gut für Recovery zu wissen).
  • Cutover: Alt-Lease-Clients zeigen noch auf FB .254 → hAP#1 temporär Secondary-IP .254 bis Renew.
  • mgmt-VLAN-Wechsel = Lockout-Risiko (VLAN muss existieren + Port muss es tragen).
  • inventory/IPs.xlsx/bf.csv enthalten echte IPs/MACs → bei öffentlichem Remote vorher prüfen.

12. Zugang / Dateien

  • Switch: telnet 10.40.41.239, claudecode (switch/.secrets).
  • Mac mini (pve): ssh 10.40.41.167. DS415+ (fm): siehe reference_ds415_docker (Memory).
  • Repo: ~/dev/bf-network-r6/ — Schlüssel: HANDOVER.md (dies), docs/vlan-plan.md, switch/cli/, inventory/ (build.py).

13. Offene Entscheidungen

  • Guest-VLAN-ID 90 (empfohlen) vs 50 — vor Phase A.2.
  • Netzmasken-Syntax ip address final bestätigen (Phase A.1).
  • DNS-Filterprofil bei Cloudflare (Families o.ä.) — Phase B/Backlog.

14. Verifikation (End-to-End)

  • A: show vlan zeigt 10/20/30/40/90/99/100 mit Namen; in show running-config; save=Success.
  • B: SSID→VLAN-Tag greift; Client verbindet; DHCP/DNS vom hAP; Bufferbloat-Test niedrig unter Last (CAKE); Telefon ohne Jitter; CAPsMAN sieht hAP#2.
  • C: IoT/Guest erreichen Main/Infra nicht; Handy erreicht Whitelist-Dienste; Sonos-Steuerung funktioniert.

15. Kickoff-Prompt (copy-paste an die Nachfolge)

Übernimm das BF-Netzwerk-Projekt (Netzwerk/Routing/VLAN/Sprachtelefonie): Implementierung + weitere Planung.
LIES ZUERST die komplette Übergabe: ~/dev/bf-network-r6/HANDOVER.md  (alles drin: Architektur+Gründe, Phasen, CLI, Gotchas, Zugänge).
Memory: project_bf_network_r6. Repo: ~/dev/bf-network-r6/ (Git).

STAND: Switch 10.40.41.239 auf FW 2.2.1 geflasht, VLAN-DB 10/20/30/40/100 angelegt+saved, alle Ports noch VLAN1
(Netz läuft, FB ist noch Router/Telefon). Switch-Konfig NUR via Telnet-CLI (Login claudecode, PW in switch/.secrets);
nur 1 VTY-Line → seriell, sauber ausloggen, bei "busy" warten.

JETZT Phase A (non-disruptiv, §9): running-config sichern → vlan 90+99 anlegen → VLAN-Namen setzen → save → show vlan.
  Runner: cd ~/dev/bf-network-r6/switch && . ./.secrets && expect cli/run-cli.exp cli/<datei>.cli
  Vorher mit User bestätigen: Guest-VLAN-ID 90 vs 50.
Danach Phasen B–D planen/ausführen, sobald die hAP ax² produktiv sind (Cutover: Telefon muss durchlaufen, CAKE gegen Jitter).
Reference in New Issue View Git Blame Copy Permalink