Wenn eine Maschine die Verbindung komplett verliert, verpasst ntpd normalerweise ein paar Abfragen und markiert alle Quellen als fehlgeschlagen. Das scheint ziemlich logisch. Aber ich habe eine Situation erlebt, in der ein Server als aktuelle Zeitquelle markiert blieb, während seine Reichweite 0 wurde.
Der Server wird im selben Subnetz wie die Zielmaschine eingesetzt und bietet dadurch sehr geringe Verzögerungen, Offsets und Jitter. Die Situation wurde modelliert, indem die Verbindung physisch beendet wurde: einfach ein Kabel von einer Client-Maschine abziehen. Ich habe versucht, dies nachzubilden, aber seitdem verliert dieselbe Maschine immer nach 5-6 erfolglosen Abfragen den Synchronisierungsstatus.
Die eigentliche Frage ist: Wodurch wird der Synchronisierungsstatus genau bestimmt, wenn die Verbindung verloren geht?
Antwort1
Es gibt eine eindeutige Erklärung zum Reichweitenregister in RFC-1305:
Das Erreichbarkeitsregister wird um eine Position nach links verschoben, wobei das frei gewordene Bit durch eine Null ersetzt wird. Wenn alle Bits dieses Registers Null sind, wird die Löschprozedur aufgerufen, um den Taktfilter zu leeren und die Synchronisationsquelle bei Bedarf neu auszuwählen. Wenn die Zuordnung nicht durch die Initialisierungsprozedur konfiguriert wurde, wird die Zuordnung aufgehoben.
RFC-1305 wurde jedoch durch RFC-5905 ersetzt, das nicht ganz so eindeutig ist:
Als nächstes wird das 8-Bit-Schieberegister p.reach im in Abschnitt 13 beschriebenen Polling-Prozess verwendet, um zu bestimmen, ob der Server erreichbar ist und die Daten aktuell sind. Das Register wird um ein Bit nach links verschoben, wenn ein Paket gesendet wird, und das Bit ganz rechts wird auf Null gesetzt. Wenn gültige Pakete eintreffen, wird das Bit ganz rechts auf Eins gesetzt. Wenn das Register Bits ungleich Null enthält, gilt der Server als erreichbar, andernfalls ist er nicht erreichbar.
In Abschnitt 13 wird kein klares Verfahren erwähnt. Aber es sieht trotzdem so aus, als ob ein nicht erreichbarer Peer irgendwann seinen Synchronisationsstatus verlieren sollte.
Ich habe es geschafft, den synchronisierten Status mit einer 0-Situation wiederherzustellen, um sicherzustellen, dass dies selten vorkommt und keineswegs dauerhaft ist. Dazu musste „Burst“ in der Serverkonfiguration deaktiviert und die Verbindung direkt nach der Synchronisierung unterbrochen werden.
remote refid st t when poll reach delay offset jitter
==============================================================================
91.198.10.4 194.190.168.1 2 u 20 64 177 51.137 -2.192 11.049
192.168.1.1 193.67.79.202 2 u 65 64 77 0.459 -1.818 0.922
remote refid st t when poll reach delay offset jitter
==============================================================================
*91.198.10.4 194.190.168.1 2 u 21 64 177 51.137 -2.192 11.049
+192.168.1.1 193.67.79.202 2 u - 64 177 0.449 -3.192 1.828
Die Reichweite betrug 177, was im Binärsystem 01111111 entspricht. Es waren also 7 Polls nötig, um die Synchronisierung herzustellen.
Die Synchronisation ging dann an dieser Stelle verloren:
remote refid st t when poll reach delay offset jitter
==============================================================================
+91.198.10.4 194.190.168.1 2 u 574 64 0 63.846 -9.652 0.756
*192.168.1.1 193.67.79.202 2 u 553 64 0 0.449 -3.192 0.505
remote refid st t when poll reach delay offset jitter
==============================================================================
91.198.10.4 194.190.168.1 2 u 575 64 0 69.871 -10.409 0.002
192.168.1.1 193.67.79.202 2 u 554 64 0 0.449 -3.192 0.505
Wenn die Zahlen etwas seltsam sind, wie 64*9 = 576 und nicht 575, aber ich schätze, die Darstellung könnte 1 Sekunde ungenau sein. In Anbetracht dessen waren 9 erfolglose Abfragen erforderlich, um den Synchronisierungsstatus zu unterbrechen.
Betrachtet man also sowohl die Theorie als auch die Praxis, so scheint es zwar möglich, aber auch selten und vorübergehend zu sein, dass eine Quelle mit der Reichweite 0 als aktuelle Zeitquelle betrachtet werden kann.