c9a413858b722c96beb6f788859f40b4daa0262b
TP31 -- Caddy als Reverse Proxy fuer innen UND aussen, cloudflared von sechs Containern auf einen. Anlass war Christophs Einwand, er habe den Core unter der Praemisse gekauft, dass auch die Public-Apps darueber laufen. Aktenlage geprueft: eine Zusage gibt es nicht, aber TP16.1 begruendet die Auswahl mit seinem Prinzip 'Router = einziger SPOF' -- und niemand hat je geprueft, ob der oeffentliche Strang ohne sechs Container auskommt. Keine Taeuschung, eine ungepruefte Annahme. - dst-nat-Variante geprueft und verworfen (ginge, Free-Tarif reicht), weil Christophs Tunnel-Variante drei Risiken spart: keine angreifbare Origin-IP, keine CF-IP-Allowlist, kein DDNS als Voraussetzung - cloudflared auf ap1/ap2: live gemessen arm64, 95 MB Flash frei, 690 MB RAM frei. Der Core kann es nie (arm 32-bit, 2,9 MB frei) - Kriterium fuer Infrastruktur-Container: was sich selten aendert und wenig schreibt. Caddy nein (Config aendert staendig), AGH nein (Query-Log frisst NAND) TP32 -- VMID-Systematik (Hunderter = Klasse, gemeinsamer Raum fuer VMs und LXCs) + letztes Oktett je /24, uebertragbar auf andere Standorte. 🔴 Dabei gefunden und SOFORT REPARIERT: die Startreihenfolge war falsch. Proxmox startet erst Gaeste mit explizitem startup order=, dann den Rest nach VMID -- drei Gaeste hatten einen, die DBs nicht. Home Assistant startete damit vor MariaDB, MQTT und z2m25. Jetzt fuenf Stufen (Core/Daten/Platform/Broker/Apps). Erkenntnis: VMID = Klassifikation, startup order = Abhaengigkeit -- die Umnummerierung muss den Startlauf gar nicht reparieren. Doku-Korrekturen aus den Messungen: - CLAUDE.md: 'Container NICHT auf dem Router' war nie nachgemessen - tp16.1: 'Connector als Container ❌' galt dem TUN-Bedarf des WARP-Connectors; cloudflared braucht kein TUN - cf-tunnel-mapping Paragraph 16: die macvlan-Blindheit war mit einem Shim behebbar -- der Workaround war groesser als der Fix Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
docs 🧭 Governance „Config nur via Nautobot" + TP19.1-Stand (ap1-DNS ✅, ap2 vertagt), sw2-IP-Korrektur .41.181, VLAN99-Cutover-Guides sw1/sw2, TP15-Lieferung 17.07., TP20 an Komodo gebunden
bf-network-r6
BF-Netzwerk-Migration (Variante R6+C2). 2× MikroTik hAP ax² + Core ALL-SG8316M.
SSOT & Übergabe: HANDOVER.md — kompletter Status, Architektur + Begründungen, Phasen, Gotchas, Zugänge.
Plan-Origin: ~/.claude/plans/welche-kosteng-nstigen-alternativen-zu-memoized-sparkle.md
Struktur:
docs/vlan-plan.md— VLAN-/Adressplan (final)docs/core-switch-prep.md— Core-Switch Status & Phasendocs/firmware-flash-runbook.md— FW-Flash Historieswitch/cli/CLI-REFERENCE.md— bestätigte CLI-Syntaxswitch/cli/*.cli/*.exp— reproduzierbare Konfig-Scriptsinventory/bf.csv/bf.md— IP-Doku (aus IPs.xlsx gespiegelt)inventory/bf-core-ports.csv/.md— Switch-Port-Map
Aktueller Stand (2026-06-09):
- Phase A (VLAN-Vorbereitung) ✅ abgeschlossen
- Phase B (hAP-Cutover) ⏳ wartet auf MikroTik-Lieferung
- Phase C (Firewall) + Phase D (Adress-Migration) ausstehend
Description
BF-Infrastruktur (Fork von bf-network-r6): MikroTik, Caddy, AGH, Nautobot/GC, MCPs. Master seit 2026-08-27.
Languages
Python
57.9%
RouterOS Script
33.8%
Jinja
6.6%
Shell
1.7%