Pourquoi la synchronisation NTP est-elle effectuée sur LOCAL plutôt que sur un serveur distant?

Donc, j'essaie de déboguer ma configuration NTP actuelle, et j'ai constaté que le décalage par rapport à mon serveur configuré unique dure plus de 3 secondes et ne s'ajuste pas. L'astérisque sur le LOCAL (0) dans la sortie ntpq semble indiquer que le système se synchronise avec lui-même plutôt que le serveur 10.130.33.201 (qui est une autre boîte Linux sur notre système sur laquelle nous voulons que tout se synchronise).

ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 10.130.33.201   LOCAL(0)         9 u   49   64  377    0.242  -3742.2   1.049
*LOCAL(0)        .LOCL.          10 l    2   64  377    0.000    0.000   0.001

Et ceci est mon fichier ntp.conf. Écrit par quelqu'un d'autre, donc je ne suis pas sûr à 100% que tout est correct.

server 10.130.33.201 burst iburst minpoll 4 maxpoll 11
driftfile /mnt/active/etc/ntp.drift

restrict -4 default  nomodify nopeer notrap
restrict -6 default  ignore

# Undisciplined Local Clock. This is a fake driver intended for backup
# and when no outside source of synchronized time is available.
server  127.127.1.0     # local clock
fudge   127.127.1.0 stratum 10

J'ai lu au sujet de la rafale et iburst et minpoll / maxpoll, donc je me rends compte que ceux-ci pourraient ne pas être nécessaires, mais je ne pense pas que cela ait quelque chose à voir avec mon problème actuel.

De plus, en raison de la façon dont il est déployé, ce fichier de configuration prendra beaucoup de travail à modifier, donc j'espère qu'il n'y a vraiment rien à changer. J'espère que c'est un cas où je ne comprends pas comment fonctionne NTP.

ÉDITER -

Donc, il semble que ce soit un doublon de Cette question , mais je ne pense pas que l'affiche ait obtenu une réponse suffisante, donc je voudrais toujours savoir pourquoi l'heure locale est préférée au serveur. De plus, selon l'une des réponses ci-dessous, j'ai essayé d'utiliser le prefermot - clé sur la ligne du serveur de la configuration et de redémarrer, mais cela ne semble pas avoir eu d'effet.

Si je supprime toutes les lignes "locales" de la configuration comme le suggère la réponse à l'autre question, que se passera-t-il si le serveur est inaccessible? Le NTP meurt-il ou continue-t-il à essayer?

MODIFICATION IMPORTANTE -

Ok, normalement, 10.130.33.201 (le "serveur") n'a pas accès à Internet et n'a pas de source horaire GPS à utiliser. La partie importante est que tous les périphériques du système ont la même heure que le serveur, quelle que soit l'heure exacte.

Donc, juste pour voir ce qui se passerait, j'ai ajouté l'un des serveurs de pool NTP au fichier de configuration du serveur afin qu'il obtienne du temps à partir de là plutôt que du temps local. Il obtient désormais correctement l'heure du serveur de temps NTP.

Après cela, les clients se synchronisent maintenant avec le serveur plutôt que de préférer LOCAL (0)

 ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*10.130.33.201   38.229.71.1      3 u   58   64  377    0.216  715621.   1.001
 LOCAL(0)        .LOCL.          10 l   18   64  377    0.000    0.000   0.001

NOUVELLE QUESTION - Lorsque mon serveur utilise local (exemple original qui a été donné), il semble que les clients disent: "Oh, 10.130.33.201 utilise LOCAL (0). Hmm, j'ai aussi un serveur LOCAL (0) - - Je vais simplement l'utiliser directement plutôt que d'obtenir les mêmes informations via 10.130.33.201 ".

Est-ce le cas? Essayent-ils d'aller "directement à la source" qui est incorrectement LOCAL (0)? J'ai besoin que mon serveur obtienne l'heure de LOCAL (0), et j'ai besoin que les clients obtiennent l'heure du serveur. En ce moment, la suppression du serveur "local" des fichiers de configuration du client est la seule option, mais je voudrais comprendre pourquoi cela se produit, et si possible, éviter de changer leurs configurations (le changement de configuration sera beaucoup de travail à cause de notre environnement...).

En outre, cela ressemble à un autre doublon sans bonne réponse.

Avec un seul serveur NTP configuré, l'algorithme ne sait pas vraiment à qui faire confiance. Même si la strate est plus faible avec l'hôte distant, je parie que l'algorithme pense que l'heure locale est plus fiable.

Essayez d'utiliser le prefermot - clé avec votre serverdéclaration pour définir cela comme une source de temps préférentielle.

ÉDITER -

Donc, il semble que ce soit un doublon de Cette question, mais je ne pense pas que l'affiche ait obtenu une réponse suffisante, donc je voudrais toujours savoir pourquoi l'heure locale est préférée au serveur.

