NTP fudge network strate source

Est-il possible de configurer ntpdpour truquer le niveau de strate d'une source réseau?

À première vue, j'ai pensé que la fudgedirective pouvait accomplir cela, mais après avoir parcouru les ntp.conf(5)pages de manuel, j'ai trouvé que cette directive ne s'applique qu'aux horloges de référence.

Quelques détails:

J'ai un serveur local fonctionnant ntpdcomme source de temps principale pour les clients sur le LAN. Ce serveur pointe vers le pool ntp.org et maintient généralement un niveau de strate 3.

En plus de mon serveur principal, j'ai un périphérique réseau tiers dont la tâche principale est de synchroniser les horloges murales sans fil via. Transmission RF. La spécification de l'appareil indique qu'il s'agit d'un "serveur de temps compatible RFC2030", mais sinon, il s'agit à peu près d'une boîte noire. J'ai configuré l'appareil pour utiliser mon serveur principal car c'est la seule source de temps:

config boîte noire http://www.freeimagehosting.net/uploads/21bafb12bd.png

Mon problème est apparu lorsque j'ai configuré ntpdsur mon ordinateur personnel pour utiliser à la fois mon serveur NTP principal et l'émetteur sans fil comme sources de temps. En interrogeant mon ntpd local, j'ai remarqué que la "boîte noire" (10.xxZ) était la source de temps préférée:

$ ntpq -pn
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
x10.x.x.X        69.164.222.108   3 u   48   64  177    0.501  370.029   1.530
*10.x.x.Z        10.x.x.Z         2 u   50   64  377    1.354  -23.681  14.179

Étant donné que 10.x.x.Zla seule source de temps du serveur est le serveur 10.x.x.X(qui est la strate 3), il devrait s'agir de la strate 4. Je pense que le fabricant a codé en dur son niveau de strate.

Existe-t-il un moyen d'amener ma machine à privilégier le "bon" serveur (10.xxX) malgré son niveau de strate plus élevé? J'ai également essayé la preferdirective dans mon ntp.conffichier local , mais en vain, la petite boîte noire gagne toujours: /

Pour ce que ça vaut, ma machine locale exécute Mac OS X 10.6.

$ ntpq -c rv | grep version
version="ntpd [email protected] Mon May 18 19:38:25 UTC 2009 (1)",

Après quelques recherches supplémentaires, il semble "fudging" le niveau de strate d'une source réseau n'est pas possible. J'ai donc continué et essayé la réponse de dtoubeli . À ma grande surprise, le simple fait de faire de mon serveur de temps local un niveau de strate 2 (égal au périphérique tiers) ne l'a pas toujours fait être la source de temps préférée. Mon ntpd local les gouvernerait toujours tous les deux en tant que "faux ticks". Pour quelle raison, je ne suis pas sûr, mais je devine parce qu'ils étaient les deux seules sources de temps, et leurs temps étaient si loin.

Le plus gros problème ici est le fait que mon appareil tiers ne semble pas tenir un temps très cohérent, en fait il fluctue beaucoup. La solution à mon problème consistait à ajouter plusieurs autres sources de temps précises (pool.ntp.org) à mon /etc/ntp.conf. Maintenant, mon serveur local est toujours choisi comme source de temps préférée, souvent malgré un niveau de strate plus élevé que certains des serveurs du pool.

Vous pouvez essayer d'exécuter votre ntpd local sur la strate 2. Au lieu de le pointer vers pool.ntp.org, créez simplement une liste de 5-7 serveurs de la strate 1 et ajoutez-les directement à la configuration. Avec le serveur de référence sur la strate 1, le vôtre fonctionnera sur la strate 2. Ensuite, votre preferoption peut fonctionner.

Cependant, d'après mon expérience, le niveau de la strate n'est pas toujours le facteur gagnant dans l'élection de source primaire. Je pense que la latence et la gigue ont également une influence significative. J'avais remarqué à plusieurs reprises que le serveur de couche inférieure a été choisi comme source principale même s'il y avait plusieurs serveurs de couche supérieure disponibles uniquement parce qu'il avait la latence la plus faible. C'est pourquoi je ne peux garantir que l'approche suggérée fonctionnera.

J'ai une source de temps GPS matérielle "haute couche (10)" dans notre réseau local qui me donne un état falsetick (x) dans ntpq, j'ai trouvé que l'utilisation de server [x.x.x.x] true(x = adresse IP) dans ntp.conf contournerait la vérification de falsetick, lui permettant d'être un candidat possible. Il semble que le numéro de strate ne signifie pas toujours une priorité plus élevée.

Si vous n'aimez pas ce serveur 10.xxZ comme référence, cela devrait faire l'affaire:

server 10.x.x.Z noselect 

Ceci est utile si le serveur ne doit être utilisé que pour des raisons de surveillance. vous pouvez également configurer:

server 10.x.x.X prefer

Par conséquent, 10.xxZ ne sera pas utilisé si 10.xxX est disponible.

L'une des raisons pour lesquelles il est préférable est que votre autre serveur de temps ait été inaccessible récemment. Voir la colonne d'audience?