b93514a04524e8f8fb09efb752f6d251a5d67268
docs/routerboot-firmware-klickanleitung.md: Schritt-fuer-Schritt fuer WinBox. RouterOS ist auf allen vier bereits 7.24, nur der Bootloader haengt zurueck (core/branch 7.19.5, ap1/ap2 7.23.2 -- live erhoben). Der Weg geht per Hand, weil `/system routerboard upgrade` interaktiv nachfragt: MikroMCP blockt ihn per Deny-Policy, und Netmiko bekommt den Prompt statt einer Antwort und quittiert mit E3001 bei LEERER Fehlermeldung. Auf core/branch waere ein Scheduler-Umweg moeglich, auf den APs nicht (device-mode=home sperrt ihn). Reihenfolge ap1 -> ap2 -> core -> branch mit Ausfall je Geraet; branch zuletzt, weil der Arbeitsplatz per Kabel daran haengt. Dazu Gegenprobe-Einzeiler fuer alle vier und die Falle, dass ohne Schritt 7 (Reboot) `Current Firmware` alt bleibt. Aus der Parallelsession dazugekommen: - TP5 Etappe 3 UND 4 sind abgenommen, beide Auto-Reverts abbestellt. Die Abnahmen stehen in den Skriptkoepfen: forward-Drop hat in der Testphase 11 Pakete gefressen, ausschliesslich die eigene pve->branch:22-Sonde; beim input-Drop war es reines Broadcast-Rauschen (NetBIOS, SSDP). Der GC-Deploy-Pfad wurde als Pfadbeweis mitgetestet (nautobot-worker -> ap2:22 = SUCCESS). - E4-Nachtrag: MNDP und CAPWAP muessen in den input. Die CAPs finden ihren Manager per Layer-2-Discovery (`current-caps-man-address` ist eine MAC, keine IP) -- bestehende Sitzungen laufen ueber seal-est weiter, der Bruch schluege also erst beim naechsten AP- oder Manager-Neustart zu. - TP19 NTP: alle drei Nicht-Core-Geraete fragten einen Zeitserver, den es nicht gab (`status=waiting`, branch hatte gar keinen). ap2 war 17 Stunden nach und hat einen Logeintrag von 04:57 als 12:19 gestempelt -- geraeteuebergreifende Korrelation war damit wertlos. Core wird Zeitquelle, die drei werden Clients. - Template: `/ip service` exportiert `available-from=`, nicht `address=`. Das Soll war falsch und das Geraet hatte recht -- vier Dauer-Drifts. Und `hw-offload` fliegt aus dem Firewall-Renderer, weil REST es meldet und /export es weglaesst. 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%