e17e45db91b8f41e6765da70f1c3e74e84f89e83
TP22 Schritt 5 — Datenmodell as-built aus dem Geraet erhoben (bridge/port, bridge/vlan, bridge/host + ARP/Leases), nicht aus der Doku: - crs326-core von 5 auf 26 Ports; 3 waren "GEPLANT (tentativ)", ether1 zeigte noch auf das tote sw1 #12 - Standort-Fehler: crs326-branch + ap2 standen auf Technik UG, real Technik OG - sw1/sw2/cudy2 -> Decommissioned (Endzustand), cudy1 -> Offline; sw1-Duplikat-Ports (gi*) entfernt - Schritt 4 entschieden: keine Secret-Injection (Governance-Regel 1 deckt es ab) TP21.1/4 — core ether4 geklaert und behoben: dort haengt das Wohnzimmer- Sideboard. Der Port war als ap1-Trunk vorkonfiguriert, pvid=40 nahm untagged an (Upstream ok), Egress war tagged -> TV bekam nichts. Diagnose ueber TX/RX- Asymmetrie + ARP failed bei frischem bound-Lease (ein bound-Lease beweist nur den Upstream: INIT-REBOOT-REQUEST braucht kein ACK). Auf untagged VLAN40 gezogen, Kabel bleibt auf Port 4 (Patchfeld-Nummerierung ist Infrastruktur). TP3.3 — Steering-Regression aus dem TP3-Rebuild behoben: /interface wifi steering war auf BEIDEN APs leer. 802.11r/FT macht die Uebergabe nur schnell, ausgeloest wird sie von 802.11k/v -> sticky client bis zum Abriss. st-main (rrm/wnm, neighbor-group bf-main) wiederhergestellt und ins GC-Template aufgenommen, damit eine Neuprovisionierung es nicht wieder still verliert. Compliance 20/20 -> 63/68 (dieselben 5 bekannten Altlasten): - neue Features wifi-steering, bridge-port, bridge-vlan - der L2-Layer war bisher komplett unueberwacht (core-Zweig hatte gar keine Bridge-Sektion, AP-Zweig nur VLAN ohne Ports) - Bridge-Sektionen bewusst als Literal-Block statt aus DCIM abgeleitet: pvid aus untagged_vlan zu generieren haette die akzeptierten Schiefstaende (core ether3, core ether2, branch ether9-23) zu Dauerdrift gemacht Alle Geraete-Aenderungen liefen ueber Nautobot-GC-ConfigPlans mit /system backup davor, keine Direkt-Writes. 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
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%