Hi!

Ich habe hier einen NTP-Server (BSD ntpd?), der stellt die Uhr nicht mehr.

Seine zwei internen Upstream NTP-Server stuft es als 16 sein, refid
steht auf INIT.

Ich hatte das schon mal gefixt, weiss aber nicht mehr wie.
Beide Upstream NTP zeigen ihre peers mit Stratum 2 an.

Einfach neustarten bringt nichts. Im Log stehen keiner Fehler.

Tim

Tim Ritberg <tim@server.invalid> wrote:
>Seine zwei internen Upstream NTP-Server stuft es als 16 sein, refid
>steht auf INIT.

Kann er diese Server erreichen? Was steht unter Reachability?

Grüße
Marc
--
----------------------------------------------------------------------------
Marc Haber | " Questions are the | Mailadresse im Header
Rhein-Neckar, DE | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402

Am 30.04.24 um 16:36 schrieb Marc Haber:
> Tim Ritberg <tim@server.invalid> wrote:
>> Seine zwei internen Upstream NTP-Server stuft es als 16 sein, refid
>> steht auf INIT.
>
> Kann er diese Server erreichen? Was steht unter Reachability?
Ja, sind im selben Netz:
remote refid st t when poll reach delay offset jitter
==============================================================================
sv1 .INIT. 16 u - 1024 0 0.000 0.000 0.000
sv2 .INIT. 16 u - 1024 0 0.000 0.000 0.000

Ich habe mal auf einem anderen Server im selben Netz gecheckt:
remote refid st t when poll reach delay offset jitter
==============================================================================
sv1 .POOL. 16 p - 64 0 0.000 +0.000 0.002
sv2 .POOL. 16 p - 64 0 0.000 +0.000 0.002
+sv1 185.252.140.126 3 u 113 1024 377 0.520 +0.110 0.103
*sv2 213.209.109.45 3 u 791 1024 377 0.289 -0.190 0.204

Mir ist aufgefallen, dass die Gegenstellen bei den verschiedenen
Linuxboxen in ntpd.conf mal als pool und mal als server stehen.

Tim

Tim Ritberg <tim@server.invalid> writes:

> Ja, sind im selben Netz:
> remote refid st t when poll reach delay offset jitter
> ==============================================================================
> sv1 .INIT. 16 u - 1024 0 0.000 0.000 0.000
> sv2 .INIT. 16 u - 1024 0 0.000 0.000 0.000

Ich würde auf dem Client mal ein tcpdump auf Port 123 mitlaufen lassen.
Entweder lange genug warten (>1024 Sekunden) oder den ntpd neu starten.
Dann mal sehen, ob da a) Pakete rausgehen und b) auch Antworten zurück
kommen, um das Problem einzugrenzen.

Lokale Firewall-Regeln gibt es keine?

> Ich habe mal auf einem anderen Server im selben Netz gecheckt:
> remote refid st t when poll reach delay offset jitter
> ==============================================================================
> sv1 .POOL. 16 p - 64 0 0.000 +0.000 0.002
> sv2 .POOL. 16 p - 64 0 0.000 +0.000 0.002
> +sv1 185.252.140.126 3 u 113 1024 377 0.520 +0.110 0.103
> *sv2 213.209.109.45 3 u 791 1024 377 0.289 -0.190 0.204

> Mir ist aufgefallen, dass die Gegenstellen bei den verschiedenen
> Linuxboxen in ntpd.conf mal als pool und mal als server stehen.

Pool heißt IMHO, dass der angegebene Name über DNS aufgelöst wird und dann
die dabei ermittelten Namen als Server genutzt werden. Das ist für
ntp.pool.org mit ständig wechselnden Servern sinnvoll und kann auch die
Last verteilen. Wenn man alle Clients und Server selber unter Kontrolle
hat, geht es eigentlich auch mit den direkt eingetragenen Servern.

--
Stefan

