Probleme mit NTP

[KHE]

Hi,

welcher Wert steht in /var/db/ntpd.drift? Wenn der Wert sehr groß ist, dann lösche die Datei und starte den ntp mal neu. Vielleicht klappt es dann besser. Unter pfsense hatte da jemand Erfolg, nachdem er unter Hyper-V auch Probleme hatte und sich selbst das entkoppeln der Zeitsynchronisierung mit Hyper-V keine Besserung einstellte. Erst nach zurücksetzen der ntpd.drift Datei hat es funktioniert.Siehe https://forum.netgate.com/topic/132980/ntpd-losing-contact-with-servers-unexpected-origin-timestamp/7.

KH

PS: Als ich das Problem wegen einer kaputten BIOS-Batterie hatte habe ich nptdate als cron-Job aufgerufen. Das sollte aber wirklich nur als allerletzte Möglichkeit angesehen werden.

[psychofaktory]

Hallo KH,

in /var/db/ntpd.drift stand -0.019.
Ich habe vorbeugend jetzt die Datei gelöscht und ntpd neu gestartet.

Jetzt werde ich wieder beobachten.


Die BIOS-Batterie des Hosts dürfte OK sein. Das Board wurde erst vor ca. 3 Monaten neu gekauft.

Der Gedanke mit dem cron-Job war mir auch schon gekommen. Sofern möglich möchte ich diese Vorgehensweise aber vermeiden. Ist ja auch wieder eher so ein Workaround als eine tatsächliche Lösung.


Mal generell gefragt:
Wie verhält es sich mit der Synchronisation zwischen Host und Gast?
Also das Board verfügt über eine RTC. Über das installierte Betriebssystem (in meinem Fall Unraid) habe ich die Möglichkeit die Systemzeit einzustellen. Manuell oder via NTP. Damit wird die RTC auf dem Board korrigiert.
Dann lasse ich eine VM auf Unraid laufen die z.B. über HPET die Zeit vom Host liest und selbst nutzt.
Wenn ich jetzt in der VM die Zeit via NTP synchronisieren lasse, wird dann die Zeit auf den Host zurücksynchronisiert?

[KHE]

Hi psychofaktory,

Der Gedanke mit dem cron-Job war mir auch schon gekommen. Sofern möglich möchte ich diese Vorgehensweise aber vermeiden. Ist ja auch wieder eher so ein Workaround als eine tatsächliche Lösung.

Daher auch als allerletzte Möglichkeit bezeichnet

Mal generell gefragt:
Wie verhält es sich mit der Synchronisation zwischen Host und Gast?
Also das Board verfügt über eine RTC. Über das installierte Betriebssystem (in meinem Fall Unraid) habe ich die Möglichkeit die Systemzeit einzustellen. Manuell oder via NTP. Damit wird die RTC auf dem Board korrigiert.
Dann lasse ich eine VM auf Unraid laufen die z.B. über HPET die Zeit vom Host liest und selbst nutzt.
Wenn ich jetzt in der VM die Zeit via NTP synchronisieren lasse, wird dann die Zeit auf den Host zurücksynchronisiert?

Ich würde von einem Hypervisor erwarten, dass er sich nicht von einer VM die Zeit stellen lässt. Zumindest nicht ohne eine explizite Einstellung, wobei ich das jetzt echt nicht weiß.
Könnte es nicht so sein, dass der Hypervisior (Hier Unraid bzw. was auch immer die benutzen) die Zeit immer wieder stellt und dann der ntpd in der VM dann durcheinander kommt? Was passiert eigentlich, wenn du den ntpd in der Opnsense mal deaktivierst? Bleibt dann die Zeit konstant?
Wenn ja, dann kannst du als externen Server 127.127.1.0 nehmen, dann nimmt er sich selbst als Source.
Quelle: https://aixperts.blogspot.com/2012/11/configuring-ntp-server-without-internet.html

Gruß
KH

[psychofaktory]

Könnte es nicht so sein, dass der Hypervisior (Hier Unraid bzw. was auch immer die benutzen) die Zeit immer wieder stellt und dann der ntpd in der VM dann durcheinander kommt?

Das war auch meine Theorie weshalb ich hier nochmal explizit nachgefragt hatte.

Daher hatte ich vorbeugend nicht nur das Drift-File glöscht, sondern auch den NTP-Client am Host deaktiviert.

Seit der Anpassung vor ca. 19 Stunden liegt die Zeit am Host jetzt ziemlich genau 10 Minuten zurück.
Das ist eine interessante Erkenntnis, da nun zum einen klar ist, dass die BIOS-Uhr zu langsam läuft, und zum andern, dass die VM die Zeit über HPET nicht an den Host zurücksynchronisiert.

