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). Notre client terminal stupide les appareils exécutent une ancienne version de BusyBox (1.00-rc2) et ntpclient 201 de Larry Doolittle.
Cette configuration a très bien fonctionné pendant des années, mais récemment, nous avons rencontré un obstacle avec un nouveau client. Ils nous ont fourni 5 = NTP adresses de serveur internes qui semblent très bien fonctionner par elles-mêmes, pour autant que ntpdate-debian est concerné sur le serveur Linux. Côté BusyBox cependant, ntpclient se plaint de "Dispersion trop élevée". À partir de la sortie de débogage, ntpclient obtient "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 le ntpq -pn sortie 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:
- Qu'est-ce que la dispersion et qu'est-ce qui peut altérer sa valeur?
- Quelles commandes pourrais-je exécuter pour obtenir plus de détails des serveurs NTP?
- La faute pourrait-elle résider du côté du serveur Ubuntu, avec une mauvaise
ntp.conf? Il n'y a vraiment rien de spécial. - Le passage à Chrony changerait-il quoi que ce soit dans ce cas?
Je vois une certaine confusion dans les réponses ici. Pour commencer, ntpclient, au moins en mode -s, N'agit pas comme un client NTP complet, il envoie et reçoit uniquement n paquet, il n'y a donc 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. Le 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 si ntpq et chrony affichent la dispersion et la dispersion racine en secondes, ce à quoi les gens ont l'habitude de regarder, 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 0 Ou -t (Selon la version de ntpclient), qui désactive NTP les vérifications d'intégrité. 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 sortie ntpq 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, soit une conspiration de tous des serveurs pour fournir l'heure erratique, ou un problème de base 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 une 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 hors du contrôle de NTP, auquel cas la mauvaise configuration est simplement qu'elle annonce le refid LOCL ; il doit être remplacé par exemple GPS ou tout ce qui donne son heure.
Juste une réponse partielle pour "Qu'est-ce que la dispersion?":
Un aller-retour NTP aller-retour 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, ce qui donne une plus grande poids à des retards plus petits. 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 date local et régler l'horloge manuellement.
Lancez ntpd et affichez ntpq -p à partir d'un hôte utilisant tous les pairs. Il sélectionnera les meilleurs.
Selon la cette documentation 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 réalisable est lorsque votre client init ntp et jusqu'à présent n'a que son horloge locale 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 ntpdate une fois avant de démarrer ntpd sur le client.