09cadadd334e8f3cbc5127e6aa1fa2923b116e9b
Ergebnis der read-only-Recherche-Session, hier gegengeprueft und in die kanonische Doku uebernommen. Der PSK in docs/teilprojekte-archiv.md (TP17) ist NOCH der live konfigurierte -- verifiziert am Manager per Fingerprint (Laenge + drei Zeichenpaare) statt im Klartext, damit der Wert nicht ein zweites Mal in einem Transkript landet. Das ist zugleich die Merkregel: Uebereinstimmung prueft man mit Stichproben, nicht durch Ausgeben. User-Entscheid: Historie belassen, im Nachtrag dokumentieren -- kein filter-repo. Traegt, weil es genau eine getrackte Fundstelle gibt, drei Commits, Remote nur gitea.emsenhuber.net und einen einzigen lokalen Klon; der Wert hat die eigene Infrastruktur nie verlassen. Der wirksame Schritt ist die Rotation, und die bleibt hinter TP17.1. Blast radius selbst nachgemessen (crs326-core, read-only), Peer-Zahlen bestaetigt: 26 der 27 WLAN-Clients des gesamten Netzes haengen auf dirtyvader-iot (main 1, media/untrusted/guest je 0), VLAN30 fuehrt 41 Leases/Reservierungen (5 bound). Neben den ~26 Shellys: P750W, Airfryer, SwitchBot, Twinkly, DTUBI, SONOFF-NSPanelPro, ein iPhone. Damit praezisiert sich TP17.1: nach zehn migrierten Gen4 blieben grob 16 Geraete auf dem IoT-SSID, nicht 12 -- der Funkruhe-Effekt ist real (-38 % Clients), der PSK-Effekt nur halb. Die Reihenfolge-Entscheidung bleibt richtig, ihre Begruendung wird ehrlicher. Zwei Umsetzungshinweise fuers spaetere Rotations-Paket festgehalten: migrate.py hat kein Rotate-Kommando, und ein Flag-Day ist vermeidbar ueber Passphrase-Overrides je MAC in /interface wifi access-list -- was dem TP25-Befund "keine access-list" nebenbei einen Zweck gibt. 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%