Christoph Emsenhuber
2607964566
- pve: Hypervisor zählt zu INFRA (User-Entscheid) → 10.40.20.100 (VLAN20), MGMT/VLAN99 = nur noch Switch/AP-Mgmt. - Mac mini ✅ live auf 10.40.20.167 (Omada Access-INFRA ohne VLAN1). Kontext (live, nicht im Repo): - Omada: Access-IOT/-UNTRUSTED/-GUEST/-MGMT Profile angelegt (Satz komplett). - ap1 DNS: macmini.bf.lan → 10.40.20.167. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
3.6 KiB
3.6 KiB
AP — IP-Plan BF (per-Gerät, Ziel-VLAN-Subnetze)
Eigenständiges Arbeitspaket. Hier definieren wir die finalen statischen IPs je Gerät in den Ziel-VLANs. Voraussetzung (✅ erfüllt 2026-06-16): Routing VLAN1 ↔ übrige VLANs steht (statische Route auf der FB →
10.40.41.1), ap1-NAT nimmt LAN-internes aus (srcnat accept 10.40.0.0/16). Erst bestätigte Zeilen werden migriert. Status: 🟡 Entwurf — Vorschläge zum Festklopfen.
Konventionen
- Host-Oktett möglichst beibehalten (weniger Churn in DNS/Configs): z.B. NAS
.10→10.40.20.10. - GW je VLAN =
.1(ap1). Pools.100–.200= DHCP → statische Geräte außerhalb des Pools (.2–.99). - Zuordnung: VLAN20 INFRA = NAS/VMs/Docker/HA/Services + Hypervisor (User-Entscheid 2026-06-16: pve/DS923 sind Infra und Hypervisor → INFRA) · VLAN99 MGMT = nur Netz-Gear-Mgmt (Switch/AP) · VLAN10 MAIN = trusted Clients · VLAN40 MEDIA = Sonos/AppleTV/TV.
- Pro migriertem Gerät: (1) IP am Gerät selbst umstellen, (2) DHCP-Reservierung/Static pflegen,
(3) DNS
bf.lan-Eintrag auf ap1 updaten, (4) Reachability prüfen.
Geräte-Tabelle (Vorschlag → bestätigen)
| Gerät | aktuell (VLAN1) | Rolle | Ziel-VLAN | Vorschlag IP | bestätigt | Notizen |
|---|---|---|---|---|---|---|
| ap1 (Router/hAP) | 10.40.41.1 | Router/GW | alle (.1) + Mgmt | bleibt .1 je VLAN; Mgmt 10.40.99.1 |
⬜ | ist GW, kein „Umzug" |
| ap2 (hAP) | 10.40.41.2 | AP | 99 MGMT | 10.40.99.2 |
⬜ | |
| sw1 ALLNET (Core) | 10.40.41.11 | Switch-Mgmt | 99 MGMT | 10.40.99.11 |
⬜ | Mgmt-VLAN-Wechsel = Lockout-Risiko, sorgsam |
| sw2 Omada (ES208G) | 10.40.41.12 | Switch-Mgmt | 99 MGMT | 10.40.99.12 |
⬜ | |
| NAS nas-bf (DS923) | 10.40.41.10 | INFRA | 20 INFRA | 10.40.20.10 |
⬜ | trägt Omada-Controller (macvlan) |
| Omada-Controller | 10.40.41.175 | Service (macvlan/DS923) | 20 INFRA | 10.40.20.175 |
⬜ | ⚠️ Mgmt-Ebene — vorsichtig/spät |
| omada-mcp | 10.40.41.176 | Service (pve-LXC) | 20 INFRA | 10.40.20.176 |
⬜ | ⚠️ Mgmt-Ebene |
| pve-mcp | 10.40.41.173 | Service (pve) | 20 INFRA | 10.40.20.173 |
⬜ | ⚠️ Mgmt-Ebene |
| Docker-LXC | 10.40.41.126 | Docker-Host (pve) | 20 INFRA | 10.40.20.126 |
⬜ | Portainer/Komodo |
| Proxmox pve | 10.40.41.100 | Hypervisor+INFRA | 20 INFRA | 10.40.20.100 |
⬜ | User: Hypervisor zählt zu INFRA (wie DS923) |
| Mac mini | 10.40.41.167 | INFRA/Server | 20 INFRA | 10.40.20.167 |
✅ live | umgezogen; Omada P7 + Access-INFRA (VLAN20, ohne VLAN1) ✅ |
| FritzBox 6660 | 10.40.41.254 | WAN/Transfer | bleibt VLAN1/Transfer | 10.40.41.254 |
⬜ | wird Modem nach Bridge (TP10) |
Weitere Geräte (Home Assistant, HA-IoT, Drucker-Reservierung, etc.) hier ergänzen, sobald relevant.
Migrations-Reihenfolge & Risiko
- Unkritisch zuerst (kein Mgmt-Pfad): z.B. Mac mini, Docker-LXC-Workloads.
- NAS als zentraler Block — zieht den macvlan-Omada-Controller mit; Controller-IP-Wechsel = ich verliere kurzzeitig den Omada-Zugriff → vorher omada-mcp/Controller-Erreichbarkeit auf neue IP umstellen.
- Mgmt-Plane zuletzt (omada-mcp, pve-mcp, Controller): erst migrieren, wenn der neue Pfad verifiziert ist.
- Switch-/AP-Mgmt (VLAN99): Lockout-Risiko — VLAN muss am Port liegen + Gerät trägt es, in einem Schritt.
Abhängigkeiten
- ✅ VLAN1↔VLANx-Routing (FB-Route) · ✅ ap1-NAT-Ausnahme (inter-VLAN ohne SNAT).
- Speist den Rest des Omada-PVID-Fix (P7 macmini→INFRA, P8 NAS→INFRA, P4 nach Klärung) sowie die
DNS-
bf.lan-Aktualisierung in [project_tp4_router]-Memory. - Unabhängig von TP10/Bridge.