da452ce1f3cb85d50d1bf7e93845dfa2661318ce
Drei Skripte aus der Folgesession. Stand am Geraet zum Commit-Zeitpunkt (per REST gegengeprueft, nicht aus den Dateikoepfen abgeschrieben): - tp23-stufe1-doh-core.rsc -> LIVE. use-doh-server auf den Cloudflare-Gateway-Resolver, verify-doh-cert=true. Nur der GTS Root R4 importiert statt eines Bundles: der Core hat ~2,8 MB freien Flash, und die Kette endet nachweislich dort. Der Root wurde per SFTP hochgeladen, nicht per fetch geholt -- fetch haette check-certificate=no gebraucht und damit genau die Pruefung ausgehebelt, die hier aufgebaut wird. Schliesst zugleich TP21.1 TODO 1. - tp5-etappe2-nachtrag.rsc -> LIVE. 17 TP5-E2-Whitelists (11 + 6). Vier Luecken, die der Kollektor ueber dreieinhalb Stunden gezeigt hat: Matter (udp/5540, 92 der 119 Zeilen -- die E2-Regel war protocol=tcp und liess Matter komplett durchfallen), der Nautobot-Deploy-Pfad (kommt von .20.31 = worker, nicht von .20.30 = web; jetzt als address-list, weil der scheduler dieselben Jobs faehrt), und zwei Rueckwege aus abgelaufenen Conntrack-Eintraegen. Dazu eine Vorratsregel fuer AdGuard, damit das spaetere DNS-Umstellen ein reiner DHCP-Change bleibt. Korrigiert meine Aussage vom Vortag: "die Log-Regel ist verstummt" beruhte auf einem 70-Sekunden-Fenster und war so nicht haltbar. Genau deshalb verlangt das Runbook ein mehrtaegiges Fenster. - tp5-etappe3-drop.rsc -> VORBEREITET, NICHT AUSGEROLLT. Kein Drop und kein Scheduler auf dem Geraet. Der Auto-Revert steht im Skript bewusst VOR dem Drop, sonst gibt es ein Fenster ohne Sicherung; der Drop kommt HINTER die Log-Regel, damit der Kollektor weiter sieht, was gefressen wird. Gate fuer Etappe 3: die Log-Regel steht aktuell auf 0 Paketen. 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%