admin/bf-infra
1
0
Fork 0
Code Issues 21 Pull Requests Actions Packages Projects Releases Wiki Activity
Files
5ee0716dda7d415c3ceed28ded8d18459d538faa
bf-infra/docs/ip-plan.md

8.8 KiB
Raw Blame History

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.

✅ Migration abgeschlossen (Stand 2026-08-19) — dieses Dokument ist Historie

Lies zuerst das hier, nicht die Tabelle. Der Plan ist umgesetzt; die Tabelle unten ist das Arbeitsblatt von damals und bleibt bewusst erhalten (Konvention: fortschreiben, nicht überschreiben). Mehrere ihrer Zeilen beschreiben eine Topologie, die es seit 2026-08-08 nicht mehr gibt — insbesondere „ap1 = Router/GW" und sw1 als lebendes Gerät.

Kanonischer Ist-Stand: docs/teilprojekte.md (Ist-Stand-Block) und CLAUDE.md.

Wie es heute wirklich aussieht:

Rolle Gerät Adresse
L3-Router + WAN-Edge + DHCP/DNS/NTP/WG-Hub crs326-core GW .1 je VLAN, Mgmt-SVI 10.40.99.1, WAN vlan100
L2-Switch Technik OG crs326-branch 10.40.99.2
AP (reiner CAP unter CAPsMAN) ap1 10.40.99.11
AP (reiner CAP unter CAPsMAN) ap2 10.40.99.12
ALLNET sw1 — ❌ ausgebaut 2026-08-08
Omada sw2 — ❌ ausgebaut 2026-07-23
FritzBox 6660 — ❌ ausgebaut 2026-07-01 (Arris im Bridge-Mode)

Was daraus für die Tabelle folgt: die Zeilen ap1 / ap2 / sw1 / crs326-* stehen unten noch mit den damals geplanten Werten und ⬜-Status. Sie sind erledigt bzw. gegenstandslos — die Marker sind 2026-08-19 nachgezogen, die ursprüngliche Planung bleibt darunter lesbar.

Ebenfalls überholt: die Konventionszeile „GW je VLAN = .1 (ap1)" und der Arbeitsschritt „(3) DNS bf.lan-Eintrag auf ap1 updaten" — beides ist seit dem Core-Cutover Sache von crs326-core. VLAN1 existiert seit TP19 (2026-08-18) gar nicht mehr als Client-Netz, die Spalte „aktuell (VLAN1)" ist damit reine Herkunftsangabe.

Konventionen

  • Host-Oktett möglichst beibehalten (weniger Churn in DNS/Configs): z.B. NAS .10 → 10.40.20.10.
  • GW je VLAN = .1 (ap1 crs326-core, seit 2026-08-08). 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 crs326-core updaten, (4) Reachability prüfen.

Geräte-Tabelle (Vorschlag → bestätigen)

Gerät aktuell (VLAN1) Rolle Ziel-VLAN Vorschlag IP bestätigt Notizen
ap1 (hAP ax²) 10.40.41.1 Router/GW → reiner AP (CAP) 99 MGMT bleibt .1 je VLAN; Mgmt 10.40.99.1 → 10.40.99.11 ✅ erledigt, anders als geplant ⚠️ Rolle seit 2026-08-08 auf crs326-core (TP21.1) — kein DHCP/DNS/NAT/WG mehr. Seit TP28 (08-17) reiner CAP unter dem Manager auf dem Core
ap2 (hAP ax²) 10.40.41.2 AP (CAP) 99 MGMT 10.40.99.2 → 10.40.99.12 ✅ live TP19.1 2026-08-14 (Mgmt-Cutover); .99.2 ging an crs326-branch. Uplink an branch ether24
sw1 ALLNET (Core) 10.40.41.11 — — — ❌ ausgebaut 2026-08-08 durch crs326-core ersetzt, physisch entfernt. Die hier geplante .99.11 ging an ap1. Telnet-Runner unter switch/ = Archiv
sw2 Omada (ES208G) — — — — ❌ abgebaut TP15 2026-07-23: physisch entfernt, durch crs326-branch ersetzt (Technik OG)
crs326-branch (CRS326) 192.168.88.1 (Werk) L2-Switch (Technik OG) 99 MGMT 10.40.99.13 (Ziel .99.12) → 10.40.99.2 ✅ live TP15 2026-07-23: ersetzt sw2. ⚠️ Anders gekommen als geplant. Uplink ether1 → crs326-core ether8 (nicht mehr sw1). Bring-up-Reste .41.213 + SVI vlan10 entfernt 08-16
crs326-core (CRS326) 192.168.88.1 (Werk) L3-Router + WAN-Edge (Technik UG) 99 MGMT + GW je VLAN 10.40.99.11 → 10.40.99.1 + .1 in jedem VLAN ✅ produktiv TP21.1 2026-08-08: Cutover vollzogen, ersetzt ap1 als L3. Routing/DHCP (7 Server)/DNS (DoH)/NAT/NTP/WG-Hub. WAN vlan100 = Liwest 90.146.33.177. VLAN1-Temp .41.211 entfernt
NAS nas-bf (DS923) 10.40.41.10 INFRA 20 INFRA 10.40.20.10 ✅ live TP14.1 2026-07-10; DNS nas.bf.lan nachgezogen 2026-07-16
Omada-Controller — Service (macvlan/DS923) — — ❌ entfernt User hat den Container 2026-07-16 gelöscht (overkill für 1 Switch auf der Abschussliste, s. TP2.1/TP15). DNS-Eintrag omada.bf.lan entfernt
omada-mcp — Service (pve-LXC) — — ❌ entfernt mit dem Controller zusammen gelöscht 2026-07-16 (MCP-Server verwaist, in Claude-Settings noch registriert — Aufräumen offen). DNS-Eintrag omada-mcp.bf.lan entfernt
pve-mcp 10.40.20.173 Service (pve) 20 INFRA 10.40.20.173 ✅ live TP14.1; NAS-Stack (vlan20-only)
Docker-LXC 10.40.20.126 Docker-Host (pve) 20 INFRA 10.40.20.126 ✅ live TP14.2 2026-07-10: LXC 400 net0 tag=20; Docker vlan20=ipvlan parent veth20
Proxmox pve 10.40.20.100 Hypervisor+INFRA 20 INFRA 10.40.20.100 ✅ live TP14 2026-07-13: vmbr0.20 Host-IP + Default-GW-Flip, SSH-Key ✓, ap1-DNS+CF-Ingress(bf-pve) nachgezogen; .41.100 bleibt interim ohne Route (wie sw1/sw2/ap2-Mgmt)
Mac mini 10.40.41.167 INFRA/Server 20 INFRA 10.40.20.167 ✅ live umgezogen. ⚠️ Die alte .41.167 geisterte bis 2026-08-16 in CLAUDE.md — dort korrigiert. Portangabe „Omada P7" ist Historie (sw2 ausgebaut)
FritzBox 6660 — WAN/Transfer — — ❌ physisch entfernt Liwest-Kabelmodemtausch 2026-07-01 (Edge-Cutover), kein Zurück — Arris-Kabelmodem im Bridge-Mode ersetzt sie komplett

