Probleme mit NTP

[psychofaktory]

Hallo Thomas,

Du hast schon viel Zeit und Energie daran gesetzt, den NTP soweit zum Laufen zu bringen.

Ich denke hier muss differenziert werden.
Durch die eingesetzte Zeit und Energie konnten grundsätzliche Probleme behoben werden die nicht nur auf NTP Auswirkungen hatten und sicher auch mit Chrony zu Problemen geführt hätten. Von daher war das in jedem Fall sinnvoll und notwendig.

Willst Du Dich weiter auf NTP festlegen und Analysen betreiben?

In erster Linie ist es mir wichtig, dass NTP sauber funktioniert. Dabei muss ich mich nicht zwingend auf NTPd festlegen. Tatsächlich hatte ich ganz zu Beginn des Problems ja bereits Chrony ins Auge gefasst und als mögliche Option eingebracht (sieht 1. Beitrag).
Leider war es mir nicht gelungen des Chrony-Plugin zu aktivieren.

Ich würde vermuten, dass der NTP Dienst damit nicht so richtig klarkommt.

Es wäre hilfreich ermitteln zu können weshalb der NTPd-Dienst nicht damit klarzukommen scheint, oder wo genau der Fehler liegt. Vermutlich hätte Chrony mit den Fehlerursachen dann ebenfalls Probleme.

[thogru]

Hi psychofaktory,

Sorry, ich hatte Dein ersten Post nicht mehr ganz in Erinnerung.

Inzwischen habe ich Dein Problem mit chrony auf meiner Installation nachstellen können (siehe https://forum.opnsense.org/index.php?topic=23492.0). Mal sehen was daraus wird.

Wenn ich mich richtig erinnere, werden die Namen von 0.opnsense.pool.ntp.org (also alle die auf pool.ntp.org enden) per load balancing auf verschiedene Server geleitet. Das einzige was mir einfällt ist folgendes: Nach der Einwahl fragst Du ja mit einer neuen IP-Adresse die Zeit ab. Ich kann mir vorstellen, dass Deine neue IP-Adresse dazu führt, dass Du Deine Antworten von einen anderen Server bekommst, der eine leicht unterschiedliche Zeit verteilt. Deswegen kann Dein lokaler NTP diese Zeitdifferenz nicht ausgleichen.

Erste Idee:
Eventuell reicht es einen anderen Server als "Prefer" zu markieren. Ansonsten kannst Du kurzzeitig auch anderen öffentliche NTP Server eintragen (siehe https://www.it-lu.de/start/zeitserverliste oder https://www.heise.de/ct/hotline/Oeffentliche-Zeitquellen-322978.html). Das solltest Du nur zu Testzwecken machen, damit Du nicht vom Server blockiert wirst.

Zweite Idee:
Hast Du einmal den Wert von "Orphan mode" erhöht? Vielleicht hilft das, "größere" Zeitsprünge zu überbrücken.

Sicherlich wäre es für jemandem, der sich mit NTP auskennt sinnvoll, die NTP-Logs zu aktivieren und vor zu halten. Damit Du für die Analyse sagen kannst: In dem Zeitraum gab es eine neue Verbindung (Neuaufbau am ... um ...) und die NTP-Logs sehen so ... aus.

Dritte Idee:
Vielleicht fällt Dir bei der Durchsicht der NTP-Logs schon etwas auf.

Ist nicht so richtig weiterführend, aber ich bin weder Netzwerk noch NTP-Profi. Es hilft Dir hoffentlich trotzdem weiter.

Gruß
Thomas

[psychofaktory]

Hallo Thomas,

vielen Dank dass du dich hier so mit einbringst!

Als NTP-Server nutze ich ptbtime2.ptb.de (bevorzugt) und ntp1.ipv6.fau.de. Beides Stratum-1-Server.
Auch wenn die Clients keine NTP-Abfrage mehr bei der OPNsense machen können, bleibt die Zeitsynchronisation mit dem bevorzugten NTP-Server ptbtime2.ptb.de nach der Wiedereinwahl bestehen.
Somit dürfte es nach meinem Verständnis aus Sicht der Clients zu keiner Veränderung kommen. Der NTPd-Dienst läuft auf der OPNsense ja weiterhin.
Zum Test habe ich auch schon ntp1.ipv6.fau.de und auch mal beide Server auf bevorzugt gesetzt.

Allgemeine Frage hierzu: Wie verhält sich NTPd wenn alle angegebenen öffentlichen NTP-Server als bevorzugt markiert sind?


Den Wert des Orphan-Modus habe ich zu Testzwecken jetzt ebenfalls mal verändert. Hier werde ich weiter beobachten.

Zum Test habe ich jetzt ebenfalls temporär alle Haken bei "Systemprotokollprotokollierung" und "Statistik-Protokollierung" gesetzt.
Im "normalen" Log finden sich keine Einträge die ich als hilfreich einstufen würde.

Ich beobachte und berichte.  :)

[psychofaktory]

Die Änderungen haben leider nicht geholfen.

Anbei der NTPd-Log der OPNsense für den Zeitraum in dem die Clients keine Zeitsynchronisation mit der OPNsense durchführen konnten.
In dem Zeitraum war die Internetverbindung stabil und wurde nicht getrennt.

[thogru]

Moin psychofaktory,

Das ist erst einmal doof, aber wir können den Reconnect als Ursache ausschließen :)