In OPNsense ist die Zeit übrigens noch immer aktuell!
Die zyklische Synchronisation via NTP mit den öffentlichen Zeitservern läuft sauber. Zwischen den Zyklen kommt es immer wieder zu einigen Sekunden Abweichungen (ca. 10 Sekunden in 15 Minuten). Mit der nächsten Synchronisation wird das dann wieder korrigiert.

Die Fehlermeldungen sind übrigens geblieben:

Code: [Select]

2021-05-16T20:56:56 ntpd[91227] receive: Unexpected origin timestamp 0xe44be974.174fb3c5 does not match aorg 0000000000.00000000 from server@2001:638:809:7::7 xmt 0xe44be97a.e819171d

Zusammenfassend würde ich also folgendes Festhalten:

• Das Löschen des Drift-Files und/oder die Umstellung auf HPET haben offenbar geholfen
• Die VM synchronisiert die Zeit über HPET nicht auf den Host zurück
• Der Zeitgeber des Hosts läuft zu langsam
• Möglicherweise war das Drift-File garnicht das Problem, sondern die Zeitsprünge die sich durch die Zeitkorrekturen bei der NTP-Synchronisationen am Host ergeben haben. Zum Test (und zur Korrektur der Zeit in Unraid) habe ich NTP wieder aktiviert und beobachte ob und wie sich das auf die Zeitsynchronisation in OPNsense auswirkt.

Jetzt wäre die nächste Frage: Was kann ich gegen die zu langsam laufende Zeit am Host machen?

Was passiert eigentlich, wenn du den ntpd in der Opnsense mal deaktivierst? Bleibt dann die Zeit konstant?

Ich vermute mal die Zeit würde im gleichen Maße zu langsam laufen wie am Host.

Wenn ja, dann kannst du als externen Server 127.127.1.0 nehmen, dann nimmt er sich selbst als Source.

Ich denke nicht dass das hier weiterhelfen wird, aber der Tipp ist genial! Danke dafür!
Gut zu wissen dass es diese Möglichkeit gibt.

[wurmloch]

Habe hier viel gelernt, danke dafür.

[JeGr]

Ich frage mich da jetzt eher:

1) Warum pusht mir Unraid überhaupt die Zeit "erzwungen" in die VM? Ich würde das - zumindest bei einem virtualisierten Border Gateway wie einer Firewall - nicht haben wollen, sondern diese soll selbst (als Internet-nächstes device) die Zeit holen und ggf. verteilen.
2) Wie kann man diesen Unbill abschalten? (denn dann sollte auch das ständige laggen in der VM nicht mehr vorkommen) Ohne die "Bremse" durch den HV würde die VM mit ntpd nämlich sehr wahrscheinlich einfach sauber vor sich hinlaufen. NTPd misst ständig nach wie sehr die Zeit laggt, stellt sich entsprechend das Drift File so ein und korrigiert ggf. ein paar ms/ns nach. Dafür ist das Driftfile da, dass quasi gemessen wird, ahja VM geht alle 1h so ~0,141542s falsch, also korrigieren.
3) Man sollte ggf. mal die Hardware oder den Unraid prüfen, warum zum Geier der ständig so "hinkt" und ihm dann ggf. entweder die Sense oder selbst einen NTPd verpassen, damit er ordentlich läuft.
4) Intern alle Kisten HW/VM so einstellen, dass sie sich die Sense VM und den HV Host (der dann NTP gestützt hoffentlich richtig läuft) als NTPs nehmen. Dann reden nur 1-2 Geräte mit NTP draußen, sind korrekt gesetzt und geben intern den Ton an.

Cheers
\jens

[psychofaktory]

1) Warum pusht mir Unraid überhaupt die Zeit "erzwungen" in die VM? Ich würde das - zumindest bei einem virtualisierten Border Gateway wie einer Firewall - nicht haben wollen, sondern diese soll selbst (als Internet-nächstes device) die Zeit holen und ggf. verteilen.

Das ist ein interessanter Punkt.
Mein Gedankengang war, dass ein Betriebssystem eine Bezugsquelle für die Zeit benötigt. Sozusagen als Ausgangslage. So wie die RTC im BIOS für Unraid wäre dann HPET für die OPNsense-VM die Basis.
Allerdings würde das Problem wie Du schreibst ja nur bis zum ersten Abgleich mit einem NTP-Server bestehen. Hier hatte ich irgendwo in den Tiefen des Internets gelesen, dass die Synchronisation mit dem Zeitserver fehlschlägt, wenn die Abweichung zu groß ist.

