Ich habe gerade durch Zufall bemerkt, dass bei einem meiner Cisco 4500-Switches die Uhr falsch läuft: Trotz scheinbar funktionierendem NTP liegt er mehr als 2 Minuten zurück . Meiner Meinung nach sollte nicht einmal eine Sekunde für die beteiligten Systeme als akzeptabel angesehen werden. Außerdem hätte ich den Unterschied zur Diagnose nicht bemerkt, wenn ich ihn nicht mit einer einfachen Wanduhr verglichen hätte.
Ein paar Details
Hier sind NTP-Informationen für einige meiner Hosts (10.0.99.1, 10.0.99.2, 10.0.1.119, 10.0.99.241), die sich teilweise gegenseitig auf Fallback verweisen, aber hauptsächlich alle letztendlich durch Synchronisierung mit 10.0.0.1, was wiederum das zieht Zeit von außen. Die Zeitdiskrepanz kann also nicht aus verschiedenen ursprünglichen Zeitquellen resultieren. Da die Beobachtungen mich etwas paranoid gemacht haben, hat "die richtige Zeit" auf folgende Weise: show clock(oder date) eine Ausgabe erzeugt, die mit meiner Wanduhr und meiner lokalen Systemuhr (die laut http://time.is in Ordnung ist ) übereinstimmt Ein Fehler, der sicherlich unter 1 Sekunde liegt (Genauigkeit, wenn ich beim Beobachten meiner lokalen Uhr die EINGABETASTE drücke)
10.0.1.119 (Ubuntu) hat die richtige Zeit
$ ntpq -np
remote refid st t when poll reach delay offset jitter
==============================================================================
+10.0.99.1 10.0.0.1 3 u 855 1024 377 0.904 -2.658 0.113
*10.0.0.1 130.149.17.8 2 u 266 1024 377 0.253 0.909 0.127
10.0.99.241 (Cisco 2960) hat die richtige Zeit
#sho ntp associations
address ref clock st when poll reach delay offset disp
*~10.0.99.1 10.0.0.1 3 28 64 377 1.462 85.288 19.758
+~10.0.99.2 10.0.1.119 4 29 64 377 1.297 83.515 5.369
* sys.peer, # selected, + candidate, - outlyer, x falseticker, ~ configured
10.0.99.2 (Cico 4500) hat die richtige Zeit
#sho ntp associations
address ref clock st when poll reach delay offset disp
+~10.0.99.1 10.0.0.1 3 6 1024 111 1.148 -1.618 42.875
*~10.0.1.119 10.0.0.1 3 31 1024 377 0.043 1.687 1.064
* sys.peer, # selected, + candidate, - outlyer, x falseticker, ~ configured
10.0.99.1 (Cisco 4500) liegt etwa 2 Minuten 6 Sekunden zurück
#sho ntp associations
address ref clock st when poll reach delay offset disp
*~10.0.0.1 130.149.17.8 2 274 1024 377 15.625 3.681 30.403
+~10.0.99.2 10.0.1.119 4 415 1024 376 15.625 0.855 33.276
* sys.peer, # selected, + candidate, - outlyer, x falseticker, ~ configured
#sho ntp status
Clock is synchronized, stratum 3, reference is 10.0.0.1
nominal freq is 250.0000 Hz, actual freq is 249.9988 Hz, precision is 2**6
reference time is DAD8B428.54C6BAEA (20:36:24.331 MESZ Sat May 7 2016)
clock offset is 3.6818 msec, root delay is 32.80 msec
root dispersion is 71.74 msec, peer dispersion is 30.40 msec
loopfilter state is 'CTRL' (Normal Controlled Loop), drift is 0.000004720 s/s
system poll interval is 1024, last update was 683 sec ago.
Fragen
- Wie kommt es, dass 10.0.99.1 so weit weg ist?
- Wie kommt es, dass Systeme, die mit 10.0.99.1 synchronisiert werden, korrekt sind?
- Wie soll ich aus der Ausgabe von
sho ntp status10.0.99.1 lernen, dass die Uhr tatsächlich völlig nicht synchron ist (im Vergleich zu allen in erwähnten Hosts und Referenzuhrensho ntp asso)? Für mich sieht die Ausgabe wie ein sehr aufwändiges "Ich bin total glücklich" aus.
EDIT: Auf vielfachen Wunsch wird die Ausgabe vonsho clock detail
10.0.99.1
#sho clock detail
13:06:38.605 MESZ Tue May 10 2016
Time source is NTP
Summer time starts 02:00:00 MEZ Sun Mar 27 2016
Summer time ends 03:00:00 MESZ Sun Oct 30 2016
10.0.99.2
#sho clock detail
13:10:54.083 MESZ Tue May 10 2016
Time source is NTP
Summer time starts 02:00:00 MEZ Sun Mar 27 2016
Summer time ends 03:00:00 MESZ Sun Oct 30 2016
quelle
10.0.0.1). Ich glaube jedoch nicht, dass eine meiner Beobachtungen die Ursache Ihres aktuellen Problems direkt erklären kann.Antworten:
Ich zögere etwas, dies als Antwort zu posten, da die ursprüngliche Ursache noch unklar ist. Trotzdem scheint das Problem gelöst zu sein - zumindest für den Moment.
Nach den Kommentaren von htm11h habe ich beschlossen, die Firmware zu aktualisieren. Und tatsächlich scheint die Uhr jetzt, da ich mit einer neueren Firmware arbeite, mit der richtigen Zeit übereinzustimmen.
Aber heißt das, dass die neue Firmware die Lösung war? Unglücklicherweise nicht. Bei meinem ersten Versuch, die neue Firmware zu laden, habe ich vergessen, das Konfigurationsregister zu ändern, das noch auf der Werkseinstellung war. Daher endete mein erster Neustart in demselben ursprünglichen ROM-Image, das der Router seit fast vier Jahren (dh seit seinem ersten Einschalten) ausgeführt hatte. Und doch war dies ausreichend, damit die Uhr eine große Anpassung vornehmen und dann synchron bleiben konnte. Dies deutet darauf hin, dass ein bloßer Neustart möglicherweise vorübergehend geholfen hat. Dies bedeutet wiederum, dass die jetzt korrekte Zeit, die mit der neueren Firmware angezeigt wird, in den kommenden Jahren möglicherweise immer noch von der NTP-Zeit abweicht. Es wird einige Tage dauern, bis ich sicher feststellen kann, ob die Uhr etwa 5 Sekunden pro Tag verloren hat oder nicht ...
Im Moment ist der Fall abgeschlossen.
quelle
Ich habe seit Mitte der 90er Jahre ziemlich viel mit dem NTP-Pool-Projekt gearbeitet und hier mehrere NTP Stratum-1 GPS-synchronisierte Server ausgeführt. Wie andere angegeben haben, benötigen Sie mehr als 2 Server, um Zeit zu erhalten. Normalerweise verwende ich hier 4 aus den oben von Ron Maupin genannten Gründen. Wie aufgelistet, müssen Sie auch nach Schleifen Ausschau halten und Dinge als Server gegen Peers einstellen.
Die Zeitverschiebung könnte auf einen bekannten Fehler in IOS zurückzuführen sein, der in diesem IOS-Update behoben wurde, der darauf zurückzuführen ist, dass ntp.drift nicht korrekt gelöscht oder aktualisiert wurde, und somit auf das Driftproblem. Auch 4 JAHRE ohne Neustart oder Update müssen Sie in Bezug auf die Sicherheit ziemlich schlecht gestellt haben, da IOS-Sicherheitsupdates ziemlich häufig veröffentlicht werden.
Hier ist ein ausgezeichneter Beitrag zum Einrichten von NTP unter Cisco IOS: http://packetlife.net/blog/2011/mar/28/cisco-ios-clocks-and-ntp/
Hoffe das ist hilfreich. Bitte fragen Sie, wenn Sie weitere Fragen oder Probleme haben.
quelle
Vollständige Offenlegung: Ich habe nur gelegentlich mit Switch-Konfigurationen herumgespielt und bin keineswegs ein NTP-Experte.
Trotzdem habe ich gesehen, dass der NTP-Daemon auf RHEL 5.x-Systemen (ja, ich gehe zurück, aber Sie haben gesagt, Ihr Switch hatte ein ~ 4 Jahre altes Image ...) in einem "glücklichen" Zustand stecken geblieben ist , wo es zu denken schien, dass es perfekt synchronisiert war, aber eindeutig nicht. Wir würden eine ClusterSSH-Sitzung verwenden, um "Datum" auf allen Systemen gleichzeitig auszuführen, und das würde manchmal bis zu 5 Minuten Drift zwischen den Systemen anzeigen. Wenn ich mich richtig erinnere, konnten wir das Problem scheinbar nur durch einen Neustart des Dämons beheben und haben letztendlich den Dienst jede Nacht neu gestartet ...
Auf keinen Fall eine ideale Lösung, aber Sie könnten möglicherweise einen ähnlichen Ansatz mit einem Cron-Job verfolgen, um eine Verbindung zum Switch herzustellen und einen Neustart einzuleiten, oder den NTP-Daemon auf dem Switch irgendwie "treten"?
Hoffe das hilft!
quelle