NTP: Wurzel war der Core selbst, plus eine fehlende Compliance-Rule

Der Core hatte keinen eigenen NTP-Client bei use-local-clock=no. Ein Server
ohne Synchronisation liefert Stratum 16, das jeder Client verwirft -- die
Anfragen kamen an und wurden trotzdem nicht brauchbar beantwortet. Der
Standort hatte an keiner Stelle eine funktionierende Zeitsynchronisation.

Notiert ist auch, dass /system ntp gar keine Compliance-Rule hat -- derselbe
blinde Fleck, den TP26 fuer /ip firewall filter geschlossen hat.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

docs/teilprojekte.md

@@ -687,6 +687,21 @@ FT kaschierte das bisher als „Roaming" statt „schwache Abdeckung".
   (`routeros/tp19-ntp-core-als-zeitquelle.rsc`, inkl. der noetigen `input`-Regel — ohne die waere der
   Server seit Etappe 4 eingeschaltet und trotzdem unerreichbar gewesen), branch ist Client
   (`routeros/tp19-ntp-branch-client.rsc`).
+  - 🔎 **Die Wurzel lag eine Ebene tiefer:** auch der Core hatte **keinen** NTP-Client
+    (`enabled: no`, keine Server) bei `use-local-clock: no`. Ein Server ohne eigene Synchronisation
+    liefert Stratum 16, das jeder Client verwirft — die Anfragen kamen also an (die Firewall-Regel
+    zaehlte) und wurden trotzdem nicht brauchbar beantwortet. Der Standort hatte damit **an keiner
+    Stelle** eine funktionierende Zeitsynchronisation; dass drei von vier Uhren stimmten, war
+    Restglueck vom letzten manuellen Stellen. Behoben mit `routeros/tp19-ntp-core-client.rsc`
+    (`time.cloudflare.com,at.pool.ntp.org`) → Core `synchronized`.
+  - ⏳ **Rest:** ap1/ap2/branch stehen weiterhin auf `status=waiting`, obwohl der Core jetzt eine
+    gueltige Quelle ist. ap2s Uhr wurde einmalig von Hand gestellt (17 h Versatz liegt ueber der
+    NTP-Panic-Schwelle, so weit springt ein Client nicht von selbst) — **alle vier Uhren stimmen
+    jetzt**, das Einrasten der Clients ist nachzukontrollieren.
+  - ⚠️ **Governance-Luecke, die dabei auffiel: `/system ntp` hat GAR KEINE Compliance-Rule.**
+    Die NTP-Konfiguration ist nicht drift-ueberwacht — exakt der Zustand, den **TP26** fuer
+    `/ip firewall filter` behoben hat. Gehoert nachgezogen, sonst faellt die naechste stille
+    Aenderung wieder erst ueber falsche Zeitstempel auf.
 - ✅ **Live-Nachprüfung 2026-08-16 (MikroMCP + CF-API, reine Reads):**
   - **`cudy1` ist tot, nicht nur „offline gemeldet":** `core ether11` steht auf `running=false`, **letzter Link-Down 2026-08-08 19:33**, seither kein Link. Die Formulierung „aktiver VLAN1-Leak" ist damit endgültig hinfällig — der **Dual-DHCP-Race hat keine Quelle mehr**. Offen bleibt nur der *physische* Ausbau + Inventar/Doku.
   - **`crs326-core` hat keine VLAN1-IP mehr:** `/ip/address` listet nur noch die 7 SVIs + die WAN-DHCP-Adresse — die **Bring-up-Altlast `10.40.41.211` ist weg**. Damit fällt einer der 5 Compliance-Drifts aus TP22 raus, *sobald* wieder **Backup → Intended → Compliance** gelaufen ist (die Compliance vergleicht gegen das letzte Backup, nicht gegen das Gerät — s. TP22-Falle).

routeros/tp19-ntp-ap-neustart.rsc

@@ -0,0 +1,9 @@
+# NTP-Client auf dem AP neu anstossen.
+#
+# Beide APs zeigen seit jeher auf 10.40.99.1 und standen deshalb dauerhaft auf
+# `status: waiting`. Ein Client, der lange erfolglos war, verlaengert seine
+# Wartezeit — er merkt also nicht von selbst zeitnah, dass der Core seit
+# 2026-08-18 tatsaechlich Zeit liefert. Aus/ein setzt den Zustand zurueck.
+:do { /system ntp client set enabled=no } on-error={ :log info "tp19ntp: ap-off warf" }
+:do { /system ntp client set enabled=yes servers=10.40.99.1 } on-error={ :log info "tp19ntp: ap-on warf" }
+:log info ("tp19ntp: ap-client status=" . [/system ntp client get status])

routeros/tp19-ntp-core-client.rsc

@@ -0,0 +1,18 @@
+# NTP, zweiter Teil: der Core braucht selbst eine Zeitquelle.
+#
+# BEFUND (2026-08-18, nach dem Einschalten des Servers): die Anfragen der APs
+# kommen an (Firewall-Regel zaehlt), der Core antwortet aber nicht brauchbar —
+# `/system ntp client` ist **enabled: no**, ohne Server, `status: stopped`, und
+# `/system ntp server` steht auf `use-local-clock: no`. Ein NTP-Server, der
+# selbst nicht synchronisiert ist, liefert Stratum 16; Clients verwerfen das
+# und bleiben genau da stehen, wo ap1/ap2 stehen: `waiting`.
+#
+# Damit ist die Kette vollstaendig: der Standort hatte **an keiner Stelle** eine
+# funktionierende Zeitsynchronisation. Dass die Uhren von core/branch/ap1
+# trotzdem stimmten, war Restglueck vom letzten manuellen Stellen — ap2 ist
+# einfach als erstes weggelaufen (17 h).
+#
+# Upstream ueber Namen ist unproblematisch: der Core loest seit TP23 Stufe 1
+# selbst per DoH auf.
+:do { /system ntp client set enabled=yes servers=time.cloudflare.com,at.pool.ntp.org } on-error={ :log info "tp19ntp: client warf" }
+:log info ("tp19ntp: core-client status=" . [/system ntp client get status])