4a6b1b72e1e31bd5c27f389ef0b6a5fbe6e56d6b
Alle vier Funknetze live erhoben: WLAN ap1 ch1 / ap2 ch11, Thread (OTBR) ch15, ZHA ch20, Z2M ch25. Es sind DREI 802.15.4-Netze, nicht eines -- das war in der bisherigen Planung nicht abgebildet. Befund: das Band ist gut geplant bis auf ZHA ch20 (2450), das direkt auf der Unterkante von WLAN ch11 (2451) sitzt -- ausgerechnet 52 ZHA-Geraete gegen den AP mit 26 Clients. Thread ch15 und Z2M ch25 liegen je 2 MHz ausserhalb einer WLAN-Bandkante, also sauber. Die Luecke 2423-2451 (ZB 16/17/18) ist unbenutzt, aber ein Kanalwechsel muessen 52 Geraete mitmachen -- erst Energy-Scan. Z2M-Vorbehalt aus dem 2024-Vorfall als eigenes Kapitel: die Fehlerklasse ist benennbar (Broadcast-/Routing-Sturm, trifft ZHA genauso), der Root Cause aber nicht mehr rekonstruierbar. Mitigation ohne Ursachenkenntnis = Blast Radius trennen: die zehn neuen Router komplett in EIN Zigbee-Netz, und zwar nicht in das, das Licht und Fernbedienungen traegt. Dazu einzeln joinen, Backup vorher, keine Gruppen-Bindings, Abbruchkriterium vorher festlegen. UART-Prozedur konkret dokumentiert: J6-Pinout (TXD GPIO16, RXD GPIO17, 3V3, GPIO0 als BOOT, GND), GPIO0 beim Einschalten LOW, Versorgung vom Adapter statt Netz, Geraet muss aus der Wand. Kein Reset-Knopf. Faellt einmal je Geraet an, danach alles OTA. Recovery = dasselbe rueckwaerts mit dem 8-MB-Image. Zwei Korrekturen von Christoph uebernommen: - Es gibt ZWEI Drucker. P750W = Etikettendrucker auf VLAN30 (stimmte), der eigentliche Brother MFC haengt auf VLAN10 -- live bestaetigt 10.40.10.6, OUI Brother, statisch. Auch in CLAUDE.md eingetragen, samt der Folge fuer TP5: der MFC steht im selben VLAN wie die Macs, die forward-Kette greift dort nicht. - s1/s2/s3 (weihnachten) sind in HA DEAKTIVIERT, nicht fehlend. Meine Formulierung "existieren gar nicht" war falsch -- deaktivierte Entities haben keinen Zustand. Entity-Bruch entschaerft: der Umbau behaelt die Entity-Namen (User-Entscheid). Damit faellt der teuerste Posten der Abwaegung weg, fuer Zigbee wie fuer Thread. Zwei Fallen dazu notiert (alte entity_id erst nach Entfernen frei; unique_id und Statistiken sind trotzdem neu). 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%