
Ich muss einen NTP-Multicast-Client einrichten. Um zu überprüfen, ob meine Konfiguration gut ist, versuche ich, einen NTP-Multicast-Server einzurichten.
Mein Setup:
- 2 VM von Centos 7, aktuell
- Ich verwende 2 virtuelle Maschinen in Virtualbox, ich habe beide mit Promicius-Modus eingerichtet: alle zulassen
Meine Probleme sind:
- Auf dem Server wird der Multicast-Eintrag als Stratum 16 gemeldet. Ist Stratum für Multicast relevant? Lehnt der Client dies ab, da das Stratum niedrig ist? Wie kann ich für einen Multicast-Server ein niedrigeres Stratum erzwingen?
- Mein Kunde scheint nichtsehenmein Server, auch wenn meine Schlüsseldateien identisch sind und ich dem Schlüssel 1 auf beiden Seiten vertraut habe.
Die Verwendung der Anweisungen für Orphan scheint die gemeldete Schicht für die Multicast-Adresse nicht zu senken:
ntpq -n -p
remote refid st t when poll reach delay offset jitter
==============================================================================
*192.165.10.2 192.165.10.109 4 u 14 64 377 0.454 2.267 1.479
224.0.1.1 .MCST. 16 u - 64 0 0.000 0.000 0.000
Und mein Client scheint immer noch nicht in der Lage zu sein, einen Server unter der Adresse 224.0.1.1 zu finden.
Ich habe die Server-VM, meinen Host-Rechner und die Client-VM überprüft. Sie alle sehen die Server-Multicast-Nachrichten (für die VM: mit TCPdump, für den Host: mit Wireshark).
Auf dem Client ntpq -n -p
wird durch using Folgendes zurückgegeben:
No association ID's returned
Auf dem Client sind in meiner Konfigurationsdatei alle Einschränkungsanweisungen kommentiert, und ich habe nur diese (und noch einige mehr, wie Driftfile und so):
multicastclient 224.0.1.1
keys /etc/ntp/keys
trustedkey 1
Das NTP-Clientprotokoll gibt mir Folgendes aus:
systemd[1]: Starting Network Time Service...
ntpd[11076]: ntpd [email protected] Tue Jun 23 15:38:18 UTC 2020 (1)
systemd[1]: Started Network Time Service.
ntpd[11077]: proto: precision = 0.052 usec
ntpd[11077]: 0.0.0.0 c01d 0d kern kernel time sync enabled
ntpd[11077]: ntp_io: estimated max descriptors: 1024, initial socket boundary: 16
ntpd[11077]: Listen and drop on 0 v4wildcard 0.0.0.0 UDP 123
ntpd[11077]: Listen and drop on 1 v6wildcard :: UDP 123
ntpd[11077]: Listen normally on 2 lo 127.0.0.1 UDP 123
ntpd[11077]: Listen normally on 3 enp0s3 192.165.10.107 UDP 123
ntpd[11077]: Listen normally on 4 lo ::1 UDP 123
ntpd[11077]: Listen normally on 5 enp0s3 fe80::a00:27ff:fec1:cc1 UDP 123
ntpd[11077]: Listening on routing socket on fd #22 for interface updates
ntpd[11077]: Listen normally on 6 multicast 224.0.1.1 UDP 123
ntpd[11077]: Joined 224.0.1.1 socket to multicast group 224.0.1.1
ntpd[11077]: 0.0.0.0 c016 06 restart
ntpd[11077]: 0.0.0.0 c012 02 freq_set kernel 0.000 PPM
ntpd[11077]: 0.0.0.0 c011 01 freq_not_set
ntpd[11077]: io_setbclient: Opened broadcast client on interface #3 enp0s3
Antwort1
Stratum 16 zeigt an, dass der NTP-Server glaubt, keine gültige Zeit zu haben, da er keine Verbindung zu einer konfigurierten Zeitquelle hat. Damit ntpd
das Serversystem der lokalen Uhr des Systems als Zeitquelle vertraut, gibt es zwei Möglichkeiten:
tos orphan
Die moderne Methode besteht darin, die Schlüsselwörter undtos orphanwait
in der Datei auf dem Multicast-Server anzugebenntp.conf
.
# If orphaned, serve others with this stratum.
tos orphan 8
# Wait for this many seconds before starting to serve others (default is 300 s)
tos orphanwait 1
- Die ältere Methode besteht darin,
ntpd
die lokale Uhr als falsche Zeitquelle auf dem Multicast-Server zu verwenden. Diese Konfigurationsollte nicht zusammen mit echten NTP-Zeitquellen verwendet werden, da dies dazu führen könnte,ntpd
dass der lokalen Uhr statt den echten NTP-Quellen geglaubt wird, es sei denn, es wurde eine ausreichende Anzahl externer Quellen konfiguriert und diese sind gut genug miteinander synchronisiert, um die Pseudoquelle 127.127.1.0 zu überstimmen (die immer perfekt mit der lokalen Uhr übereinstimmt und deshalb dazu neigt, vomntpd
Auswahlalgorithmus übermäßig bevorzugt zu werden).
server 127.127.1.0 iburst
fudge 127.127.1.0 stratum 8
Die mit beginnenden IP-Adressen 127.127.*
sind speziell für ntpd
: Sie beziehen sich auf verschiedene in integrierte Referenztakttreiber ntpd
.
Beide Methoden sorgen dafür, dass das System die UTC-Zeit basierend auf der lokalen, nicht synchronisierten Systemuhr über NTP unter Verwendung von Stratum 8 bereitstellt. Daher sollten alle Systeme mit einer einigermaßen direkten Verbindung zu einer echten NTP-Zeitquelle (= Stratum 7 oder weniger) diese Methode dieser vorziehen.
Die Verwendung der neueren Methode wird empfohlen, wenn Ihre Version ntpd
dies unterstützt, da Sie damit nicht daran denken müssen, die Pseudoquelle zu entfernen, falls Sie dem System echte NTP-Zeitquellen hinzufügen.