Am 30.04.24 um 21:08 schrieb Stefan Möding:
> Tim Ritberg <tim@server.invalid> writes:
>
>> Ja, sind im selben Netz:
>> remote refid st t when poll reach delay offset jitter
>> ==============================================================================
>> sv1 .INIT. 16 u - 1024 0 0.000 0.000 0.000
>> sv2 .INIT. 16 u - 1024 0 0.000 0.000 0.000
>
> Ich würde auf dem Client mal ein tcpdump auf Port 123 mitlaufen lassen.
> Entweder lange genug warten (>1024 Sekunden) oder den ntpd neu starten.
> Dann mal sehen, ob da a) Pakete rausgehen und b) auch Antworten zurück
> kommen, um das Problem einzugrenzen.
Nichts aber auch gar nichts in Sachen NTP.
2x DNS sieht man, wenn er die beiden internen NTP-Server auflöst beim
Restart.

>
> Lokale Firewall-Regeln gibt es keine?
nope

Tim

Tim Ritberg <tim@server.invalid> schrieb:
> Am 30.04.24 um 16:36 schrieb Marc Haber:
>> Tim Ritberg <tim@server.invalid> wrote:
>>> Seine zwei internen Upstream NTP-Server stuft es als 16 sein, refid
>>> steht auf INIT.
>>
>> Kann er diese Server erreichen? Was steht unter Reachability?
> Ja, sind im selben Netz:
> remote refid st t when poll reach delay offset jitter
> ==============================================================================
> sv1 .INIT. 16 u - 1024 0 0.000 0.000 0.000
> sv2 .INIT. 16 u - 1024 0 0.000 0.000 0.000
>
Da steht unter reach ja 0, das heisst, dass die Server bei den letzten
acht polls keine Antwort geschickt haben.

> Ich habe mal auf einem anderen Server im selben Netz gecheckt:
> remote refid st t when poll reach delay offset jitter
> ==============================================================================
> sv1 .POOL. 16 p - 64 0 0.000 +0.000 0.002
> sv2 .POOL. 16 p - 64 0 0.000 +0.000 0.002
> +sv1 185.252.140.126 3 u 113 1024 377 0.520 +0.110 0.103
> *sv2 213.209.109.45 3 u 791 1024 377 0.289 -0.190 0.204
>
Hier steht unter reach 377, das bedeutet, dass die Server bei den
letzten acht polls geantwortet haben.

11 111 111
3 7 7

NTP läuft über UDP, ist da irgendwas geblockt?

Schultze

--
/"\
\ / ASCII Ribbon Campaign
X against HTML email & vCards
/ \

Tim Ritberg <tim@server.invalid> wrote:
>Am 30.04.24 um 16:36 schrieb Marc Haber:
>> Tim Ritberg <tim@server.invalid> wrote:
>>> Seine zwei internen Upstream NTP-Server stuft es als 16 sein, refid
>>> steht auf INIT.
>>
>> Kann er diese Server erreichen? Was steht unter Reachability?
>Ja, sind im selben Netz:
>remote refid st t when poll reach delay offset jitter
>==============================================================================
>sv1 .INIT. 16 u - 1024 0 0.000 0.000 0.000
>sv2 .INIT. 16 u - 1024 0 0.000 0.000 0.000
>
>Ich habe mal auf einem anderen Server im selben Netz gecheckt:
>remote refid st t when poll reach delay offset jitter
>==============================================================================
>sv1 .POOL. 16 p - 64 0 0.000 +0.000 0.002
>sv2 .POOL. 16 p - 64 0 0.000 +0.000 0.002
>+sv1 185.252.140.126 3 u 113 1024 377 0.520 +0.110 0.103
>*sv2 213.209.109.45 3 u 791 1024 377 0.289 -0.190 0.204

Die Zahl unter "reach" musst Du als Bitvektor sehen. Eine 1 bedeutet,
der Server hat beim entspechend letzten Poll geantwortet. 377 sind nur
einsen, und zwar acht Stück, d.h. der Server war bei den letzten acht
Polls erreichbar. Eine NUll heißt, er hat achtmal nicht geantwortet.

Deine sv1 und sv2 antworten also nicht.

Warum auf dem zweiten System sv1 und sv2 zweimal in der Liste stehen,
weiß ich nicht.

Der unterschied zwischen "server" und "pool" scheint mir nach man
ntp.conf eher semantischer natur zu sein, ich verwende immer "server"
und iburst. Nachdem der einzige signifikante Unerscheid zu sein
scheint, das bei "pool" "servers", bei "server" aber der Singular
steht, hat das vielleicht was damit zu tun dass mehrere zurückgegebene
IP-Adressen bei "pool" anders behandelt werden?

