¿Qué es la dispersión NTP y cómo la controlo?

Implementamos servidores Ubuntu 14.04 en redes aisladas, ejecutando ntpd 4.2.6p5, configurado para usar múltiples servidores NTP según lo provisto por los clientes (sin acceso a pool.ntp.org). Nuestros tontos dispositivos cliente de terminal ejecutan una versión anterior de BusyBox (1.00-rc2) y ntpclient 2010 de Larry Doolittle.

Esta configuración ha funcionado muy bien durante años, pero recientemente hemos llegado a un obstáculo con un nuevo cliente. Nos proporcionaron 5 direcciones de servidor NTP internas que parecen funcionar muy bien por sí mismas, en lo que ntpdate-debianrespecta al servidor Linux. Sin embargo, en el lado de BusyBox, se ntpclientqueja con "Dispersión demasiado alta". De la salida de depuración, ntpclientobtiene "1217163.1" del servidor NTP pero el valor máximo que admite es absoluto (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

Todos estos dispositivos están en la misma LAN, así que, francamente, estoy asombrado. Horrorizado incluso.

Aquí está la ntpq -pnsalida del servidor 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

Mis preguntas son:

1. ¿Qué es la dispersión y qué puede alterar su valor?
2. ¿Qué comandos podría ejecutar para obtener más detalles de los servidores NTP?
3. ¿Podría la falla recaer en el lado del servidor Ubuntu, con un incorrecto ntp.conf? No hay nada especial allí realmente.
4. ¿Cambiar a Chrony cambiaría algo en este caso?

Veo cierta confusión en las respuestas aquí. Para empezar, ntpcliental menos en -smodo, no está actuando como un cliente NTP completo, solo está enviando y recibiendo un paquete , por lo que no hay "últimos 8 paquetes recibidos". En realidad, no está estimando su propia dispersión en absoluto.

En cambio, el valor que está imprimiendo es el valor llamado "dispersión raíz" (rootdisp) en el paquete devuelto por el servidor, que es una estimación de la cantidad total de error / variación entre ese servidor y el tiempo correcto. La forma en que se calcula esto es bastante simple: cada servidor NTP obtiene su tiempo de un reloj externo (por ejemplo, un receptor de radio o GPS) o de otro servidor NTP. Si un servidor obtiene su tiempo de un reloj externo, su dispersión raíz es el error máximo estimado de ese reloj. Si obtiene su tiempo de otro servidor NTP, su dispersión raíz es la dispersión raíz de ese servidor más la dispersión agregada por el enlace de red entre ellos.

Un punto de confusión aquí es que mientras ntpq y chrony muestran la dispersión y la dispersión de la raíz en segundos, que es a lo que la gente está acostumbrada, ntpclient lo muestra en microsegundos . En cualquier caso, un valor de 1217163 sigue siendo bastante alto. Un buen servidor NTP conoce el tiempo en unos pocos milisegundos; uno malo en unas pocas decenas o cientos de milisegundos. El tuyo te dice que solo se puede confiar en su tiempo en +/- 1.2 segundos.

De todos modos, puede hacer que ntpclient se sincronice con este servidor pasando la opción -x 0o -t(dependiendo de la versión de ntpclient), que deshabilita las comprobaciones de sanidad NTP. Si solo necesita un tiempo más o menos preciso (en unos pocos segundos), puede ser suficiente. Sin embargo, ntpclient está siendo bastante razonable al negarse a sincronizarse con un servidor tan malo. Su ntpqsalida en la máquina ubuntu muestra una inquietud de cientos de milisegundos para todos sus servidores, a pesar de que tienen un retraso bajo, lo que indica una red muy poco confiable, una conspiración de todos los servidores para proporcionar un tiempo errático o un error básico. problema de cronometraje en el propio servidor.

También me preocupa que el servidor 10.31.10.22 esté anunciando un rechazo de LOCL(reloj local indisciplinado) pero tiene un estrato de 1. Por lo general, el reloj local está falsificado a un estrato de 10 para que solo se use como fuente de sincronización de último recurso para evitar que una manada se separe. O 10.31.10.22 está mal configurado y proporciona un mal momento para el resto de la red, o está siendo disciplinado a buen tiempo por algún programa fuera del control de NTP, en cuyo caso la mala configuración es simplemente que está anunciando la LOCLdevolución; debe ser anulado, por ejemplo, GPSo lo que sea que esté proporcionando su tiempo

Solo una respuesta parcial para "¿Qué es la dispersión?":

Un típico viaje redondo de NTP:

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

Esto produce dos valores, compensación (la diferencia horaria entre el cliente y el servidor) y el retraso (esencial el tiempo de viaje de la red) con las siguientes fórmulas:

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

El cliente selecciona el desplazamiento actual de los últimos 8 paquetes recibidos, eligiendo el que tenga el menor retraso.

Los mismos 8 paquetes se usan para calcular la dispersión haciendo un promedio ponderado de la diferencia de estos 8 desplazamientos con el seleccionado en el último paso, donde el retraso se usa como factor de ponderación, dando mayor peso a retrasos más pequeños. Es una medida para la "dispersión" de los valores y se utiliza para calcular la calidad de un servidor de hora, especialmente si tiene múltiples para elegir.

Su dispersión y sesgo son enormes, hay un desplazamiento muy grande del reloj local a ese par. Debe comparar los desplazamientos con el local datey configurar el reloj manualmente.

Obtenga ntpd en ejecución y muestre ntpq -pdesde un host utilizando todos los pares. Seleccionará los mejores.

De acuerdo con esta documentación de Cisco , "la dispersión , informada en segundos, es la diferencia máxima de tiempo de reloj que se observó entre el reloj local y el reloj del servidor". Con los servidores ntp que no están totalmente rotos, nunca debería producirse una alta dispersión. El único escenario factible es cuando su cliente inicia ntp y hasta ahora solo tiene disponible su reloj local. E incluso entonces, una dispersión tan alta como se informa corresponde a los relojes que están apagados por más de dos semanas .

Debería ser suficiente para garantizar que el reloj local no esté demasiado alejado al principio (incluso un par de horas aún sería aceptable), ya sea ajustando el reloj (¡y hasta la fecha!) En el BIOS o emitiéndolo ntpdateuna vez antes de comenzar ntpden el cliente