Von den Logs verstehe ich so wenig, dass ich den Fehler in der Zeitsynchronisation nicht lokalisieren kann.

Das erste was mit aufgefallen ist: Das stehen ja IPv6 Adressen drin. Davon verstehe ich nichts.

Mein nächster Schritt wäre IPv6 komplett in OPNsense zu blocken (dafür gibt es eine Haken in OPNsense, Du könntest NTP auf IPv4 blocken, dafür müsstest Du Regeln bauen). Der Gedanke dahinter: Wenn die Zeitserver mit Deiner OPNsense über verschiedene Protokolle "sprechen", können sich die Laufzeiten "mehr" unterscheiden.

Gruß
Thomas

[KHE]

Hi psychofactory,

Im Log sehe ich öfters die Abfolge dieser Meldungen: spike_detect, clock_step, clock_sync, sys_no_peer.
D.h. die Uhr wird immer wieder nachgestellt.
Dies könnte dazu führen, dass die Clients ein Problem nach einem clock_step haben, da Ihnen die Zeitdifferenz zu groß wird. Das ist aber nur eine Vermutung. Schau mal bei einem von den Clients nach, vielleicht steht da was in den Logs.

Gruß KH

[thogru]

Hallo psychofaktory,

Deine VM hat nur eine "Hardware-Uhr". Du lässt auf diese Uhr zwei verschiedene "Steller" einwirken:

• den NTP in Deiner OPNsense
• Deinen VM Host

Wie Du siehst funktioniert das auf lange Sicht nicht. Schalte eine Zeitquelle ab (entweder NTP oder Deine VM Synchronisation).

Im Grundsatz versucht NTP Deine Uhr mal zu beschleunigen oder zu verlangsamen. Das hat den Effekt, dass die Sekunden meinetwegen über einen Zeitraum hinweg 1001 Millisekunden habe oder evtl. nur 999 Millisekunden. Das Vorgehen hat den Vorteil, dass Deine OPNsense keine Probleme damit hat und das Schwanken Deiner "Hardware-Uhr" keine Auswirkungen hat: Die Uhrzeit geht immer voran (der Mathematiker sagt, die Uhrzeit verhält sich streng monoton). Als Nachteil kann der lange Zeitraum genannt werden, der gebraucht wird um eine Differenz von nur einer Zehntelsekunde auszugleichen.

Ich weiß nicht wie Deine Virtualisierungslösung die Uhr Deiner VM verstellt. Falls die VM-Lösung die Uhrzeit mal ein bisschen vorstellt und mal ein bisschen zurück, ist das sehr schlecht. Dann geht Deine "Hardware-Uhr" in der VM nicht mehr immer nach "vorne", die strenge Monotonie der Uhrzeit geht verloren. Für die Synchronisation solch großer Sprünge ist NTP nicht ausgelegt.

In meinen Augen musst Du Dich entscheiden:

• NTP in OPNsense an und VM-Synchronisation aus
• NTP aus und die VM-Uhr über die VM-Software synchronisieren lassen.

Selbst die Synchronisation Deines VM-Hosts mittels NTP muss/kann das Problem nicht lösen.

Gruß
Thomas

[psychofaktory]

