Das NTP- Deamon wird häufig im einfachsten Modus verwendet, nämlich Client / Server: Sie geben eine oder mehrere serverAnweisungen in Ihrem an, ntp.confund Ihre Clients verwenden diese Server.
Wenn Sie Ihre eigenen NTP-Server ausführen, empfiehlt es sich außerdem, peerdiese gemeinsam zu nutzen. Wenn einer von ihnen die Verbindung zu seinen Upstream-Servern verliert, erhält er Zeit von seinen Kollegen.
NTPd kann aber auch mit Broadcast- und / oder Multicast-Verteilung von Zeitdaten arbeiten. In der Dokumentation heißt es:
Broadcast- und Multicast-Modi sind für Konfigurationen vorgesehen, an denen ein oder mehrere Server und eine möglicherweise sehr große Client-Population beteiligt sind
Die Dokumentation sagt auch anderswo :
Es ist möglich und häufig nützlich, einen Host sowohl als Broadcast-Client als auch als Broadcast-Server zu konfigurieren. Eine Reihe von Hosts, die auf diese Weise konfiguriert wurden und eine gemeinsame Broadcast-Adresse gemeinsam nutzen, organisieren sich automatisch in einer optimalen Konfiguration, die auf Schicht und Synchronisationsentfernung basiert.
Ich sehe einen offensichtlichen administrativen Vorteil: Sie müssen Ihre Liste der NTP-Server in den Clients nicht manuell angeben und aktualisieren. Daher erscheint ntp.confes mir verlockend, den Broadcast-Modus auch für eine kleine Client-Population (z. B. 5+ Clients mit 3) zu verwenden ~ 4 Server). Ich erwarte, dass der Netzwerkverkehr bei Broadcasts anstelle von Client / Server-Zuordnungen etwas höher ist, aber angesichts des üblichen Gigabit-Ethernet-LAN sollten die Auswirkungen vernachlässigbar sein, es sei denn, Sie haben eine sehr große Anzahl von Hosts in derselben Broadcast-Domäne.
Wann sollte am Ende des Tages der Broadcast-Modus verwendet oder vermieden werden? Gibt es Vor- und Nachteile, die ich nicht gesehen habe?