Grüße
Marc
--
----------------------------------------------------------------------------
Marc Haber | " Questions are the | Mailadresse im Header
Rhein-Neckar, DE | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402

Am 30.04.24 um 21:49 schrieb Tim Ritberg:
> Nichts aber auch gar nichts in Sachen NTP.
> 2x DNS sieht man, wenn er die beiden internen NTP-Server auflöst beim
> Restart.

Anders gesagt, der ntpd geht gar nicht oder seine Pakete überleben die
iptables nicht.

Konfigurationsfehler, Hänger bei irgendetwas, was vor dem NTP-Zugriff
passieren muss oder ein Deadlock fallen mir noch ein.
So ein Hänger könnte z.B. der Zugriff auf irgendeinen Remote-Pfad (NFS)
sein, der gerade nicht erreichbar ist.

Marcel

Marcel Mueller <news.5.maazl@spamgourmet.org> wrote:
> Konfigurationsfehler, Hänger bei irgendetwas, was vor dem NTP-Zugriff
> passieren muss oder ein Deadlock fallen mir noch ein.
> So ein Hänger könnte z.B. der Zugriff auf irgendeinen Remote-Pfad (NFS)
> sein, der gerade nicht erreichbar ist.

Man könnte auch mal probieren den ntpd unter strace zu starten,
eventuell sieht man dann was.

/ralph

Am 30.04.24 um 21:08 schrieb Stefan Möding:
> Tim Ritberg <tim@server.invalid> writes:
>
>> Ich habe mal auf einem anderen Server im selben Netz gecheckt:
>> remote refid st t when poll reach delay offset jitter
>> ==============================================================================
>> sv1 .POOL. 16 p - 64 0 0.000 +0.000 0.002
>> sv2 .POOL. 16 p - 64 0 0.000 +0.000 0.002
>> +sv1 185.252.140.126 3 u 113 1024 377 0.520 +0.110 0.103
>> *sv2 213.209.109.45 3 u 791 1024 377 0.289 -0.190 0.204
>
>> Mir ist aufgefallen, dass die Gegenstellen bei den verschiedenen
>> Linuxboxen in ntpd.conf mal als pool und mal als server stehen.

Kommt drauf an was man haben möchte:
Beispiele:
server pool.ntp.org - gibt zufälligen Satz von Servern Weltweit aus
server de.pool.ntp.org - gibt zufällige Zeitserver der Länderzone 'DE'
server 1.europe.pool.ntp.org - gibt zufällige Zeitserver kontinentalen
Zeitzone 'Europa' aus.

Diese Pools ändern sich dort stündlich.[1]

server 172.16.0.55 - fragt genau diese IP ab
server ptbtime2.ptb.de - fragt z.B. den 2.Zeitserver
Physikalisch-Technischen Bundesanstalt in Braunschweig ab.

Wie schaut deine ntp.conf an der Stelle aus?

[1] www.ntppool.org
>
> Pool heißt IMHO, dass der angegebene Name über DNS aufgelöst wird und dann
> die dabei ermittelten Namen als Server genutzt werden. Das ist für
> ntp.pool.org mit ständig wechselnden Servern sinnvoll und kann auch die
> Last verteilen. Wenn man alle Clients und Server selber unter Kontrolle
> hat, geht es eigentlich auch mit den direkt eingetragenen Servern.
>

Gruß
Heiko
--
Wenn Architekten so bauen würden wie Programmierer ihre Programme machen,
könnte ein einziger Specht der vorbei kommt, die gesamte Zivilisation
zerstören...

Am 01.05.24 um 16:32 schrieb Heiko Siek:
>
> server 172.16.0.55 - fragt genau diese IP ab
> server ptbtime2.ptb.de - fragt z.B. den 2.Zeitserver
> Physikalisch-Technischen Bundesanstalt in Braunschweig ab.
>
> Wie schaut deine ntp.conf an der Stelle aus?
Ich hab den Fehler gefunden. In der Config stand noch interface ignore
wildcard.
Sein Interface ist auch ein bond, irgendwie mochte er das nicht.

Tim