admin/bf-infra
1
0
Fork 0
Code Issues 21 Pull Requests Actions Packages Projects Releases Wiki Activity
Files
main
bf-infra/docs/ip-plan.md
Christoph Emsenhuber b52d6aa49e TP45 Schicht A: Nautobot .30/.31/.32/.34 -> .154/.155/.156/.158 
Oktett-Klasse .150-.199 (App-Services). Nautobot gibt damit .30/.31 an
AGH frei. .157 ist gitea, deshalb nimmt redis .158.

- Datenmigration ueber neues nautobot/tp45-ip-move.py: Nautobot verbietet
  das Aendern einer IP nach dem Anlegen -> anlegen/primary_ip4 umhaengen/
  Altobjekt loeschen, in dieser Reihenfolge
- Stack-Redeploy (PUT /api/stacks/203), Caddy-Backend, Core-Literal *24
  ueber GC deployt (Plan 51a90e25) mit Wirksamkeitspruefung am Geraet
- caddy/deploy.sh: push_verified() ersetzt den push||push-Fallback.
  `pct push` meldet Exit 0 AUCH wenn es die Quelle nicht lesen kann, der
  Fallback griff deshalb nie und `caddy validate` pruefte die ALTE Datei
  -> gruene Abnahme bei unveraendertem Zustand (Symptom: 502 bei
  gesundem Backend)
- 39 Referenzen in 28 Dateien mitgezogen; lebende Doku nachgezogen
  (CLAUDE.md, ip-plan.md, cf-tunnel-mapping §0-Kopf, TP16.3/TP31-Prosa)
- GC-Compliance 140/140, 0 Drifts

Neue Funde (TP45-Prosa + CLAUDE.md):
- Die Core-Adressliste `nautobot` wird von GC nirgends gerendert -> ein
  Recovery von null erzeugt einen Core, in den Nautobot nicht mehr per
  SSH kommt. Gleiche Klasse wie die fehlenden DHCP-Reservierungen.
- Regel *24 (Literal) und *28 (Liste) sind Dubletten; der Literal steht
  bei 0 Paketen. Zusammenlegung bleibt offen.
- gc-manual-plan.py: /api/extras/job-log-entries/ liefert 404 (Nautobot
  3.x) -> bei gescheitertem Deploy fehlt die Fehlermeldung.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
2026-09-21 13:14:35 +02:00

8.9 KiB
Raw Permalink 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.154 | ✅ live | TP21 2026-07-16: ghcr.io/nautobot/nautobot:3.1.7, ep14 Stack Id 203, DB=platform-pg; Begleitcontainer nautobot-worker.20.155, nautobot-scheduler.20.156, nautobot-redis.20.158. TP45 Schicht A 2026-09-21: Oktett-Klasse .150–.199 (App-Services) — die alten .30–.34 gibt Nautobot an AGH .30/.31 frei |

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