RouterBOOT-Klickanleitung + TP5 E3/E4 abgenommen, NTP-Zeitquelle, Template-Fixes
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>
This commit is contained in:
5
routeros/tp19-ntp-branch-client.rsc
Normal file
5
routeros/tp19-ntp-branch-client.rsc
Normal file
@@ -0,0 +1,5 @@
|
||||
# NTP-Client auf crs326-branch nachziehen. Er hatte GAR KEINEN Server
|
||||
# eingetragen (status=stopped) — die Uhr stimmte nur zufaellig noch.
|
||||
# Zeitquelle ist der Core (s. routeros/tp19-ntp-core-als-zeitquelle.rsc).
|
||||
:do { /system ntp client set enabled=yes servers=10.40.99.1 } on-error={ :log info "tp19ntp: branch warf" }
|
||||
:log info ("tp19ntp: branch status=" . [/system ntp client get status])
|
||||
34
routeros/tp19-ntp-core-als-zeitquelle.rsc
Normal file
34
routeros/tp19-ntp-core-als-zeitquelle.rsc
Normal file
@@ -0,0 +1,34 @@
|
||||
# NTP: den Core zur Zeitquelle des Standorts machen.
|
||||
#
|
||||
# BEFUND (2026-08-18, beim TP19-Abschluss gefunden):
|
||||
# ap1 ntp client -> 10.40.99.1, status=waiting, Uhr zufaellig noch richtig
|
||||
# ap2 ntp client -> 10.40.99.1, status=waiting, Uhr **17 Stunden nach**
|
||||
# branch ntp client -> gar keiner, status=stopped
|
||||
# core /system ntp server = enabled:no
|
||||
# Alle drei fragen also einen Zeitserver, den es nicht gibt ("waiting" heisst
|
||||
# genau das). ap2 ist nur der erste, der sichtbar weggelaufen ist — die anderen
|
||||
# folgen.
|
||||
#
|
||||
# WARUM DAS MEHR ALS KOSMETIK IST: Geraete-Logs sind das Hauptwerkzeug in diesem
|
||||
# Projekt (TP5 lebt vom Kollektor). Beim Pfadbeweis heute nacht hat ap2 einen
|
||||
# Logeintrag von 04:57 als "2026-08-17 12:19" gestempelt — eine Korrelation
|
||||
# ueber mehrere Geraete ist damit wertlos.
|
||||
#
|
||||
# WEG: der Core hat als einziger eine verlaessliche Zeit (WAN + DoH). Er wird
|
||||
# Server, die drei anderen bleiben/werden Clients auf 10.40.99.1. Kein Geraet
|
||||
# braucht dafuer Internet.
|
||||
#
|
||||
# ⚠️ Die input-Regel ist Pflicht: seit Etappe 4 endet `input` mit einem Drop.
|
||||
# Ohne sie waere der NTP-Server eingeschaltet und trotzdem unerreichbar —
|
||||
# derselbe stille Fehlschlag wie bisher, nur eine Ebene tiefer.
|
||||
#
|
||||
# Push: python3 nautobot/gc-manual-plan.py --device crs326-core \
|
||||
# --commands-file routeros/tp19-ntp-core-als-zeitquelle.rsc \
|
||||
# --change-id TP19-NTP --deploy \
|
||||
# --assert '/system/ntp/server|enabled=true'
|
||||
# ---------------------------------------------------------------------------
|
||||
|
||||
:do { /system ntp server set enabled=yes } on-error={ :log info "tp19ntp: 01 server warf" }
|
||||
:do { :if ([:len [/ip firewall filter find comment="TP5-E4: ntp"]] = 0) do={ /ip firewall filter add chain=input action=accept in-interface-list=LAN protocol=udp dst-port=123 comment="TP5-E4: ntp" place-before=[/ip firewall filter find comment="TP5: input log-only"] } } on-error={ :log info "tp19ntp: 02 fw warf" }
|
||||
|
||||
:log info ("tp19ntp: ENDE server-enabled=" . [:tostr [/system ntp server get enabled]] . " fw-regel=" . [:tostr [:len [/ip firewall filter find comment="TP5-E4: ntp"]]])
|
||||
14
routeros/tp5-etappe3-autorevert-abbestellen.rsc
Normal file
14
routeros/tp5-etappe3-autorevert-abbestellen.rsc
Normal file
@@ -0,0 +1,14 @@
|
||||
# TP5 Etappe 3 — Auto-Revert abbestellen.
|
||||
#
|
||||
# Der Scheduler aus tp5-etappe3-drop.rsc haette den Drop nach 10 Minuten selbst
|
||||
# wieder abgeschaltet. Die Abnahme ist durch, also wird er entfernt und der
|
||||
# Drop bleibt stehen. Abnahme am 2026-08-18 (Drop live):
|
||||
# INFRA->IOT Shelly .30.211:80 = 200
|
||||
# INFRA->WAN cloudflare.com = 301
|
||||
# INFRA->MAIN MacBook = erreichbar
|
||||
# INFRA->MGMT branch:22 von pve = ZU (korrekt: pve ist keine Mgmt-Quelle)
|
||||
# GC-Deploy nautobot-worker -> ap2:22 = SUCCESS (der Pfadbeweis)
|
||||
# Gedroppt wurden in der Testphase 11 Pakete — ausschliesslich die eigene
|
||||
# pve->branch:22-Sonde.
|
||||
:do { /system scheduler remove [find name="tp5autorevert"] } on-error={ :log info "tp5e3: abbestellen warf" }
|
||||
:log info ("tp5e3: AUTO-REVERT entfernt, drop-disabled=" . [:tostr [/ip firewall filter get [find comment="TP5: deny-by-default"] disabled]])
|
||||
13
routeros/tp5-etappe4-autorevert-abbestellen.rsc
Normal file
13
routeros/tp5-etappe4-autorevert-abbestellen.rsc
Normal file
@@ -0,0 +1,13 @@
|
||||
# TP5 Etappe 4 — Auto-Revert abbestellen. Abnahme 2026-08-18 (input-Drop live):
|
||||
# DNS aus VLAN20 an den Core core.bf.lan -> 10.40.99.1, heise.de -> 193.99.144.80
|
||||
# AGH unveraendert nas.bf.lan -> 10.40.20.10
|
||||
# MAIN->core admin 57 Pakete (MikroMCP/SSH laufen weiter)
|
||||
# HA->core api 3 Pakete
|
||||
# Die 5 mDNS-input-Regeln erstmals scharf: vlan30=87, vlan20=13 Pakete
|
||||
# (standen seit dem Bau am 2026-08-14 auf 0)
|
||||
# CAPsMAN ap1 + ap2 state=Ok
|
||||
# Gedroppt wurde ausschliesslich Broadcast-Rauschen, fuer das der Core nie
|
||||
# zustaendig war: MNDP (inzwischen explizit erlaubt), NetBIOS 137/138 aus
|
||||
# VLAN20, SSDP-Announcements einer Sonos aus VLAN40.
|
||||
:do { /system scheduler remove [find name="tp5e4autorevert"] } on-error={ :log info "tp5e4: abbestellen warf" }
|
||||
:log info ("tp5e4: AUTO-REVERT entfernt, input-drop-disabled=" . [:tostr [/ip firewall filter get [find comment="TP5: input deny-by-default"] disabled]] . " seal-lan-disabled=" . [:tostr [/ip firewall filter get [find comment="TP10-seal-lan"] disabled]])
|
||||
32
routeros/tp5-etappe4-nachtrag-discovery.rsc
Normal file
32
routeros/tp5-etappe4-nachtrag-discovery.rsc
Normal file
@@ -0,0 +1,32 @@
|
||||
# TP5 Etappe 4 — NACHTRAG: Discovery-Protokolle in den input lassen.
|
||||
#
|
||||
# BEFUND (2026-08-18, unmittelbar nach dem input-Drop):
|
||||
# Die input-Log-Regel fing MNDP-Broadcasts (udp/5678) von crs326-branch
|
||||
# (04:F4:1C:B4:15:58), ap1 (D0:EA:11:4D:40:E0/E1) und ap2 (D0:EA:11:4D:40:39/3A).
|
||||
#
|
||||
# WARUM DAS NICHT HARMLOS IST:
|
||||
# `/interface/wifi/cap` auf ap1 zeigt
|
||||
# discovery-interfaces: vlan99
|
||||
# current-caps-man-address: 04:F4:1C:B4:17:76%vlan99
|
||||
# — eine MAC, keine IP. Die CAPs finden ihren Manager also per Layer-2-Discovery
|
||||
# auf vlan99, nicht ueber eine konfigurierte Adresse. Ein Drop dieser Pakete
|
||||
# bricht die Manager-Findung. Die BESTEHENDEN CAPWAP-Sitzungen laufen weiter
|
||||
# (sie sind established und werden von TP10-seal-est akzeptiert), das Problem
|
||||
# schlaegt also erst beim naechsten AP- oder Manager-Neustart zu — genau die
|
||||
# Sorte Spaetschaden, die man im Log sehen und sofort schliessen will.
|
||||
#
|
||||
# Sicherheitlich billig: MNDP ist link-lokal (Broadcast, verlaesst das Segment
|
||||
# nicht), CAPWAP wird auf vlan99 begrenzt.
|
||||
#
|
||||
# ⚠️ place-before ist Pflicht: ein blankes `add` haengt hinter den Drop und
|
||||
# waere wirkungslos.
|
||||
# ---------------------------------------------------------------------------
|
||||
|
||||
# MNDP. Aus der LAN-Liste, weil es auch die Winbox-Neighbors-Anzeige speist und
|
||||
# als Broadcast ohnehin nicht routbar ist.
|
||||
:do { :if ([:len [/ip firewall filter find comment="TP5-E4: MNDP discovery"]] = 0) do={ /ip firewall filter add chain=input action=accept in-interface-list=LAN protocol=udp dst-port=5678 comment="TP5-E4: MNDP discovery" place-before=[/ip firewall filter find comment="TP5: input log-only"] } } on-error={ :log info "tp5e4n: 01 mndp warf" }
|
||||
|
||||
# CAPsMAN/CAPWAP, eng auf das Mgmt-VLAN begrenzt.
|
||||
:do { :if ([:len [/ip firewall filter find comment="TP5-E4: CAPsMAN capwap"]] = 0) do={ /ip firewall filter add chain=input action=accept in-interface=vlan99 protocol=udp dst-port=5246,5247 comment="TP5-E4: CAPsMAN capwap" place-before=[/ip firewall filter find comment="TP5: input log-only"] } } on-error={ :log info "tp5e4n: 02 capwap warf" }
|
||||
|
||||
:log info ("tp5e4n: ENDE mndp=" . [:tostr [:len [/ip firewall filter find comment="TP5-E4: MNDP discovery"]]] . " capwap=" . [:tostr [:len [/ip firewall filter find comment="TP5-E4: CAPsMAN capwap"]]])
|
||||
Reference in New Issue
Block a user