admin/bf-infra
1
0
Fork 0
Code Issues 21 Pull Requests Actions Packages Projects Releases Wiki Activity
Files
777ac95c3f3f6bf4a3adffd16d06b2a72ee0a9ac
bf-infra/docs/ip-plan.md
Christoph Emsenhuber b595c75eef TP15: CRS326-Bring-up (core+branch) + Branch-Tausch gegen sw2 durch 
- Beide CRS326 grundkonfiguriert via REST (Governance-Ausnahme #2): core-zuerst
  als L2-Pfad, Zugriff auf Werks-.88.1 über temporäre ap1-.88.2+Masquerade
  (nach Bring-up entfernt). Winbox-MAC scheiterte (sync-timeout).
- branch produktiv, volle SOLL-Portbelegung (ether1 Uplink→sw1#8, 2/8 NAS-20T,
  3 Drucker/4 Dock VLAN10, 5/6 Sonos VLAN40, 7 macmini VLAN20, 24 ap2), mgmt
  .99.13; core grundkonfiguriert nicht produktiv (mgmt .99.11, an sw1#12).
- Branch-Tausch: sw2 physisch raus, Lifelines auf branch; Abnahme grün (NAS/
  macmini VLAN20, Dock VLAN10, Sonos VLAN40). Gotcha: ether3/5-Kabel vertauscht
  (Sonos-VLAN10-Leck/Dual-Homing) → gefixt.
- Nautobot modelliert + GraphQL-verifiziert (nautobot/ingest-crs326-ports.py):
  branch Active + Ports, core Planned + tentativ, sw1 verifizierte 16-Port-
  Belegung (löst UNVERIFIZIERT), sw2 Decommissioning.
- CRS326 in MikroMCP routers.yaml; Creds in ~/.secrets. Doku (teilprojekte/
  CLAUDE/ip-plan) nachgezogen; Core-Swap-Handoff-Prompt neu.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-23 16:20:26 +02:00

6.2 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.

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) — — — — ❌ abgebaut TP15 2026-07-23: physisch entfernt, durch crs326-branch ersetzt (Technik OG)
crs326-branch (CRS326) 192.168.88.1 (Werk) Switch-Mgmt (Technik OG) 99 MGMT 10.40.99.13 (Ziel .99.12 nach Core-Tausch) ✅ live TP15 2026-07-23: ersetzt sw2; Bring-up-VLAN1-Temp .41.213; über sw1 #8
crs326-core (CRS326) 192.168.88.1 (Werk) Switch-Mgmt/künftig L3-Router (Technik UG) 99 MGMT 10.40.99.11 🟡 grundkonf. TP15 2026-07-23: grundkonfiguriert, nicht produktiv (ersetzt sw1, eigene Session); VLAN1-Temp .41.211, an sw1 #12
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; Omada P7 + Access-INFRA (VLAN20, ohne VLAN1) ✅
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