Das erste was mit aufgefallen ist: Das stehen ja IPv6 Adressen drin. Davon verstehe ich nichts.

Mein nächster Schritt wäre IPv6 komplett in OPNsense zu blocken

Ich habe eine öffentliche IPv4 sowie eine öffentliche IPv6 IP-Adresse. Die angefragten NTP-Server verfügen ebenfalls über eine öffentliche IPv6-Adresse und antworten daher mit dieser.
Das in dem Protokoll auch IPv4-Adressen auftauchen liegt daran, dass in meinenen verwendeten NTP-Servern auch Server enthalten sind, die nur mit ihrer IPv4-Adresse kommunizieren. Mit jeden öffentlichen NTP-Server wird aber nur entweder mit IPv4 oder mit IPv6 kommuniziert. Nicht beides gemischt.

In wie fern das Deaktivieren von IPv6 hier Abhilfe schaffen könnte kann ich nicht so ganz nachvollziehen.

Dies könnte dazu führen, dass die Clients ein Problem nach einem clock_step haben, da Ihnen die Zeitdifferenz zu groß wird.

Nach meinem Verständnis stellt die OPNsense eine Verbindung mit einem NTP-Server her und synchronisiert die Zeit fortlaufend damit kleinere Abweichungen der internen Uhr somit ausgeglichen werden können.
Die "eigene" Zeit wird dann für die Clients im Netzwerk bereitgestellt.
Meine Clients holen sich dann die Zeit nicht fortlaufend, sondern zyklisch z.B. 1x alle 12 Stunden um die eigene Uhr nachzustellen. Dabei hat es den Clients bisher keine Rolle gespielt wie groß die Zeitabweichungen waren. Ich habe das getestet in dem ich an einem Windows-Client die Systemzeit 2 Stunden zurück gestellt hab und dann manuell synchronisieren lassen habe. Die Uhr wurde problemlos auf die korrekte Zeit eingestellt. Eine Abweichung von einigen Sekunden sollte da dann auch keine Probleme bereiten.

Wenn der Fehler besteht steht in den Logs der Clients lediglich dass die Verbindung nicht hergestellt werden konnte (Timeout).

In meinen Augen musst Du Dich entscheiden:

• NTP in OPNsense an und VM-Synchronisation aus
• NTP aus und die VM-Uhr über die VM-Software synchronisieren lassen.

Mit Hilfe dieses Threads ist es mir gelungen die Systemzeit sowohl am VM-Host als auch in OPNsense deutlich stabiler zu bekommen. Wesentliche Verbesserung brachte es die richtigen Zeitgeber für die interne Systemuhr der OPNsense zu finden.
Wenn der OPNsense jetzt dieser Zeitgeber genommen wird, worauf bezieht sich dann die Systemzeit noch vor der ersten NTP-Synchronisation oder wenn gerade keine Internetverbindung besteht?
Und wie könnte die VM-Synchronisation überhaupt ausgestellt werden?

Vor einem Monat hatte ich die entsprechenden Timer-Einträge aus der XML-Konfiguration für die VM aus Unraid bereits testweise entfernt. Das hatte leider keinerlei Verbesserung gebracht.

[thogru]

Hi psychofaktory,

Ich habe auf die Schnelle nicht gefunden, ob man in unRAID die Zeitsynchronisation vom Host zu einem Gast abstellen kann. Ich nutze bisher den VMware Player und VirtualBox. In VMware kann man pro Gast einstellen, ob die Zeit mit dem Host übernommen werden soll.

Ich habe "nur" das gefunden: https://wiki.unraid.net/Manual/Additional_Settings#Date_.26_Time
Ich kann nicht beurteilen, ob sich das auf den Host oder einen Gast bezieht.

In meinen Augen ist das lokale NTP in OPNsense der Synchronisation mit dem Host vor zu ziehen. Das läuft.

Wenn die Synchronisation mit dem Host nicht abschaltbar sein sollte, würde ich den Host an NTP anbinden, und mich auf die Synchronisation mit dem Host verlassen. Ich denke, dass ist besser, als zwei Steller auf die Uhr in OPNsense los zu lassen, die die Uhr immer mal wieder vor- oder zurück stellen.

Gruß
Thomas

[KHE]

Hi,

