Christoph Emsenhuber 92bd4aac85 TP45: pool-v20 auf .200-.249 verengt -- Schema-Baender .100-.199 freigegeben
Die 7 DHCP-Pools starteten alle bei .100 und ueberlappten damit die beiden
Oktett-Baender, die dieses TP gerade belegt: .100-.149 (Server-Hosts) und
.150-.199 (App-Services). In VLAN20 ist das eine echte Kollisionsflaeche --
nautobot .154-.158, gitea .157, pve-mcp .173 und shelly-mcp .180 tragen ihre
IP GERAETELOKAL und stehen in keinem Lease-Eintrag, der Core kann sie also
nicht schuetzen und einem DHCP-Client .154 anbieten.

Entscheid 2026-09-21: nur pool-v20 und pool-v30 werden verengt, v20 zuerst.
VLAN10/40/50/90/99 bleiben bei .100-.200 -- dort gibt es kein Schema-Band,
das etwas gewoenne, und VLAN40/VLAN10 haetten sonst 11 Sonos (.191-.201),
den iPhone (.196) und den Mac (.82) mitgezogen.

VLAN20 kostet die Verengung nichts: eine statische Reservierung (nas-bf
.20.10, in .10x) und 0 dynamische Leases.

pool-v30 bleibt bewusst unangetastet -- dort liegen 35 statische
Reservierungen IM Fenster .200-.249 (26 Shellys .202-.226/.233, SwitchBot
.227, Twinkly .228, Withings .230/.231, lichterketten .236/.237, Nuki
.241/.244, CCU .232). Erst Schicht B zieht die um, dann pool-v30.
Nebenbei faellt damit die .30.250-Kollision: der Sonoff Dongle-M sitzt dort
statisch, der Pool reicht heute bis .250.

Neuer Job `tp45-pool-v20` (gc-configplan.py) mit gezaehltem Selektor: ein
`find where`, das 0 trifft, sieht wie "nicht vorhanden" aus statt wie
"kaputt" -- ein blankes `set [find where name=...]` liefe ins Leere und der
Job meldete Erfolg.

🔴 Lehre aus dem ersten Fehlversuch: jedes config_set-Statement muss auf EINER
Zeile klammer-vollstaendig sein. Mit `:if (...) do={` am Zeilenende geht
RouterOS in den Fortsetzungs-Modus und zeigt einen anderen Prompt, der
netmiko-Treiber verliert sein Muster und der Deploy stirbt mit
`E1015: Pattern not detected: ...@crs326\-core\].*$|#.*$)` -- Plan auf
Failed, ohne etwas geschrieben zu haben.

Abnahme: Gerate-Read pool-v20 = 10.40.20.200-10.40.20.249 (total=50,
used=0); DHCPOFFER-Probe auf vmbr0.20 -> 10.40.20.200 mit
Domain Name Server 10.40.20.30, 10.40.20.31; Probe-Lease wieder entfernt;
Compliance 140/140 ohne Drift.

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

bf-infra

BF-Netzwerk-Infrastruktur (Caddy, AGH, MikroTik-Konfig, Dokumentation, MCPs). Aktiver Fork von bf-network-r6 (Claude-Code-Architektur, 2025-2026), ab August 2026 unter OpenCode und anderem LLM weitergepflegt.

Master-Struktur

Repo Rolle Stand
~/dev/bf-infra/ + admin/bf-infra (Gitea) Aktiver Master Remote seit 2026-08-30, main synchron — Backup-Lücke geschlossen
admin/bf-network-r6 (Gitea) Archiv, historischer Master read-only-Header, letzte aktive Commits 2026-08-25
admin/bf-golden-config (Gitea) Bot-Master (Nautobot 2×/Tag) intended/ + backups/, nicht manuell
admin/blaueblueten-n8n (Gitea) Master für terpene-Repo aktiv, lokal synchron

Was hier lebt

  • docs/teilprojekte.md — kanonische Steuerung (Ist-Stand, offene TPs, kritischer Pffad)
  • docs/teilprojekte-archiv.md — abgeschlossene TPs (Volltext)
  • docs/handoff-*.md — Session-Übergaben
  • caddy/Caddyfile — Reverse-Proxy BF (siehe TP34 für Migration zu Nautobot/GC)
  • nautobot/ — Skripte + Jinja-Template für Golden Config
  • mcp/ — MCP-Server-Inventar (SSoT gegen „1000 MCP-Leichen")
  • inventory/ — entfernt 2026-08-27 (Pipeline seit 2025-06 stale; Live-Daten via MikroMCP/CF/Portainer)

Status (2026-08-27)

  • L3 + WAN-Edge = crs326-core, alle 4 MikroTik auf RouterOS 7.24 (TP27)
  • Firewall deny-by-default seit 2026-08-18 (TP5)
  • WLAN via CAPsMAN auf dem Core seit 2026-08-17 (TP28)
  • Compliance 104/104 grün, 0 Drifts (Golden Config, TP22)
  • AdGuard-Paar agh-bf1/agh-bf2 aufgebaut, DHCP noch nicht umgestellt (TP23 Stufe 2 / TP31 Schritt 4)
  • Caddyfile Reverse-Proxy seit 2026-08-25 (TP31), 16 Sites BF-intern
  • terpene.teilzeitladen.xyz: Worker läuft auf Mac mini (10.40.20.167:8890), kein Caddy-Block, kein CF-Tunnel — Backfill via DB-Migration blockiert (Handoff 2026-08-27)

Übergangspfad von bf-network-r6 → bf-infra

  1. README + Strukturen aktualisiert (dieses File)
  2. bf-network-r6 im Gitea auf read-only, Header mit Verweis (deine Aktion)
  3. Inventar-Pipeline gelöscht (XLSX stale, MikroMCP/CF/Portainer liefern Live)
  4. Caddyfile-Master wandert zu Nautobot/GC (TP34, siehe Handoff 2026-08-27)
  5. bf-infra bekommt Gitea-Remote (offen, „später")

Werkzeuge (Stand 2026-08-27)

  • MikroMCP (RouterOS, 4 Geräte) — ~/.claude.json + opencode.jsonc
  • pve-mcp (Proxmox, 10.40.20.173) — opencode.jsonc
  • home-assistant (HA, 10.40.20.105) — opencode.jsonc
  • cloudflare (CF-API, OAuth) — opencode.jsonc
  • gitea-mcp (FQDN) — opencode.jsonc
  • komodo-mcp (geplant, Migration von Portainer) — ~/dev/bf-infra/mcp/komodo/
  • shelly-mcp (Client-lokal Interim, 127.0.0.1:3030) — vor Migration auf zentralen Container
Description
BF-Infrastruktur (Fork von bf-network-r6): MikroTik, Caddy, AGH, Nautobot/GC, MCPs. Master seit 2026-08-27.
Readme 21 MiB
Languages
Python 57.9%
RouterOS Script 33.8%
Jinja 6.6%
Shell 1.7%