2) Wie kann man diesen Unbill abschalten? (denn dann sollte auch das ständige laggen in der VM nicht mehr vorkommen) Ohne die "Bremse" durch den HV würde die VM mit ntpd nämlich sehr wahrscheinlich einfach sauber vor sich hinlaufen. NTPd misst ständig nach wie sehr die Zeit laggt, stellt sich entsprechend das Drift File so ein und korrigiert ggf. ein paar ms/ns nach. Dafür ist das Driftfile da, dass quasi gemessen wird, ahja VM geht alle 1h so ~0,141542s falsch, also korrigieren.

Zum Test habe ich aus der XML-Konfiguration der VM in Unraid die komplette "clock offset"-Sektion entfernt und die VM neu gestartet. Dann habe ich mit

Code: [Select]

dmesg | grep Timecounter und

Code: [Select]

sysctl kern.timecounter die Konfiguration überprüft.
Interessanterweise waren die ausgegebenen Werte exakt gleich mit denen, als die "clock offset"-Sektion noch enthalten war.
Als Zeitzähler wurde wieder HPET erkannt und gewählt.
Aber:
Seit der Anpassung vor etwa 7 Stunden hinkt die Zeit in der OPNsense schon wieder gut 3 Minuten nach. Die NTP-Synchronisation scheint wieder nicht zu funktionieren. "Sync Source" sagt "Keine aktiven Peers verfügbar", im NTP-Status steht bei allen Servern "Unerreichbar/Ausstehend". Im NTP-Protokoll sind keine Fehlermeldungen/Warnungen gelistet.
Mit der Konfiguration zuvor hatte die Synchronisation jetzt über 2 Tage durchgängig funktioniert. Im Protokoll gab es zwar die erwähnten Warnungen, aber es lief zumindest.

Apropos Drift-File:
Mit ACPI-fast war die Abweichung im Drift-File bei -0.019.
Mit HPET steht die Abweichung auf 500.000. Eine Anpassung des Wertes findet nicht statt!
Zum Test habe ich jetzt nochmal das Drift-File gelöscht und den NTPd-Dienst neu gestartet. Für den Moment läuft die Zeitsynchronisation gerade. Mit dem Neustart des Dienstes wurde kein neues Drift-File angelegt.

3) Man sollte ggf. mal die Hardware oder den Unraid prüfen, warum zum Geier der ständig so "hinkt" und ihm dann ggf. entweder die Sense oder selbst einen NTPd verpassen, damit er ordentlich läuft.

Hier habe ich bisher die BIOS-Einstellungen überprüft und keine Fehler gefunden. Die Spannung der BIOS-Batterie ist auch OK. Und das BIOS ist ebenfalls aktuell.
Unraid ist eine "frische" Standardinstallation.
Aktuell bezieht Unraid die Zeit von den selben öffentlichen NTP-Quellen wie OPNsense. Der Abgleich funktioniert hier.
Wo kann ich hier noch ansetzen?

4) Intern alle Kisten HW/VM so einstellen, dass sie sich die Sense VM und den HV Host (der dann NTP gestützt hoffentlich richtig läuft) als NTPs nehmen. Dann reden nur 1-2 Geräte mit NTP draußen, sind korrekt gesetzt und geben intern den Ton an.

Das wäre meine Wunschkonfiguration!



---
Edit zu Punkt 2)
nach Löschen des Drift-Files und Neustart des NTPd-Dienstes lief die Synchronisation nur einmalig. Seitdem gab es keine neue Synchronisation mehr. Das Fehlerbild sieht aus wie gehabt. Die Zeit liegt inzwischen wieder knapp 1 Minute zurück.
Ich gehe jetzt vorerst wieder zurück auf den Zustand vor entfernen der "clock offset"-Sektion.

[psychofaktory]

Die Synchronisation läuft leider nach wie vor noch nicht sauber.
Der initiale Sync nach einem (Dienst-)Neustart läuft, aber dann gleicht sich die Zeit nicht mehr ab.

Im Log treten weiterhin diese Fehler auf:

Code: [Select]

