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
commit 498fa06472
25 changed files with 1474 additions and 0 deletions
--- a/docs/core-switch-prep.md
+++ b/docs/core-switch-prep.md
@@ -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.
--- a/docs/firmware-flash-runbook.md
+++ b/docs/firmware-flash-runbook.md
@@ -0,0 +1,84 @@
+# Firmware-Flash ALL-SG8316M (1.0 → 2.2.1) + Plan-B-Recovery
+
+> ⚠️ Erst ausführen, wenn ALLE Pre-Flight-Punkte erfüllt sind. Flash = Werks-Reset der Config.
+> Quelle Defaults: ALLNET QIG. Annahme: Flash setzt Switch auf Werk → **192.168.1.1 / admin / admin**.
+
+## Werks-Defaults (Recovery-Anker)
+| | |
+|---|---|
+| Default-IP nach Flash | **192.168.1.1** /24 |
+| Default-Login | **admin / admin** |
+| FW-Image | `switch/firmware/2.2.1/all-sg8316m-version_2.2.1_vmlinux.bix` (5,1 MB) |
+| Aktuell (PRE) | IP 10.40.41.239, FW 1.0, nur VLAN1, Ports Hybrid/PVID1 |
+
+## Warum „du bist dann auch offline"
+Claude erreicht den Switch über **10.40.41.239**. Nach dem Flash lebt er auf **192.168.1.1** in einem
+anderen Subnetz → für Claude nicht mehr erreichbar, **bis** jemand physisch eine Verbindung ins
+192.168.1.x-Netz herstellt. **Recovery ist daher bewusst menschen-ausführbar** (GUI), Skript optional danach.
+
+## Pre-Flight-Checkliste (HARTE Voraussetzungen)
+- [ ] **Physisch am Switch** (Reset-Knopf erreichbar, Konsole-Zugang am Standort).
+- [ ] **Direkt angestöpselter Laptop** an einem Switch-Port (nicht über WLAN/Remote).
+- [ ] Laptop kann **Zweit-IP `192.168.1.2/24`** setzen (macOS: `sudo ifconfig en0 alias 192.168.1.2 255.255.255.0`).
+- [ ] **Stabile Stromversorgung** des Switches (idealerweise USV) — Stromausfall **während** des Flashs = Brick-Risiko #1.
+- [ ] FW-Image lokal vorhanden ✅ + Hash notiert (s.u.).
+- [ ] PRE-Scrape vorhanden ✅ (`switch/state-PRE/`) → Soll-Config bekannt.
+- [ ] Recovery-Skript bereit: `sg8316m.sh` kann Mgmt-IP zurücksetzen + VLANs/Ports anlegen (set_ip/add_vlans/…).
+- [ ] **Zeitfenster** angekündigt: BF-LAN droppt ~1–2 Min beim Reboot; Re-Config danach wenige Min.
+- [ ] Mentaler Worst-Case akzeptiert: €~96-Switch, im äußersten Notfall Ersatz.
+
+## Flash-Durchführung (GUI empfohlen — sichtbarer Fortschritt)
+1. Browser auf `http://10.40.41.239` → **Maintenance → Upgrade Manager** (cmd=4363).
+2. Upgrade Method = **HTTP**, Upgrade Type = **Image**, Datei = `…2.2.1_vmlinux.bix` → **Upgrade**.
+3. **NICHT** Strom/Netz trennen, bis der Switch von selbst neu startet. Geduld (mehrere Minuten).
+   - Scripted-Alternative (nur wenn bewusst gewählt):
+     `curl -F "type=0" -F "http_file=@switch/firmware/2.2.1/all-sg8316m-version_2.2.1_vmlinux.bix" -F "cmd=4364" http://10.40.41.239/cgi-bin/httpupload.cgi`
+
+## Post-Flash — erwarteter Zustand
+- Switch auf **192.168.1.1**, Login **admin/admin**, **leere Config** (nur VLAN1, Ports default).
+- 10.40.41.239 weg (erwartet, kein Fehler).
+
+## Recovery-Szenarien
+
+### A) Normalfall: Flash OK, Switch auf 192.168.1.1 (= erwartet) — RECOVERY ÜBER MAC MINI
+Voraussetzung: Mac mini trägt Zweit-IP **192.168.1.2/24** auf en0 (L2-benachbart, verifiziert).
+Siehe `switch/recovery/README.md`. Claude führt **vom Mac mini aus** (per SSH-Tunnel) aus — **kein**
+manuelles IP-Suchen, kein Laptop:
+```
+ssh 10.40.41.167 "curl -sS -X POST \
+  --data mode=0 --data ip=10.40.41.239 --data netmask=255.255.255.0 \
+  --data gateway=10.40.41.254 --data cmd=518 \
+  http://192.168.1.1/cgi-bin/dispatcher.cgi"
+```
+Danach Switch wieder auf .239 → Claude fährt VLANs/Ports/Mgmt-VLAN auf + `save`.
+(Repo muss dafür NICHT auf dem Mac mini liegen — der curl-Einzeiler reicht via SSH.)
+
+### B) Switch reagiert NICHT auf 192.168.1.1 (Loader/Recovery)
+1. **30 Sek warten**, erneut pingen (Boot dauert).
+2. **Factory-Reset-Knopf** ~10 Sek halten → erneut 192.168.1.1 prüfen.
+3. Manche Realtek-Loader haben **TFTP-Recovery**: PC auf feste IP, TFTP-Server mit dem Image bereithalten,
+   Switch beim Boot ziehen lassen. (Für SG8316M nicht dokumentiert → nur als letzter Versuch; Setup s.u.)
+4. Wenn weiterhin tot → Hardware-Defekt, Ersatz.
+
+### C) Flash bricht mit Fehler ab, Switch noch auf 10.40.41.239 / FW 1.0
+- Kein Reboot passiert → alte FW läuft weiter. Image-Datei/Hash prüfen, ggf. erneut versuchen oder abbrechen.
+
+## TFTP-Recovery vorbereiten (optional, für Szenario B)
+- macOS hat `launchctl`-tftpd, oder `dnsmasq --enable-tftp`. Image in TFTP-Root legen.
+- **Nur** relevant, wenn der Loader es unterstützt — vorher recherchieren, nicht blind versuchen.
+
+## Image-Integrität
+- SHA256 (verifiziert 2026-06-05):
+  `e3f160983e8b17962dc70a52360b7f560c92da8197928d702f5266027a0fc7fc`
+- Vor Flash erneut prüfen: `shasum -a 256 switch/firmware/2.2.1/all-sg8316m-version_2.2.1_vmlinux.bix`
+
+## Recovery-Skript (Felder verifiziert)
+- IP setzen (cmd=518): `POST mode=0 ip=<ip> netmask=<mask> gateway=<gw> cmd=518` → in `sg8316m.sh set-ip`.
+- Schnell-Recovery nach Flash:
+  `SW_HOST=192.168.1.1 SW_USER=admin SW_PASS=admin ./sg8316m.sh set-ip 10.40.41.239`
+  danach `.secrets` zurück auf .239, dann `add-vlans 10,20,30,40,100` + Port-Config + `save`.
+
+## Abbruch-Kriterien (lieber nicht flashen)
+- Kein physischer Zugang ODER kein direkt-gekabelter Laptop → **verschieben**.
+- Switch an instabilem Strom (kein USV, Gewitter, Bauarbeiten) → **verschieben**.
+- Kein Zeitpuffer für ~15–30 Min Bastel-Risiko → **verschieben**.
--- a/docs/manual-flash-howto.md
+++ b/docs/manual-flash-howto.md
@@ -0,0 +1,35 @@
+# Manuelles Firmware-Update ALL-SG8316M (1.0 → 2.2.1) via GUI
+
+Ausgangslage: Switch sauber auf FW 1.0 @ 10.40.41.239 (scripted Versuch hat nur den Auto-Reboot
+verpasst — Image-Write wird in der GUI vom Browser-JS korrekt zu Ende geführt inkl. Reboot).
+
+## 1. Firmware holen
+- Download (ZIP): https://www.allnet.de/ftp-downloads/allnet/switches/all-sg8316m/all-sg8316m-version_2.2.1.zip
+- Entpacken → Datei **`all-sg8316m-version_2.2.1_vmlinux.bix`** (5,1 MB)
+- SHA256 (optional prüfen): `e3f160983e8b17962dc70a52360b7f560c92da8197928d702f5266027a0fc7fc`
+- (Liegt auch schon auf dem Mac mini: `~/bf-switch-flash/all-sg8316m-version_2.2.1_vmlinux.bix`)
+
+## 2. Flashen
+1. Browser → `http://10.40.41.239` (ggf. Login).
+2. Menü **Maintenance → Upgrade Manager**.
+3. **Upgrade Method = HTTP**, **Upgrade Type = Image**, Datei = die `.bix`.
+4. **Upgrade** klicken.
+5. Seite zeigt **„Writing image to FLASH… Do not power down…"** → **Strom NICHT trennen, warten**.
+   Der Browser pollt selbst und rebootet danach.
+6. Falls die Seite „fertig" zeigt **ohne** Reboot → oben **REBOOT** klicken.
+
+## 3. Nach dem Reboot (~1–2 min)
+Switch kommt vermutlich auf **Werks-Default** hoch:
+- IP **192.168.1.1**, Login **admin / admin**
+1. Falls nicht erreichbar: Notebook-NIC temporär auf `192.168.1.50 /24` setzen (oder Mac mini, hat schon `192.168.1.2`).
+2. Browser `http://192.168.1.1`, admin/admin.
+3. **Network → IP Address**: Static, IP `10.40.41.239`, Maske `255.255.255.0`, Gateway `10.40.41.254` → Apply.
+4. **SAVE → Save Configuration to FLASH → Apply** (damit es den nächsten Reboot übersteht!).
+
+## 4. Fertig
+- Prüfen: System Information zeigt **Firmware Version 2.2.1**.
+- Mir „durch" sagen → ich verifiziere + übernehme (Mac-mini-Alias `192.168.1.2` ist noch aktiv).
+
+## Hinweise
+- Kommt der Switch auf `.239` statt `192.168.1.1` zurück (FW bewahrt IP) → Schritt 3 entfällt, nur prüfen + Save.
+- Reagiert er gar nicht: 30 s warten, dann Reset-Knopf 10 s → wieder `192.168.1.1`.
--- a/docs/vlan-plan.md
+++ b/docs/vlan-plan.md
@@ -0,0 +1,44 @@
+# BF — VLAN- & Adressplan (final, 2026-06-06)
+
+## VLAN-Modell
+| 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 10.40.41.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 (Mnemonik). Alles RFC1918 (10/8).
+
+## Firewall — Least-Privilege (nicht „Main→alle")
+- Default **deny** inter-VLAN, dann gezielt erlauben.
+- **Main → Infra:** nur Whitelist-Dienste (NAS-Shares, HA-UI, Proxmox-UI auf definierten Ports). Kein Vollzugriff.
+- **Infra → Main:** grundsätzlich deny (Ausnahmen: Backups/Notifications gezielt).
+- **IoT / Guest / Untrusted → intern:** deny — nur Internet.
+- **Mgmt (99):** aus Main nicht erreichbar; nur dedizierter Admin-Zugang.
+
+## Discovery / Usability (Sonos & Co.)
+- mDNS/SSDP queren VLANs **nicht** von allein → discovery-abhängige Media-Geräte (Sonos, AppleTV, AirPrint, TV/SAT)
+  liegen bewusst **auf MAIN** mit den steuernden Handys → funktioniert ohne Reflector.
+- Nicht-Discovery-Zugriff (NAS-UI, HA-Web) aus Main: per Firewall-Regel + DNS/Hostname, kein mDNS nötig.
+- Most-IoT-Steuerung läuft eh **Handy → HA → IoT** → IoT (30) kann hart dichtgemacht werden.
+
+## Geräte-Einordnung
+| Gerät | VLAN |
+|---|---|
+| Handy, Laptop (du) | 10 MAIN |
+| Sonos, AppleTV, Smart-TV, SAT-Receiver, Drucker | 10 MAIN (Discovery) |
+| Sensoren/Plugs/Kameras/Smart-Home | 30 IOT |
+| Spielekonsole | 40 UNTRUSTED |
+| NAS, Proxmox-VMs, Docker, HA | 20 INFRA |
+| Netz-Mgmt (sw1, hAPs, Hypervisor-Mgmt) | 99 MGMT |
+
+## Migrations-Notizen
+- **MAIN-Re-IP** 10.40.41 → 10.40.10: groß (DHCP/Statics/Referenzen) → später, geplant.
+- **INFRA**: erst vorhandene 172er weiterfahren, dann behutsam auf 10.40.20.0/24.
+- **NAS .10**: bleibt vorerst auf 10.40.41.10/MAIN; Umzug nach INFRA später.
+- **VPNchristoph**: muss von `.1` weg (wird Gateway); IP egal.
+- **Switch-Mgmt**: heute 10.40.41.239; nach Cutover → vlan99 / 10.40.99.2 (`management-vlan vlan 99` + `ip address`).