wenn ich mir auf der Seite https://docs.ntpsec.org/latest/clock.html#step den Abschnitt 4 durchlese, dann tritt die spike_detect Meldung auf, wenn der ntpd feststellt, dass der Unterschied zwischen lokaler Uhr und seinem Peer mehr als 128 ms hat. Wenn der Unterschied größer als 300 ms ist, dann kommt der clock_step. Wenn ich den letzten Absatz des Abschnitt 4 richtig lese, wird er nach einem Spike solange die Zeit nicht an die Clients weitergeben, bis er wieder synchron mit den Peer(s) ist. In deinem Log sehe ich, dass der clock_step ca. 15 Min bis 75 Min benötigt. In diesem Zeitraum werden die Clients keine Zeit von der OPNsense bekommen. Falls er nach dem clock_step immer noch nicht für die Clients zur Verfügung steht, erholt der ntpd sich vielleicht nicht mehr.

Ich glaube ebenfalls, das VM Client und VM Host sich gegenseitig aus dem Konzept bringen.

Gruß KH

[psychofaktory]

Vielen Dank für die Rückmeldungen und Lösungsansätze.

Ich denke das hier war tatsächlich das Kernproblem:

Ich glaube ebenfalls, das VM Client und VM Host sich gegenseitig aus dem Konzept bringen.

Die Synchronisation von Host zum Gast konnte ich leider nicht unterbinden. Zum Test habe ich aber NTP unter Unraid deaktiviert. NTP lief in OPNsense damit gefühlt etwas stabiler, aber letztlich kam es doch wieder zu den "spike" und "clock_step"-Meldungen. Zusätzlich hatte ich dann aber das Problem dass die Systemzeit in Unraid immer weiter von der tatsächlichen Zeit abwich.

Ich habe mir daraufhin nochmal die Vergleiche von NTPd und chrony angesehen und es scheint als käme chrony mit solchen Konstellationen besser zurecht.
Also habe ich nochmal versucht die chrony-Erweiterung zu installieren.
Das Verhalten war wieder wie im Eingangspost beschrieben. Nach dem ersten Klick auf "Speichern" in der chrony-Konfiguration hing die Webgui. Über die Konsole habe ich die OPNsense daraufhin neu gestartet und konnte chrony dann konfigurieren ohne dass die Gui hing.

Seitdem läuft die Zeit absolut stabil und alle Clients können die Zeit problemlos von der OPNsense abholen.


Zusammenfassend waren die Lösungsschritte die zum Erfolg führten:

• Aktivierung HPET unter Unraid
• Aktivierung HPET unter OPNsense
• Umstellung des Dienstes für die Zeitsynchronisation von NTPd zu chrony in OPNsense

[franco]

Man sollte auch NTPd abstellen indem man alle Zeitserver entfernt und diese Einstellung speichert.

Wahrscheinlich braucht es Chrony nach dem Deaktivieren auch nicht wenn der Host sowieso nachstellt und alles funktioniert "besser" als vorher. ;)


Grüsse
Franco

[psychofaktory]

NTPd hatte ich bei der Umstellung zu Chrony natürlich entsprechend deaktiviert.

Wenn ich Chrony ebenfalls deaktivieren würde, bräuchte ich ja noch einen separaten NTP-Server im Netz bzw. müssten die Clients direkt bei einem öffentlichen NTP-Server anfragen.
Da erscheint mir die Variante mit der OPNsense als zentralem NTP-Server im Netz als eleganter. Im Moment funktioniert das auch hervorragend.  :)

[BrAiNee]

Unter Windows mit Hyper-V ist das nur ein Klick auf ein Häckchen und der OPNsense NTP Server läuft sauber in der VM :) Frag doch mal beim Support von Unraid obs da nicht ein switch irgendwo gibt um die Zeitsyncro aus zu machen.

[psychofaktory]

Unter Hyper-V ist mir die Konfiguration auch bekannt  :)

Im Unraid-Forum hatte ich auch bereits zu der Thematik angefragt.
Aufgrund der Anfrage ist es gelungen HPET zu aktivieren. Allerdings konnte mir bisher niemand sagen ob und wie die Zeitsynchronisation vom Host zum Gast abgestellt werden kann.

Für mich ist die aktuelle Lösung aber auch so schon absolut zufriedenstellend, da alles sauber läuft bisher.