2021-05-21T11:35:15 ntpd[48751] receive: Unexpected origin timestamp 0xe451fd50.5b674221 does not match aorg 0000000000.00000000 from server@2001:638:809:7::7 xmt 0xe451fd56.1de170b5
2021-05-21T11:25:28 ntpd[48751] receive: Unexpected origin timestamp 0xe451fb03.ab0d1271 does not match aorg 0000000000.00000000 from server@2001:638:809:7::7 xmt 0xe451fb0a.96e26369
2021-05-21T10:07:25 ntpd[48751] receive: Unexpected origin timestamp 0xe451e8ba.c6dd2766 does not match aorg 0000000000.00000000 from server@2001:638:809:7::7 xmt 0xe451e8bd.55395647
2021-05-21T10:01:24 ntpd[48751] receive: Unexpected origin timestamp 0xe451e752.f0c0a0da does not match aorg 0000000000.00000000 from server@2001:638:809:7::7 xmt 0xe451e755.1e853c52
2021-05-21T10:01:24 ntpd[48751] frequency error 5243 PPM exceeds tolerance 500 PPM
2021-05-21T10:01:22 ntpd[48751] kernel reports TIME_ERROR: 0x41: Clock Unsynchronized
2021-05-21T09:55:48 ntpd[48751] receive: Unexpected origin timestamp 0xe451e603.f801a850 does not match aorg 0000000000.00000000 from server@2001:638:809:7::7 xmt 0xe451e604.28fed278
2021-05-21T09:55:48 ntpd[48751] receive: Unexpected origin timestamp 0xe451e603.f7fdae3f does not match aorg 0000000000.00000000 from server@132.199.4.1 xmt 0xe451e604.289e5bfe
2021-05-21T09:55:40 ntpd[48751] kernel reports TIME_ERROR: 0x41: Clock Unsynchronized
2021-05-21T09:55:40 ntpd[48751] kernel reports TIME_ERROR: 0x41: Clock Unsynchronized
2021-05-21T09:55:40 ntpd[48751] Listening on routing socket on fd #48 for interface updates

Das Drift-File wird scheinbar nur beim Systemstart einmalig erstellt und dann nicht mehr angepasst.
Der Wert steht hier bei 500.000.
Wird das File gelöscht, wird es erst erst beim nächsten Neustart von OPNsense neu angelegt. Ein Neustart vom NTPd-Dienst reicht nicht aus. Der Wert im File wird im laufenden Betrieb auch nicht angepasst, sondern bleibt immer beim initialen Wert.
Das sollte doch normalerweise anders sein, oder?

[KHE]

Hi,

Die Synchronisation läuft leider nach wie vor noch nicht sauber.
Der initiale Sync nach einem (Dienst-)Neustart läuft, aber dann gleicht sich die Zeit nicht mehr ab.

Blöd.

Das Drift-File wird scheinbar nur beim Systemstart einmalig erstellt und dann nicht mehr angepasst.
Der Wert steht hier bei 500.000.
Wird das File gelöscht, wird es erst erst beim nächsten Neustart von OPNsense neu angelegt. Ein Neustart vom NTPd-Dienst reicht nicht aus. Der Wert im File wird im laufenden Betrieb auch nicht angepasst, sondern bleibt immer beim initialen Wert.
Das sollte doch normalerweise anders sein, oder?

Bei den paar Artikeln im Internet, an die ich mich erinnere, sollte die Drift unter +/-100 sein. Je kleiner, desto besser.
Entweder hat unraid mit deinem Board ein Problem, oder dein Board hat einen Knacks.
Kannst du es z.B. mit einem Live-Linux oder anderem Live-Betriebssystem starten und schauen, was die Zeit da ohne Zeitabgleich macht? Wenn es da auch Probleme macht würde ich es als HW-Fehler ansehen und umtauschen, da es ja noch nicht so alt ist.

Gruß KH

[thogru]

Hi psychofaktory,

Soweit ich mich erinnere, synchronisiert NTP die Uhr direkt nach dem Start für eine "größere" Zeitdifferenz. Danach werden nur noch "kleinere" Zeitdifferenzen synchronisiert. Sprich, wenn die Zeit in Deiner OPNsense zu stark abweicht (aus welchen Gründen auch immer) wird NTP die Uhrzeit nicht nach führen.

So wie ich das verstehe hast Du zwei Probleme:

• Die Zeit auf Deiner OPNsense wird "irgendwie" mit großen Zeitsprüngen umgestellt
• ntpd kann die Zeit über diese Zeitsprünge nicht synchronisieren (Erklärung oben)

Wenn Du das erste Problem löst, löst sich das zweite gleich mit. 

Falls Du nur das zweite Problem angehen willst, könntest Du es mal mit chrony versuchen. Der soll bei unzuverlässigen Leitungen besser funktionieren und schafft es eventuell die Zeitsprünge zu synchronisieren.

Gruß
Thomas

[psychofaktory]

Das Problem konnte gelöst werden!

