OPNsense Forum
International Forums => German - Deutsch => Topic started by: psychofaktory on May 12, 2021, 04:11:10 pm
-
Hallo liebe OPNsense-Gemeinde,
ich habe ein Problem mit der Systemzeit in meinem Netzwerk.
Folgende Ausgangssituation:
OPNsense 21.1.5-amd64 auf Unraid 6.9.2 als VM
VM-Konfiguratioin unter Unraid: "Gerät": i440fx-5.1"; BIOS: "OVMF"; 2 logigische CPUs isoliert zugewiesen; 4GB RAM zugewiesen; CPU-Modus "Pathtrough"; 2 Ports einer 4-Port Intel I350-PCIe-Karte an OPNsense durchgereicht
In OPNsense unter "Netzwerk-Zeit" sieht es wie folgt aus:
Schnittstelle(n): "Nothing selected"
Zeitserver: insgesamt 4 Zeitserver eingetragen, 2 davon bevorzugt; alle 4 sind gültig und erreichbar
sonst sind die Standardeinstellungen gesetzt.
Die Zeitsynchronisation läuft immer wieder sauber durch. Die Clients können ihre Zeit auch problemlos von der OPNsense beziehen. Nach einiger Zeit scheint die Synchronisation jedoch nicht mehr zu funktionieren. Die Systemzeit der OPNsense weicht nach 24 Stunden bis zu 30 Minuten von der tatsächlichen Zeit ab.
Wird der ntpd-Dienst neu gestartet funktioniert dann wieder alles.
Ich habe jetzt gelesen, dass es unter virtuellen Installationen derartige Probleme geben kann, da die Hardware-Zeit der BIOS-Uhr nicht richtig durchgereicht werden kann, bzw. deren Virtualisierung Probleme bereitet.
In diesen Fällen wird dann wohl dazu geraten Statt ntpd "chrony" zu verwenden, da das in derartigen fällen wohl robuster ist.
Ich habe daher die Erweiterung "os-chrony" installiert, dann den Dienst ntpd-Dienst gestoppt, alle vorhandenen Einträge unter ntpd gelöscht und ntpd somit deaktiviert.
Dann habe ich in der Konfiguration zu chrony den Haken bei "Aktiviert" gesetzt, den Port von "323" auf "123" geändert, die gleichen Zeitserver wie zuvor unter ntpd genutzt eingetragen, und meine internen Netzwerke unter "erlaubte Netzwerke" hinterlegt.
Sobald ich nun auf "Speichern" klicke ist die Weboberfläche nicht mehr erreichbar. Auch nicht nach einem Neustart über die Konsole. Ich muss erst ein Backup einspielen damit ich wieder auf die Webkonfiguration gelange. Der Fehler lässt sich beliebig oft reproduzieren.
Zum Test habe ich bei meiner Vorgehensweise in chrony die Standardkonfiguration belassen und lediglich den Haken bei "Aktiviert" gesetzt. Auch dann war die Weboberfläche ab diesem Moment nicht mehr zu erreichen.
Wo liegt hier der Fehler?
Wie kann ich chrony nutzen und sicherstellen, dass die Zeit auf meinen Systemen synchron bleibt?
-
Mir ist eben aufgefallen dass der Fehler seit Thread-Erstellung eben wieder aufgetreten ist.
im ntpd-Protokoll steht folgendes:
2021-05-12T19:00:03 ntpd[71141] receive: Unexpected origin timestamp 0xe4468813.3c7638f4 does not match aorg 0000000000.00000000 from server@2001:638:a000:1123:123::2 xmt 0xe4468813.6915f5622021-05-12T18:59:56 ntpd[71141] kernel reports TIME_ERROR: 0x4041: Clock Unsynchronized
Außerdem ist mir unter "Schnittstellen" -> "Überblick" bei der WAN-Schnittstelle aufgefallen, dass dort kein vom Provider zugewiesener IPv6-Präfix mehr angezeigt wird.
Ich habe die PPPoE-Verbindung nochmal neu laden lassen, aber erhalte dennoch keinen Präfix mehr.
Das finde ich auch etwas merkwürdig.
Provider ist die Deutsche Telekom; mein Tarif ist Magenta Zuhause L (VDSL100); als Modem wird ein Draytek Vigor 166 im Bridge-Modus eingesetzt. PPPoE-Einwahl und VLAN7-tagging übernimmst die OPNsense.
Was stimmt hier nicht?
-
Moin,
hier mal ein paar Anmerkungen.
Du mixt derzeit drei verschiedene Probleme in diesem einen Thread.
Nicht besonders gut geeignet um Antworten zu bekommen.
Zum 1 Problem.
OPNsense ist außer Sync.
Das wird wohl in der Tat ein Problem mit unraid und OPNsense sein.
Habe zu diesem Thema folgendes im Netz gefunden.
https://www.reddit.com/r/unRAID/comments/a1yw5b/vm_clock_vs_hwclock_driving_me_nuts/
Das ist ähnlich wie bei Dir. Du solltest im unraid Forum fragen warum sowas vorkommen kann.
Denn so eine krasse Zeit Abweichung ist nicht normal. Ich betreibe diverse OPNsense innerhalb verschiedener Virtualisierungsumgebungen (Kein unraid). Mit so einer Zeit Abweichung ist die Firewall an sich nicht mal richtig zu gebrauchen geschweige den als Zeit Server zu nutzen.
Zu Punkt 2.
Da bist du ja hingekommen weil das Zeit abgleichen per NTP scheinbar nicht so toll in vms ist.
Was mit Sicherheit so nicht ist. Der NTP gleicht beim starten die zeit ab. Wenn da mehr kommen soll muss man es konfigurieren. Ich habe da im Forum nur das Thema Cron Job zu gefunden.
Gut nun das alles war der Grund warum Du chrony probieren wolltest.
Und Du hast recht. Das lässt sich via GUI scheinbar nicht aktivieren. Hab das selbst mal probiert.
Da an die Macher vom chrony Plug IN. Das ist derzeit wohl defekt im OPNsense 21.1.5. Ein einfacher Neustart von OPNsense reicht aber aus um wieder in das Interface zu kommen.
Zu Punkt 3.
Da kann ich nichts zu beitragen.
-
Vielen Dank für die Anmerkungen.
Sie haben mich auf jeden Fall schon mal ein Stück weiter geführt.
Ich hatte die Themen alle in dem Thread aufgeführt, weil ich leider nicht beurteilen kann in wie weit hier eventuell Zusammenhänge bestehen.
Nicht dass hier etwas übersehen wird weil ich ein womöglich wichtiges Detail weggelassen habe.
Vielleicht versuche ich es etwas besser zu strukturieren:
Die Systemzeit in OPNsense (VM) beginnt immer wieder vom VM-Host (Unraid) abzuweichen.
Ich habe hierzu etwas recherchiert. Offenbar verwendet OPNsense (FreeBSD) bestimmte Zeitzähler (https://www.thomas-krenn.com/de/wiki/FreeBSD_Timecounters).
Meine ausgelesenen Werte wären:
root@ADL15-FW001:~ # dmesg | grep Timecounter
Timecounter "i8254" frequency 1193182 Hz quality 0
Timecounters tick every 10.000 msec
Timecounter "ACPI-fast" frequency 3579545 Hz quality 900
Timecounter "i8254" frequency 1193182 Hz quality 0
Timecounters tick every 10.000 msec
Timecounter "ACPI-fast" frequency 3579545 Hz quality 900
Timecounter "i8254" frequency 1193182 Hz quality 0
Timecounters tick every 10.000 msec
Timecounter "ACPI-fast" frequency 3579545 Hz quality 900
Timecounter "i8254" frequency 1193182 Hz quality 0
Timecounters tick every 10.000 msec
Timecounter "ACPI-fast" frequency 3579545 Hz quality 900
Timecounter "i8254" frequency 1193182 Hz quality 0
Timecounters tick every 10.000 msec
Timecounter "ACPI-fast" frequency 3579545 Hz quality 900
Timecounter "i8254" frequency 1193182 Hz quality 0
Timecounters tick every 10.000 msecroot@ADL15-FW001:~ # sysctl kern.timecounter
kern.timecounter.tsc_shift: 1
kern.timecounter.smp_tsc_adjust: 0
kern.timecounter.smp_tsc: 0
kern.timecounter.invariant_tsc: 0
kern.timecounter.fast_gettime: 1
kern.timecounter.tick: 1
kern.timecounter.choice: i8254(0) ACPI-fast(900) TSC-low(-100) dummy(-1000000)
kern.timecounter.hardware: ACPI-fast
kern.timecounter.alloweddeviation: 5
kern.timecounter.timehands_count: 2
kern.timecounter.stepwarnings: 0
kern.timecounter.tc.i8254.quality: 0
kern.timecounter.tc.i8254.frequency: 1193182
kern.timecounter.tc.i8254.counter: 19671
kern.timecounter.tc.i8254.mask: 65535
kern.timecounter.tc.ACPI-fast.quality: 900
kern.timecounter.tc.ACPI-fast.frequency: 3579545
kern.timecounter.tc.ACPI-fast.counter: 1961978
kern.timecounter.tc.ACPI-fast.mask: 16777215
kern.timecounter.tc.TSC-low.quality: -100
kern.timecounter.tc.TSC-low.frequency: 1909497435
kern.timecounter.tc.TSC-low.counter: 4174462623
kern.timecounter.tc.TSC-low.mask: 4294967295Unter Unraid wurden in der Konfiguration der VM bei Erstellung (automatisch) folgende Werte dazu gesetzt:
<clock offset='utc'>
<timer name='rtc' tickpolicy='catchup'/>
<timer name='pit' tickpolicy='delay'/>
<timer name='hpet' present='no'/>Die Werte für die Zeitzähler in der VM-Konfiguration unter Unraid und die die OPNsense nutzt müssen nach meinem Verständnis zusammenpassen.
Allerdings konnte ich noch nicht herausfinden welche Anpassungen genau an welcher Stelle hier vorzunehmen sind damit alles zusammenpasst.
Ich habe hierzu auch schon einen Thread im Unraid-Forum eröffnet.
Die chrony-Erweiterung lässt sich nicht aktivieren.
Bei mir war es leider so, dass ich auch nach einem Neustart nicht mehr auf das Web-Inferface gekommen bin.
Bzw. in einem weiteren Versuch konnte ich die Weboberfläche kurzzeitig nach dem Start erreichen. Sobald ich dann aber auf "Dienste" -> "chrony" bin war ich wieder ausgesperrt.
Der vom Provider zugewiesene IPv6-Präfix wird in der Übersicht der Schnittstellen unter "WAN" nicht mehr angezeigt.
Noch später am selben Abend als ich meinen Post hier eingestellt hatte wurde die Info plötzlich wieder angezeit. Von meiner Seite aus wurde hier nichts angepasst. Auch die Internetverbindung wurde nicht neu aufgebaut.
Ich vermute hier einfach mal, dass es zu den verschiedensten Problemen kommen kann wenn OPNsense außer Sync gerät und wahrscheinlich einige Probleme verschwinden würden wenn hier der Sync mit dem Host sauber laufen würde.
Ist mein Ansatz hier der richtige?
Weiß jemand welche Anpassungen ich hier machen könnte um den Fehler zu beheben?
Ist meine ntpd-Konfiguration ansonsten korrekt?
Gibt es einen Trick wie ich chrony dennoch aktivieren kann?
-
Ich würde erst einmal das zu Grunde liegende Problem bzgl ntp lösen bevor ich andere Pakete dafür heran ziehe. Ich hatte noch bei meiner Installationen ob virtuell oder HW das Problem dass ich was anderes als ntpd benötigt habe um eine vernünftige Zeit zu bekommen. das Paket hat sicher seinen Sinn aber warum schon irgendwas als workaround nutzen wenn das eigentliche Problem tiefer liegt?
Cheers
-
Danke für Deine Einschätzung JeGr.
Ich denke auch es wäre sinnvoller zuerst die Systemzeit von Unraid und OPNsense in Einklang zu bringen.
Wenn ich bisher alles richtig interpretiere werden in der aktuellen Standardkonfiguration Host-seitig von Unraid folgende Timer zum Abgleich zur Verfügung gestellt:
- rtc (catchup)
- pit (delay)
- hpet (not present)
OPNsense unterstützt folgende Timer:
- i8254 (0)
- ACPI-fast (900)
- TSC-low (-100)
- dummy (-1000000)
Wobei in meinem Fall aktuell wohl "ACPI-fast" genutzt wird.
Damit Unraid und OPNsense sich abgleichen können müssen die verwendeten Timer auf beiden Seiten identisch sein.
Hier erkenne ich aber keine Übereinstimmungen.
Im Unraid-Forum habe ich den Hinweis gefunden, dass man 'tsc' als Timer in Unraid zur Konfiguration hinzufügen kann. So ist es auch in der libvirt-Dokumentation (https://libvirt.org/formatdomain.html#time-keeping) aufgeführt.
Wie kann ich der OPNsense sagen sie soll statt 'ACPI-fast' 'TSC-low' nutzen?
Und wäre das überhaupt der richtige Ansatz?
-
Moin,
das soll jetzt keine ketzerische Frage sein, aber warum auf irgendwelche Hypervisoren und deren Mechanismen vertrauen?
Vorschlag:
Es gibt einen (vielleicht auch redundanten) time server im LAN, der alle Maschinen mit der korrekten Zeit versorgt. Die holt er sich zB von der PTB.DE
Alle Fragen nach der Zeit (123/TCP / 123/UDP) aus dem LAN werden von Firewall/Gatway/Router auf diese Maschine umgelenkt. Dazu werden DNS-Anfragen zu der IP der "üblichen Verdächtigen" wie "time.windows.com" vom lokalen DNS mit der IP ebendieses Zeitservers beantwortet.
Ferdsch :)
Ist das nicht eleganter und einfacher?
LG
-
Ich denke dieser Ansatz wäre zwar intern für die anderen Geräte im LAN hilfreich, aber für die OPNsense-Instanz nicht zielführend.
Nach meinem Verständnis ist es unerheblich woher OPNSense die aktuelle Zeit bezieht. Die Abfrage bei einem (bzw. mehreren redundanten) öffentlichen NTP-Server(n) funktioniert ja und wird es sicherlich ebenso von einem NTP-Server im LAN.
Aber solange es beim internen Zeitzähler hardwarseitig, oder wie hier innerhalb der virtuellen Umgebung, immer wieder zu (teils größeren) Abweichungen kommt, wird OPNSense zumindest bis zur nächsten NTP-Abfrage wieder mit der falschen Zeit laufen. Bei einer zu großen Abweichung scheitert dann wohl auch die Abfrage an sich und die Systemzeit läuft gänzlich willkürlich.
Alle Fragen nach der Zeit (123/TCP / 123/UDP) aus dem LAN werden von Firewall/Gatway/Router auf diese Maschine umgelenkt.
Das wäre ja nur dann erforderlich, wenn an einem Client im LAN der Zeitserver hard-coded wäre und man Zeitabweichungen zwischen dem eigenen internen Zeitserver und dem hart kodiertem öffentlichen vermeiden wöllte. Das ist bei meinen Geräten nicht der fall. Hier kann ich die Adresse des Zeitservers überall statisch festlegen, oder via DHCP übergeben. Eventuelle zeitabweichungen sollten aber auch nicht allzu gravierend sein.
-
Aber solange es beim internen Zeitzähler hardwarseitig, oder wie hier innerhalb der virtuellen Umgebung, immer wieder zu (teils größeren) Abweichungen kommt, wird OPNSense zumindest bis zur nächsten NTP-Abfrage wieder mit der falschen Zeit laufen. Bei einer zu großen Abweichung scheitert dann wohl auch die Abfrage an sich und die Systemzeit läuft gänzlich willkürlich.
Volle Zustimmung. Ich bin allerdings davon ausgegangen, dass der NTP Service der OPNsense in regelmäßigen Abständen seine Zeitquelle abfragt und die Zeit der OPNsense entprechend stellt.
Das ist vielleicht eine Annahme, die schlicht falsch ist, das weiß ich nicht. Falls das zutrifft, dann würde ich bei meinen Netzen dringend Anpassungen vornehmen müssen. Ich habe gerade in die OPNsense Doku geschaut und keine Info über die Regelmäßigkeit/Häufigkeit der Zeitabfrage gefunden.
Falls die Zeit der OPNsense dramatisch schnell in die Differenz läuft, könnte dieses Intervall doch verkürzt werden? Aber ich denke, das ist in Deinem Fall eher Arbeiten an einem Symptom und nicht an der Ursache.
Alle Fragen nach der Zeit (123/TCP / 123/UDP) aus dem LAN werden von Firewall/Gatway/Router auf diese Maschine umgelenkt.
Das wäre ja nur dann erforderlich, wenn an einem Client im LAN der Zeitserver hard-coded wäre und man Zeitabweichungen zwischen dem eigenen internen Zeitserver und dem hart kodiertem öffentlichen vermeiden wöllte. Das ist bei meinen Geräten nicht der fall. Hier kann ich die Adresse des Zeitservers überall statisch festlegen, oder via DHCP übergeben. Eventuelle zeitabweichungen sollten aber auch nicht allzu gravierend sein.
Schon alles erlebt (und teilweise noch aktuell): Geräte, die einen Zeitserver in taiwan fest codiert hatten; Geräte, die sich nicht um einen eingetragenen Zeitserver scheren; Geräte die den DHCP-Parameter mit dem zu nutzenden Zeitserver schlicht ignorieren. Und das quer durch Server- und Client-Betriebssysteme oder embedded devices. Das hat mich am Ende zu "meiner" best practice geführt.
LG
-
Was ich gelesen habe fragt der NTP-Dienst regelmäßig seine Zeitquelle ab, legt den Intervall hierfür aber eigenständig fest. Man kann dieses Verhalten wohl beeinflussen indem man einen Minimalwert und einen Maximalwert (http://www.ntp.org/ntpfaq/NTP-s-algo.htm#Q-POLL-RANGE) dafür festlegt.
Häufigeres Abfragen würde die Probleme sicherlich verringern, aber wohl nicht beheben.
Einige Zeitserver blocken die Peers bei zu häufigen Anfragen. Ich müsste dann zwangsläufig auf die Variante mit dem dediziertem Zeitserver im LAN arbeiten.
Grundsätzlich gibt es aber einige Dienste die Probleme mit den Zeitsprüngen haben die sich bei den Sychronisationen ergeben. Das lässt sich wohl nur lösen indem die eigentlich Ursache gefunden und behoben wird.
Hier klingt für mich der Ansatz mit den Zeitzählern (https://www.thomas-krenn.com/de/wiki/FreeBSD_Timecounters)sehr vielversprechend.
Allerdings weiß ich leider noch nicht wie ich die nötigen Anpassungen vornehmen kann und welches die richtigen Werte seitens Unraid und seitens OPNsense wären.
-
Ok geh mal auf die OPNsense Shell
Was gibt sysctl kern.timecounter.hardware zurück?
Bei meinen Vms mit Proxmox kommt HPET.
-
root@ADL15-FW001:~ # sysctl kern.timecounter.hardware
kern.timecounter.hardware: ACPI-fast
Hier kommt ACPI-fast.
Wie kann ich das umstellen?
-
<clock offset='utc'>
<timer name='rtc' tickpolicy='catchup'/>
<timer name='pit' tickpolicy='delay'/>
<timer name='hpet' present='no'/>
evtl. beim unraid mal das hpet auf yes
-
Vielen Dank für diesen Tipp!!
root@ADL15-FW001:~ # sysctl kern.timecounter.hardware
kern.timecounter.hardware: HPET
OPNsense nutzt jetzt tatsächlich HPET.
root@ADL15-FW001:~ # dmesg | grep Timecounter
Timecounter "HPET" frequency 100000000 Hz quality 950
Timecounter "ACPI-fast" frequency 3579545 Hz quality 900
Timecounter "i8254" frequency 1193182 Hz quality 0
Timecounters tick every 10.000 msec
root@ADL15-FW001:~ # sysctl kern.timecounter
kern.timecounter.tsc_shift: 1
kern.timecounter.smp_tsc_adjust: 0
kern.timecounter.smp_tsc: 0
kern.timecounter.invariant_tsc: 0
kern.timecounter.fast_gettime: 1
kern.timecounter.tick: 1
kern.timecounter.choice: i8254(0) ACPI-fast(900) HPET(950) TSC-low(-100) dummy(- 1000000)
kern.timecounter.hardware: HPET
kern.timecounter.alloweddeviation: 5
kern.timecounter.timehands_count: 2
kern.timecounter.stepwarnings: 0
kern.timecounter.tc.i8254.quality: 0
kern.timecounter.tc.i8254.frequency: 1193182
kern.timecounter.tc.i8254.counter: 49369
kern.timecounter.tc.i8254.mask: 65535
kern.timecounter.tc.ACPI-fast.quality: 900
kern.timecounter.tc.ACPI-fast.frequency: 3579545
kern.timecounter.tc.ACPI-fast.counter: 3004578
kern.timecounter.tc.ACPI-fast.mask: 16777215
kern.timecounter.tc.HPET.quality: 950
kern.timecounter.tc.HPET.frequency: 100000000
kern.timecounter.tc.HPET.counter: 2725944664
kern.timecounter.tc.HPET.mask: 4294967295
kern.timecounter.tc.TSC-low.quality: -100
kern.timecounter.tc.TSC-low.frequency: 1908553173
kern.timecounter.tc.TSC-low.counter: 1216703817
kern.timecounter.tc.TSC-low.mask: 4294967295
Ich werde die Zeit jetzt mal genau im Auge behalten.
-
Es sah vielversprechend aus, kam dann aber doch wieder zu Abweichungen.
Ich hatte das Verhalten jetzt seit den Anpassung vorhin beobachtet.
Die Zeit verlief wunderbar synchron, bis diese Meldungen im NTP-Protokoll auftauchten:
2021-05-15T17:44:15 ntpd[78666] receive: Unexpected origin timestamp 0xe44a6acf.564f8c38 does not match aorg 0000000000.00000000 from server@2001:638:809:7::7 xmt 0xe44a6acf.c7f0dbb0
2021-05-15T17:44:15 ntpd[78666] receive: Unexpected origin timestamp 0xe44a6acf.5659de65 does not match aorg 0000000000.00000000 from server@2001:638:610:be01::104 xmt 0xe44a6acf.c6d26f56
2021-05-15T17:44:15 ntpd[78666] receive: Unexpected origin timestamp 0xe44a6acf.5656d4d0 does not match aorg 0000000000.00000000 from server@2001:638:a000:1123:123::2 xmt 0xe44a6acf.c67a89cb
Im "Status" stehen seitdem alle Server auf Unerreichbar/Ausstehend.
Erst nach Neustart des ntpd-Dienstes wird wieder mit den NTP-Servern synchronisiert.
Was bedeutet die Fehlermeldung und wie kann ich den Fehler beheben?
-
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 (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.
-
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?
-
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 (https://aixperts.blogspot.com/2012/11/configuring-ntp-server-without-internet.html)
Gruß
KH
-
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:
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.
-
Habe hier viel gelernt, danke dafür.
-
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
-
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 dmesg | grep Timecounter und 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.
-
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:
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?
-
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
-
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
-
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!
-
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?
-
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
-
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.
-
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
-
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.
-
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 (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 (https://www.it-lu.de/start/zeitserverliste) oder https://www.heise.de/ct/hotline/Oeffentliche-Zeitquellen-322978.html (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
-
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. :)
-
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.
-
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
-
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
-
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
-
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.
-
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
(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
-
Hi,
wenn ich mir auf der Seite https://docs.ntpsec.org/latest/clock.html#step (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
-
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 (https://chrony.tuxfamily.org/comparison.html) 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
-
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
-
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. :)
-
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.
-
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.