Wie kommt es, dass einer meiner Schalter trotz NTP um zwei Minuten ausgeschaltet ist?

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 Referenzuhren sho 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

cisco ntp time-synchronization

— Hagen von Eitzen
quelle

Ich kann kein System erkennen, in dem IP-Adressen, die Sie als NTP-Server konfiguriert haben, von jedem Gerät verwendet werden. Und ich sehe eine Schleife sowie ein Paar, das sich gegenseitig als NTP-Server verwendet. Ich glaube, in diesen Fällen sollten Sie sie eher als NTP-Peers als als Server angeben. Obwohl ich zugeben muss, dass ich nicht genau weiß, welchen Unterschied es macht, ob Sie es als Peer oder Server angeben. Ich bin auch nicht davon überzeugt, dass es eine gute Idee ist, alles über einen einzigen Host synchronisieren zu lassen ( 10.0.0.1). Ich glaube jedoch nicht, dass eine meiner Beobachtungen die Ursache Ihres aktuellen Problems direkt erklären kann.

— Kasperd

Ein eklatantes Problem bei Ihrer NTP-Konfiguration ist, dass jeder Host mit der schlechtestmöglichen Anzahl von Zeitquellen konfiguriert ist . "Ein Mann mit einer Uhr weiß, wie spät es ist, ein Mann mit zwei Uhren ist sich nie sicher ..." Jede andere Zahl ist besser als zwei, vier ist wahrscheinlich die beste Wahl, es gibt ein Kissen, wenn eine nicht verfügbar ist und immer noch geht drei Quellen.

— dfc

Ihre gesamte NTP-Konfiguration muss überdacht werden. Sie müssen mit Schichtenebenen arbeiten. Wie @kasperd betonte, könnten Sie ein Problem mit einer Schleife haben. Sie sollten nur mit Servern mit einer niedrigeren Schichtstufe synchronisieren, und diejenigen mit derselben Schichtstufe können einen Blick darauf werfen, sich jedoch nicht gegenseitig als Server verwenden. Peered-Geräte benötigen weiterhin einen oder mehrere Server auf einer niedrigeren Schicht als autorisierende Quelle (n), versuchen jedoch, sich an anderen Peers auszurichten. Verwenden Sie keine ausgelasteten Geräte (z. B. Core-Switches) als NTP-Server.

— Ron Maupin

Etwas sehr Seltsames ist los. Die gesamte NTP-Ausgabe ist einigermaßen normal und zeigt eine gute Synchronisation. Ihr Befehl, die Zeit vom Gerät abzurufen, ergab jedoch eine Zeit, die weit davon entfernt ist. Dies deutet darauf hin, dass das Gerät mit ausgeschalteter Zeit aus irgendeinem Grund die Systemuhr nicht über das NTP-Subsystem einstellt.

— David Schwartz

Es hört sich wirklich so an, als hätten Sie einen Fehler gefunden, und wahrscheinlich besteht der einzige Weg vorwärts darin, ihn neu zu starten und zu hoffen, dass er verschwindet, oder Cisco zu kontaktieren.

— Derobert

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.

— Hagen von Eitzen
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.

— George Kasica
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!

— Dan
quelle