Wir rollen Ubuntu 14.04-Server in isolierten Netzwerken aus, auf denen ntpd 4.2.6p5 ausgeführt wird und die so konfiguriert sind, dass sie mehrere von Kunden bereitgestellte NTP-Server verwenden (kein Zugriff auf pool.ntp.org). Unsere dummen Terminal-Client-Geräte verwenden eine alte Version von BusyBox (1.00-rc2) und ntpclient 2010 von Larry Doolittle.
Dieses Setup hat jahrelang großartig funktioniert, aber vor kurzem haben wir einen Roadblock mit einem neuen Kunden erreicht. Sie stellten uns 5 interne NTP-Serveradressen zur Verfügung, die ntpdate-debian
auf dem Linux-Server anscheinend hervorragend funktionieren . Auf der BusyBox-Seite ntpclient
klagt man jedoch mit "Dispersion zu hoch". ntpclient
Ruft aus der Debug-Ausgabe "1217163.1" vom NTP-Server ab, der maximal unterstützte Wert ist jedoch absolut (65536).
$ /usr/sbin/ntpclient -s -i 15 -h 10.17.162.250 -d
Configuration:
-c probe_count 1
-d (debug) 1
-g goodness 0
-h hostname 10.17.162.250
-i interval 15
-l live 0
-p local_port 0
-q min_delay 800.000000
-s set_clock 1
-x cross_check 1
Listening...
Sending ...
recvfrom
packet of length 48 received
Source: INET Port 123 host 10.17.162.250
LI=0 VN=3 Mode=4 Stratum=4 Poll=4 Precision=-20
Delay=60745.2 Dispersion=1346801.8 Refid=10.31.10.21
Reference 3668859928.942079
(sent) 3668859928.708371
Originate 3668859928.708371
Receive 3668859928.963271
Transmit 3668859928.963369
Our recv 3668859928.708371
Total elapsed: 0.00
Server stall: 93.09
Slop: -93.09
Skew: 255443.94
Frequency: 0
day second elapsed stall skew dispersion freq
42463 56728.708 rejected packet: abs(DISP)>65536
Das sind alles Geräte im selben LAN, also bin ich ehrlich gesagt verblüfft. Entsetzt sogar.
Hier ist die ntpq -pn
Ausgabe vom Ubuntu 14.04 Server:
user@host:~$ ntpq -pn
remote refid st t when poll reach delay offset jitter
==============================================================================
127.127.1.0 .LOCL. 10 l 1025 64 0 0.000 0.000 0.000
10.17.162.249 10.17.6.10 5 u 23 1024 37 0.865 1381.07 697.260
10.31.10.22 .LOCL. 1 u 1044 1024 17 29.586 -838.06 397.342
10.17.6.10 10.31.10.21 4 u 1065 1024 17 0.366 105.245 402.999
*10.31.10.21 132.246.11.238 3 u 5 1024 37 29.418 794.292 616.796
10.17.6.11 10.31.10.21 4 u 1038 1024 17 0.408 120.030 381.058
Meine Fragen sind:
- Was ist Dispersion und was kann ihren Wert verändern?
- Welche Befehle kann ich ausführen, um weitere Details von den NTP-Servern abzurufen?
- Könnte der Fehler auf der Ubuntu-Serverseite liegen, mit einem falschen
ntp.conf
? Da ist wirklich nichts Besonderes. - Würde sich in diesem Fall etwas ändern, wenn Sie zu chrony wechseln?
Antworten:
Ich sehe einige Verwirrung in den Antworten hier. Zum einen handelt es sich
ntpclient
, zumindest im-s
Modus, nicht um einen vollständigen NTP-Client, sondern es wird nur ein Paket gesendet und empfangen , sodass keine "letzten 8 Pakete empfangen" werden. Es schätzt seine eigene Streuung überhaupt nicht.Stattdessen ist der Wert, den er ausgibt, der Wert, der als "Root-Dispersion" (Rootdisp) in dem vom Server zurückgegebenen Paket bezeichnet wird. Dies ist eine Schätzung des Gesamtbetrags an Fehlern / Abweichungen zwischen diesem Server und der korrekten Zeit. Die Art und Weise, wie dies berechnet wird, ist recht einfach: Jeder NTP-Server bezieht seine Zeit entweder von einer externen Uhr (z. B. einem Radio- oder GPS-Empfänger) oder von einem anderen NTP-Server. Wenn ein Server seine Zeit von einer externen Uhr bezieht, ist seine Stammdispersion der geschätzte maximale Fehler dieser Uhr. Wenn es seine Zeit von einem anderen NTP-Server erhält, ist seine Stammdispersion die Stammdispersion des Servers plus der durch die Netzwerkverbindung zwischen ihnen hinzugefügten Dispersion.
Ein Punkt der Verwirrung ist hier, dass ntpq und chrony die Dispersion und Wurzeldispersion in Sekunden anzeigen, was die Leute gewohnt sind, aber ntpclient sie in Mikrosekunden anzeigt . Ungeachtet dessen ist ein Wert von 1217163 immer noch recht hoch. Ein guter NTP-Server kennt die Zeit innerhalb weniger Millisekunden. eine schlechte innerhalb weniger zehn oder hundert Millisekunden. Ihr sagt Ihnen, dass seine Zeit nur innerhalb von +/- 1,2 Sekunden vertrauenswürdig ist.
Sie können ntpclient tatsächlich dazu bringen, sich auf jeden Fall mit diesem Server zu synchronisieren, indem Sie die Option
-x 0
oder-t
(je nach Version von ntpclient) übergeben, wodurch die NTP-Sicherheitsprüfung deaktiviert wird. Wenn Sie nur eine annähernd genaue Zeit benötigen (auf wenige Sekunden genau), ist dies möglicherweise ausreichend. Ntpclient ist jedoch ziemlich vernünftig, wenn es sich weigert, mit einem so fehlerhaften Server zu synchronisieren. Ihrentpq
Ausgabe auf dem Ubuntu-Computer zeigt für alle Server einen Jitter von Hunderten von Millisekunden, auch wenn sie eine geringe Verzögerung aufweisen, was entweder auf ein sehr unzuverlässiges Netzwerk, eine Verschwörung aller Server hinweist , um eine fehlerhafte Zeit bereitzustellen, oder auf eine grundlegende Verzögerung Zeitnehmungsproblem auf dem Server selbst.Ich habe auch Bedenken, dass der Server 10.31.10.22 eine Refid von
LOCL
(undisziplinierte lokale Uhr) ankündigt, aber eine Schicht von 1 aufweist. In der Regel wird die lokale Uhr auf eine Schicht von 10 verfälscht, sodass sie nur als Synchronisierungsquelle der letzten Instanz verwendet wird um zu verhindern, dass eine Herde auseinander treibt. Entweder ist 10.31.10.22 falsch konfiguriert und liefert dem Rest des Netzwerks schlechte Zeit, oder es wird von einem Programm, das sich der Kontrolle von NTPLOCL
entzieht, zu guter Zeit diszipliniert. In diesem Fall ist die falsche Konfiguration einfach, dass es die Refid bewirbt. es sollte überschrieben werden, um z. B.GPS
oder was auch immer seine Zeit zur Verfügung stellt.quelle
-x 0
oder-t
und berichten. In Bezug auf10.31.10.22
, könnte ich es aus der Serverliste nehmen. Großer Fang. Ich habe keine Informationen zu diesen Servern. Gibt es noch andere Debug-Befehle, um Details von einem NTP-Server abzurufenntpq -p
?-t
vertraut der Switch trotz hoher Streuung dem internen NTP-Server. Wir können immer noch nicht erklären, warum es zufällig solche Peaks gibt, aber das ist vielleicht für einen anderen Beitrag. Vielen Dank.Nur eine Teilantwort für "Was ist Dispersion?":
Eine typische NTP-Rundreise:
Dies ergibt zwei Werte, Offset (der Zeitunterschied zwischen Client und Server) und die Verzögerung (wesentlich die Netzwerklaufzeit) mit den folgenden Formeln:
Der Client wählt den aktuellen Versatz aus den letzten 8 empfangenen Paketen aus und wählt das Paket mit der geringsten Verzögerung aus.
Dieselben 8 Pakete werden zur Berechnung der Dispersion verwendet, indem ein gewichteter Durchschnitt der Differenz dieser 8 Offsets zu dem im letzten Schritt ausgewählten Wert gebildet wird, wobei die Verzögerung als Gewichtungsfaktor verwendet wird, wodurch kleinere Verzögerungen stärker gewichtet werden. Es ist ein Maß für die "Streuung" der Werte und wird zur Berechnung der Qualität eines Zeitservers verwendet, insbesondere wenn Sie mehrere zur Auswahl haben.
quelle
offset = 1/2 * [(T2-T1) + (T4-T3)]
und "Verzögerung = (T3-T1) - (T4-T2)"t3/t4
in deiner typischen Rundreise den richtigen Ort? Die Berechnung des Verkehrsflusses und der Verzögerung scheint anzuzeigen, dass sie umgekehrt seint4 -t1
sollten : sollte die gesamte RTT sein,t3-t2
sollte die Zeit sein, die im Server verbracht wird.Ihre Streuung und Ihr Versatz sind enorm, da ein sehr großer Versatz von der lokalen Uhr zu diesem Peer besteht. Sie sollten die Offsets mit den lokalen vergleichen
date
und die Uhr manuell einstellen.Lass ntpd laufen und zeige es
ntpq -p
von einem Host unter Verwendung aller Peers. Es wird die besseren auswählen.quelle
ntpq -pn
Ausgabe zu meiner Frage hinzugefügt . Vielen Dank, dass Sie sich damit befasst haben.Laut dieser Cisco-Dokumentation ist " Dispersion , angegeben in Sekunden, der maximale Zeitunterschied, der jemals zwischen der lokalen Uhr und der Serveruhr beobachtet wurde". Bei NTP-Servern, die nicht vollständig kaputt sind, sollte niemals eine hohe Streuung auftreten. Das einzig mögliche Szenario ist, wenn Ihr Client ntp ausführt und bisher nur die lokale Uhr zur Verfügung steht. Und selbst dann entspricht eine so hohe Streuung Uhren, die um mehr als zwei Wochen verschoben sind .
Es sollte ausreichen, um sicherzustellen, dass die lokale Uhr zu Beginn nicht zu weit entfernt ist (sogar ein paar Stunden wären noch akzeptabel), entweder indem Sie die Uhr (und das Datum sogar!) Im BIOS anpassen oder indem Sie sie
ntpdate
vor dem Start einmal ausgebenntpd
auf dem Client.quelle