Pour une réponse vraiment suffisante, vous allez creuser dans les entrailles d'un algorithme très complexe. La documentation n'est même pas trop précise, mais je suis sûr qu'il existe un livre blanc ou des spécifications.

Si je supprime toutes les lignes "locales" de la configuration comme le suggère la réponse à l'autre question, que se passera-t-il si le serveur est inaccessible? Le NTP meurt-il ou continue-t-il à essayer?

Le démon NTP ne meurt pas ou ne s'arrête pas, mais il quitte la synchronisation de l'heure après avoir échoué à atteindre le serveur distant. C'est pourquoi les meilleures pratiques suggèrent un minimum de trois serveurs distants et ne pas utiliser la LCL à moins que vous ne soyez déconnecté du réseau. Trois serveurs sont proposés car quand il n'y en a que deux, et qu'ils ne sont pas d'accord, lequel choisira-t-il? Le troisième serveur devrait aider l'algorithme à éliminer le faux serveur.

Enfin, je viens de remarquer que vous ne définissez pas a driftfile. Cela pourrait aider?

Il me semble que l'intervalle de décalage (différence entre l'heure de votre système et celle de l'hôte NTP) est trop différent pour que NTP le règle correctement.

Ma suggestion,

 1. Stop the NTP service
 2. As root ntpdate -bs 10.130.33.201 to reset your time to something close
 3. Start the NTP service

Vous ne devriez avoir aucun problème après cela.

La strate de 10.130.33.201 en tant que serveur LOCAL est 9, ce qui fait que la strate locale calculée à partir de cela (9 + 1 = 10) est en concurrence avec le serveur LOCAL local de la strate 10. Étant donné que la strate LOCAL locale n'a pas de retards ou de gigue sur le réseau, elle peut sembler légèrement meilleur à ntpd que celui distant.

Si vous voulez que cette configuration fonctionne, définissez le serveur LOCAL «maître» sur une strate inférieure à 9. Pas trop bas si vous voulez qu'une heure traçable sur un serveur de la strate 1 soit préférée.

Je sais que c'est vieux, mais je pense que vous avez raison. Personne ne montre aucun moyen de déboguer les problèmes ntpd. Il s'avère que c'est faisable.

Je pense que vous étiez sur la bonne voie lorsque vous soupçonniez que l'utilisation de LOCAL (0) localement et sur le serveur en amont pourrait être un problème.

C'était certainement sur une île temporelle de 4 serveurs avec laquelle j'ai eu un problème similaire. Ils étaient tous prêts à être des pairs les uns des autres, donc peut-être un problème différent du vôtre.

Tout d'abord, il existe un meilleur moyen de gérer les îlots de temps appelé mode orphelin qui est pris en charge par les versions ntpd des dernières années:

Mode orphelin sur doc.ntp.org

Initialement, les 4 serveurs avaient la même strate de 10 et préféraient leur horloge locale. J'ai corrigé cela et ils ont quand même préféré leur horloge locale (la strate semble cependant être importante).

J'ai utilisé la commande ntpq pe (peer), as, rv pour avoir une idée de ce qui se passait. Vous devez utiliser rv (readvar) sur le numéro d'association du serveur pour vider les informations. pe et as semblent être triés par le même index afin que vous puissiez obtenir le nombre as de cette façon. tout comme un champ appelé condition qui peut afficher la valeur rejeter s'il n'aime pas le serveur.

Dans la sortie RV est un champ appelé flash. Si tout va bien, ce sera zéro. Sinon, c'est un masque de bits (affiché en hexadécimal) des problèmes. Ils peuvent être consultés ici:

décodage interne ntpd

Le problème que j'ai eu était 0800 peer_loop. Il s'est avéré que le refid de l'horloge est important. Voir LOCAL (0) à la fois sur l'horloge locale et sur le serveur distant avait ntpd pensant qu'il y avait une boucle. David Mills confirme que dans les publications sur comp.protocols.time 'Comment éviter la boucle dans NTP' (j'ai atteint ma limite de 2 liens, désolé!)

L'utilisation de l'argument refid pour fudge pour définir un refid unique n'a pas fonctionné - il apparaît toujours comme LOCAL (0) au destinataire.

Ce qui semble fonctionner, c'est l'utilisation de numéros d'instance uniques pour le pilote local. 127.127.1. [0-3]. Utilisez le même ID sur le serveur et la ligne de fudge. Lorsque je l'ai fait, les serveurs se sont généralement synchronisés avec le serveur de couche le plus bas qui utilisait généralement son horloge locale. Cependant, il a parfois essayé d'utiliser l'un des autres serveurs qui l'utilisaient comme source. Cependant, les temps se sont synchronisés et semblent rester ainsi.

Probablement beaucoup trop tard pour aider, mais je le propose pour montrer que NTP se prête à la logique et au dépannage. J'ai mis des heures à atteindre la réponse par essais et erreurs, puis j'ai trouvé les documents plus tard.

Utilisez iburst pour forcer le serveur à envoyer la demande NTP au NTS souhaité même si une demande échoue