Die verschiedenen Ansätze haben mich auf die richtig Fährte gebracht und letztlich zum Ziel geführt.
Die Umstellung von ACPI-fast zu HPET in OPNsense durch hinzufügen des HPET-Timecounters in der XML-Konfiguration der VM unter Unraid haben eine große Verbesserung innerhalb von OPNsense gebracht.

Es kam aber dennoch immer wieder zu Abweichungen. Nur weniger häufig als zuvor.

Ursächlich dafür war, dass die Zeit am Unraid-Host ebenfalls zu langsam lief und dort ebenfalls mit NTP synchronisiert wurde. Dadurch kam es wohl immer wieder zu Zeitsprüngen mit denen der VM-Gast dann Probleme hatte.

Daraufhin habe ich, analog der Vorgehensweise die unter OPNsense zu Verbesserungen geführt hatte, geprüft von welchem Zeitzähler Unraid seine Zeit bezieht.
Hier war "tsc" eingestellt.
Nachdem ich auch das auf HPET umgestellt hatte lief auch am VM-Host die Zeit mit der richtigen Geschwindigkeit.

Seit der Umstellung zu HPET sowohl in Unraid als auch in OPNsense läuft jetzt überall die Zeit durchweg perfekt synchron und der Abgleich mit den NTP-Servern klappt reibungslos und dauerhaft.

Vielen Dank nochmal allen Beteiligten für die Unterstützung!

[psychofaktory]

Ich muss leider nochmal an das Thema anknüpfen.

Zuerst: die Netzwerk-Zeit läuft auf der OPNsense noch immer dauerhaft perfekt mit dem NTP-Server synchron.

Allerdings ist mir in dem Zusammenhang jetzt noch ein anderes Problem aufgefallen.
Von Zeit zu Zeit können sämtliche NTP-Clients im Netzwerk keine Verbindung mehr mit dem NTP-Server der OPNsense aufbauen.
Der NTPd-Dienst auf der OPNsense läuft derweil fehlerfrei. Auch im NTP-Protokoll sind keine Einträge zu Fehlern vorhanden.
Ein Neustart des NTPd-Dienstes behebt dann das Problem.
Der Fehler tritt ca. alle 3 Tage auf.

Was könnte hier die Ursache sein?

[thogru]

Hallo psychofaktory,

Hast Du mal nach der Ursache für "keine Verbindung" forschen können? Gibt es einen kurzen Aussetzer in der Verbindung zu Deinem Provider? Hast Du eine neue externe IP-Adresse bekommen? Baust Du VPN Verbindungen auf oder ab, sodass sich die Routen ändern? Gibt es irgend welche Ereignisse die zeitgleich statt finden?

Gruß
Thomas

[psychofaktory]

Hallo Thomas,

Die NTP-Clients synchronisieren die Zeit nur periodisch, so dass mir die Fehler erst auffallen wenn eine periodische Synchronisation ausbleibt oder ich die Synchronisation manuell anstoße.
In beiden Fällen erhalten ich an den Clients dann die Meldung dass keine Verbindung mit dem NTP-Server hergestellt werden kann.
Dieses Verhalten macht es mir auch schwer den genauen Zeitpunkt ab dem der Fehler besteht einzugrenzen.

An der Konfiguration in OPNsense haben in diesen Zeiträumen keine Veränderungen stattgefunden. Auch wurden keine VPN-Verbindungen auf- oder abgebaut.
Bei der Internetverbindung (Telekom VDSL 100) gibt es tatsächlich des öfteren Verbindungssabbrüche (nach denen ich dann auch eine neue IP zugewiesen bekomme), die sich aber leider nicht beheben lassen.
Weder die Telekom-Techniker noch der Draytek-Support (des vorgeschalteten Modems) konnten hier etwas ausrichten.

[thogru]

Hi psychofaktory,

OK, die Verbindung bricht "häufiger" weg als es Dir lieb ist. Das passiert mehrmals (1 - 4 mal) innerhalb von 24 Stunden? Das ist doof. Lösung scheint es keine zu geben. Noch viel dööfer.

Ich würde vermuten, dass der NTP Dienst damit nicht so richtig klarkommt. Ich weiß, Du hast schon viel Zeit und Energie daran gesetzt, den NTP soweit zum Laufen zu bringen. Willst Du Dich weiter auf NTP festlegen und Analysen betreiben? Ich denke, dass ich Dir da nicht wirklich weiterhelfen kann.

Eventuell ist es an der Zeit, dass Du Dich mit Alternativen beschäftigst: Chrony wäre eine. Da gibt es bei OPNsense ein Plugin, welches Du nutzen kannst. In einem anderem Software-Router (fli4l) habe ich Chrony jahrelang ohne Probleme genutzt.

Gruß
Thomas