| platform-pg (LXC 105, pve) | — (neu) | Platform-Postgres (TP20), PG16, DB nautobot | 20 INFRA | 10.40.20.20 | ✅ live | TP20 2026-07-16: erstellt via pct create, Ubuntu 24.04 (native PG16, kein PGDG-Repo nötig), UTF8/en_US.UTF-8, wal_level=replica, archive_mode bewusst noch aus (s. Memory) bis pgBackRest/Garage-S3 da ist; Creds postgres/.secrets | | nautobot (Portainer-Stack, NAS) | — (neu) | Nautobot Golden Config (TP21), App/API | 20 INFRA | 10.40.20.30 | ✅ live | TP21 2026-07-16: ghcr.io/nautobot/nautobot:3.1.7, ep14 Stack Id 203, DB=platform-pg; Begleitcontainer nautobot-worker.20.31, nautobot-scheduler.20.32, nautobot-redis.20.34 |

Weitere Geräte (Home Assistant, HA-IoT, Drucker-Reservierung, etc.) hier ergänzen, sobald relevant.

Migrations-Reihenfolge & Risiko

Phase 1 — INFRA, sofort möglich (✅ Mac mini schon live)

  1. Proxmox pve → 10.40.20.100 (Hypervisor, kein Lockout-Risiko, Management per SSH/Web).
  2. Docker-LXC → 10.40.20.126 (Portainer-Host auf pve, folgt pve).
  3. pve-mcp → 10.40.20.173 (pve-LXC, folgt pve; MCP-URL in ~/.claude/settings.json updaten).
  4. omada-mcp → 10.40.20.176 (pve-LXC, folgt pve; MCP-URL in ~/.claude/settings.json updaten).

Phase 2 — MGMT-Plane, Lockout-Risiko (nach Phase 1, VLANs verifiziert)

  1. ap2 → 10.40.99.2 (hAP #2 Mgmt-IP; VLAN99 muss am Port sitzen, in einem Schritt).
  2. sw2 Omada (ES208G) → 10.40.99.12 (Controller-Config + Port-VLAN in einem Schritt).
  3. sw1 ALLNET → 10.40.99.11 (Telnet-CLI, risikoreichstes Gerät — zuletzt in dieser Phase).

Phase 3 — Geblockt auf CF Zero Trust + TP10

  1. NAS nas-bf (DS923) → 10.40.20.10
    • Voraussetzung 1: CF Zero Trust auf neue Ziel-Struktur (VLAN20-Subnetze, neue IPs) angepasst.
    • Voraussetzung 2: TP10 abgeschlossen (VPN-Tunnel 2× WG auf ap1; FB kann Bridge-Mode gehen).
  2. Omada-Controller → 10.40.20.175 (macvlan auf DS923 → folgt automatisch mit NAS; kurz Mgmt-Downtime).

Phase 4 — nach TP10

  1. FritzBox 6660 → Bridge-Mode (wird zum reinen Modem; IP 10.40.41.254 entfällt als GW).

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.
  • NAS + Controller: geblockt auf CF Zero Trust + TP10 (User-Entscheid 2026-06-16).
Reference in New Issue View Git Blame Copy Permalink