Christoph Emsenhuber
5cc62b29c1
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>
19 lines
1.1 KiB
Plaintext
19 lines
1.1 KiB
Plaintext
# 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])
|