Qu'est-ce que la dispersion NTP et comment la contrôler?

Nous déployons des serveurs Ubuntu 14.04 sur des réseaux isolés, exécutant ntpd 4.2.6p5, configurés pour utiliser plusieurs serveurs NTP fournis par les clients (pas d'accès à pool.ntp.org). Nos appareils clients terminaux stupides exécutent une ancienne version de BusyBox (1.00-rc2) et ntpclient 2010 de Larry Doolittle.

Cette configuration a très bien fonctionné pendant des années, mais nous avons récemment rencontré un obstacle avec un nouveau client. Ils nous ont fourni 5 adresses de serveurs NTP internes qui semblent très bien fonctionner seules, en ce qui ntpdate-debianconcerne le serveur Linux. Côté BusyBox cependant, se ntpclientplaint de "Dispersion trop élevée". À partir de la sortie de débogage, ntpclientobtient "1217163.1" du serveur NTP mais la valeur maximale qu'il prend en charge est absolue (65536).

$ /usr/sbin/ntpclient -s -i 15 -h 10.17.162.250 -d
Configuration:
  -c probe_count 1
  -d (debug)     1
  -g goodness    0
  -h hostname    10.17.162.250
  -i interval    15
  -l live        0
  -p local_port  0
  -q min_delay   800.000000
  -s set_clock   1
  -x cross_check 1
Listening...
Sending ...
recvfrom
packet of length 48 received
Source: INET Port 123 host 10.17.162.250
LI=0  VN=3  Mode=4  Stratum=4  Poll=4  Precision=-20
Delay=60745.2  Dispersion=1346801.8  Refid=10.31.10.21
Reference 3668859928.942079
(sent)    3668859928.708371
Originate 3668859928.708371
Receive   3668859928.963271
Transmit  3668859928.963369
Our recv  3668859928.708371
Total elapsed:      0.00
Server stall:      93.09
Slop:             -93.09
Skew:          255443.94
Frequency:             0
 day   second     elapsed    stall     skew  dispersion  freq
42463 56728.708  rejected packet: abs(DISP)>65536

Ce sont tous des appareils sur le même réseau local, donc franchement, je suis sidéré. Consterné même.

Voici la ntpq -pnsortie du serveur Ubuntu 14.04:

user@host:~$ ntpq -pn
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 127.127.1.0     .LOCL.          10 l 1025   64    0    0.000    0.000   0.000
 10.17.162.249   10.17.6.10       5 u   23 1024   37    0.865  1381.07 697.260
 10.31.10.22     .LOCL.           1 u 1044 1024   17   29.586  -838.06 397.342
 10.17.6.10      10.31.10.21      4 u 1065 1024   17    0.366  105.245 402.999
*10.31.10.21     132.246.11.238   3 u    5 1024   37   29.418  794.292 616.796
 10.17.6.11      10.31.10.21      4 u 1038 1024   17    0.408  120.030 381.058

Mes questions sont:

1. Qu'est-ce que la dispersion et qu'est-ce qui peut altérer sa valeur?
2. Quelles commandes pourrais-je exécuter pour obtenir plus de détails des serveurs NTP?
3. La faute pourrait-elle résider du côté du serveur Ubuntu, avec un mauvais ntp.conf? Il n'y a vraiment rien de spécial.
4. Le passage à Chrony changerait-il quoi que ce soit dans ce cas?

Je vois une certaine confusion dans les réponses ici. Pour commencer, ntpclientau moins en -smode, n'agit pas comme un client NTP complet, il envoie et reçoit seulement un paquet , donc il n'y a pas de "8 derniers paquets reçus". Il ne s'agit pas du tout d'estimer sa propre dispersion.

Au lieu de cela, la valeur qu'il imprime est la valeur appelée "dispersion racine" (rootdisp) dans le paquet renvoyé par le serveur, qui est une estimation de la quantité totale d'erreur / variance entre ce serveur et l'heure correcte. La façon dont cela est calculé est assez simple: chaque serveur NTP tire son heure d'une horloge externe (par exemple un récepteur radio ou GPS), ou d'un autre serveur NTP. Si un serveur tire son heure d'une horloge externe, sa dispersion racine est l'erreur maximale estimée de cette horloge. S'il obtient son heure d'un autre serveur NTP, sa dispersion racine est la dispersion racine de ce serveur plus la dispersion ajoutée par la liaison réseau entre eux.

Un point de confusion ici est que, alors que ntpq et chrony affichent la dispersion et la dispersion racine en secondes, ce à quoi les gens sont habitués, ntpclient l'affiche en microsecondes . Quoi qu'il en soit, une valeur de 1217163 est encore assez élevée. Un bon serveur NTP connaît l'heure en quelques millisecondes; une mauvaise en quelques dizaines ou centaines de millisecondes. Le vôtre vous dit que son heure ne peut être fiable qu'en +/- 1,2 seconde.

De toute façon, vous pouvez obtenir la synchronisation de ntpclient avec ce serveur en passant l' option -x 0ou -t(selon la version de ntpclient), qui désactive les vérifications d'intégrité NTP. Si vous n'avez besoin que d'un temps approximativement précis (en quelques secondes), cela peut être suffisant. Cependant, ntpclient est assez raisonnable en refusant de se synchroniser avec un serveur aussi mauvais. Votre ntpqsortie sur la machine Ubuntu affiche une gigue de centaines de millisecondes pour tous ses serveurs, même si leur délai est faible, ce qui indique soit un réseau très peu fiable, une conspiration de tous les serveurs pour fournir un temps erratique, soit une base problème de chronométrage sur le serveur lui-même.

Cela m'inquiète également que le serveur 10.31.10.22 annonce un refid de LOCL(horloge locale indisciplinée) mais a une strate de 1. Habituellement, l'horloge locale est truquée à une strate de 10 afin qu'elle ne soit utilisée que comme source de synchronisation de dernier recours pour empêcher un troupeau de se séparer. Soit 10.31.10.22 est mal configuré et fournit du mauvais temps au reste du réseau, soit il est discipliné à temps par un programme indépendant de la volonté de NTP, auquel cas la mauvaise configuration est simplement qu'elle annonce le LOCLrefid; il doit être ignoré, par exemple, GPSou tout ce qui donne son temps.

Juste une réponse partielle pour "Qu'est-ce que la dispersion?":

Un aller-retour NTP typique:

client |        | server
    t1 |------->| t2
    t3 |<-------| t4

Cela donne deux valeurs, le décalage (la différence de temps entre le client et le serveur) et le retard (essentiel le temps de trajet du réseau) avec les formules suivantes:

offset= ((t4 - t3) + (t1 - t2)) / 2
delay = (t4 - t1) - (t3 - t2)

Le client sélectionne le décalage actuel parmi les 8 derniers paquets reçus, en choisissant celui avec le plus petit retard.

Les mêmes 8 paquets sont utilisés pour calculer la dispersion en faisant une moyenne pondérée de la différence de ces 8 décalages avec celle sélectionnée à la dernière étape, où le retard est utilisé comme facteur de pondération, donnant plus de poids aux plus petits retards. C'est une mesure de la «propagation» des valeurs et utilisée pour calculer la qualité d'un serveur de temps, surtout si vous avez plusieurs choix.

Votre dispersion et asymétrie sont énormes, il y a un très grand décalage entre l'horloge locale et ce pair. Vous devez comparer les décalages avec le local dateet régler l'horloge manuellement.

Lancez ntpd et affichez à ntpq -ppartir d'un hôte en utilisant tous les pairs. Il sélectionnera les meilleurs.

Selon la documentation de ce Cisco , "la dispersion , rapportée en secondes, est la différence de temps d'horloge maximale jamais observée entre l'horloge locale et l'horloge du serveur". Avec des serveurs ntp qui ne sont pas totalement cassés, une dispersion élevée ne devrait jamais se produire. Le seul scénario possible est lorsque votre client init ntp et que jusqu'à présent, seule son horloge locale est disponible. Et même alors, une dispersion aussi élevée que vous le signalez correspond à des horloges qui sont éteintes de plus de deux semaines .

Il devrait être suffisant de s'assurer que l'horloge locale n'est pas trop éloignée au début (même quelques heures seraient toujours acceptables), soit en ajustant l'horloge (et même la date!) Dans le BIOS ou en émettant ntpdateune fois avant de commencer ntpdsur le client.