Servidor NTP único en red aislada

Tengo dos máquinas Linux (A y B) en una red aislada. Deben estar sincronizados en el tiempo. La máquina A se alimenta de manera intermitente y debe servir el tiempo, ya que está conectada a una fuente de tiempo autorizada (GPS). La máquina B solo está alimentada si la máquina A está alimentada, pero es un dispositivo Linux incorporado y su estado de alimentación cambiará con frecuencia. Ninguna máquina tiene acceso a otros sistemas. Es una red cerrada.

Entiendo que esto es bastante difícil para NTP, ya que NTP generalmente espera tener contacto con varios servidores. Tengo problemas para que esto funcione correctamente en la máquina B. La máquina A se sincroniza bien con el GPS, y la máquina B puede llegar a la máquina A e incluso hacer consultas de tiempo, pero la máquina A no es confiable (¿tal vez por sí misma?). Después de una hora sólida de máquina A, esto cambió repentinamente y la máquina B funcionó. Sin embargo, cuando la máquina A dejó de funcionar (y, por lo tanto, la máquina B), la máquina B no puede encontrar una buena sincronización de tiempo.

Aquí hay información de ntpdate. Tenga en cuenta que incluso cuando el estrato de la máquina A es 1, la operación falla con la misma salida al final.

10.10.10.1: servidor caído: estratos demasiado altos
servidor 10.10.10.1, puerto 123
estrato 16, precisión -19, salto 11, confianza 000
reposición [10.10.10.1], demora 0.02614, dispersión 0.00000
transmitido 4, en el filtro 4
tiempo de referencia: 00000000.00000000 jue, 7 de febrero de 2036 6: 28: 16.000
marca de tiempo original: d3a9bdc4.27ebb350 jue, 12 de julio de 2012 21: 19: 00.155
marca de tiempo de transmisión: bc17c803.b42dfffe sáb, 1 de enero de 2000 0: 25: 39.703
Retraso del filtro: 0.02625 0.02614 0.02618 0.02625 
         0.00000 0.00000 0.00000 0.00000 
desplazamiento del filtro: 39544160 39544160 39544160 39544160
         0.000000 0.000000 0.000000 0.000000
retraso 0.02614, dispersión 0.00000
offset 395441600.451568

 1 de enero 00:25:39 ntpdate [677]: no se encontró ningún servidor adecuado para la sincronización

Supongo que la máquina A simplemente no confía en sí misma para el tiempo de servicio. Después de 51 minutos (puede que haya sucedido antes, no lo sé) de tiempo de actividad y sincronizado su reloj con el GPS, la máquina A comenzó a servir la hora correctamente y la máquina B lo activó. Necesito que esto suceda antes. Me gusta, en segundos si es posible.

Con las siguientes configuraciones (y mucha espera), finalmente tiene éxito.

Máquina A ntp.conf:

el servidor 127.127.28.0 prefiere verdadero minpoll 4 maxpoll 4
dulce de azúcar 127.127.28.0 estrato 1 vez1 0.420 GPS rechazado 

Machine B ntp.conf:

servidor 10.10.10.1 prefiere verdadero minpoll 4 maxpoll 4

ntpq -c pares en la máquina B sin una buena corrección de tiempo:

     t de reposición remota cuando la demora del alcance de la encuesta compensa la fluctuación de fase
================================================== ============================
 10.10.10.1. PASO. 16 u 9 16 0 0.000 0.000 0.000

ntp1 -c pares en la máquina B con buena corrección de tiempo:

     t de reposición remota cuando la demora del alcance de la encuesta compensa la fluctuación de fase
================================================== ============================
* 10.10.10.1 SHM (0) 2 u 7 16 17 0.669 2.597 1.808

Entonces, ahora la pregunta es: ¿cómo hago que Machine A confíe en sí mismo rápidamente?

Algunos resultados de depuración de la máquina A antes y después de la máquina B deciden que la máquina A es lo suficientemente buena para usar.

antes de..

~ # ntpq -c rv
associd = 0 status = c418 leap_alarm, sync_uhf_radio, 1 evento, no_sys_peer,
version = "ntpd [email protected] Vie 24 de febrero 15:01:45 UTC 2012 (1)",
procesador = "armv7l", sistema = "Linux / 2.6.35.14", salto = 11, estrato = 2,
precisión = -19, rootdelay = 0.000, rootdisp = 44.537, refid = SHM (0),
reftime = d3ab0053.43b44780 viernes, 13 de julio de 2012 20: 15: 15.264,
reloj = d3ab0062.e7e03154 viernes, 13 de julio de 2012 20: 15: 30.905, igual = 34819, tc = 4,
mintc = 3, offset = 0.000, frecuencia = 0.000, sys_jitter = 3.853,
clk_jitter = 36.492, clk_wander = 0.000

después...

~ # ntpq -c rv
associd = 0 status = 0415 leap_none, sync_uhf_radio, 1 evento, clock_sync,
version = "ntpd [email protected] Vie 24 de febrero 15:01:45 UTC 2012 (1)",
procesador = "armv7l", sistema = "Linux / 2.6.35.14", salto = 00, estrato = 2,
precisión = -19, rootdelay = 0.000, rootdisp = 41.278, refid = SHM (0),
reftime = d3ab0063.43b37856 Vie, 13 de julio de 2012 20: 15: 31.264,
reloj = d3ab006d.9ee53ec2 viernes, 13 de julio de 2012 20: 15: 41.620, igual = 34819, tc = 4,
mintc = 3, offset = 0.000, frecuencia = 43.896, sys_jitter = 0.762,
clk_jitter = 36.953, clk_wander = 0.000

NTP debería funcionar bien. Mire algunas de las opciones para una sincronización rápida en el inicio. Mire las opciones bursty iburstpara el sistema B. Mire la trueopción para la fuente del reloj GPS.

Considere usar el reloj de hardware como fuente de tiempo de respaldo en ambos sistemas. Establezca un sistema de estrato más alto B. Algo como lo siguiente debería funcionar:

server  127.127.1.0
fudge   127.127.1.0 stratum 8

Mire la salida de ntpq -c peerspara ver cuándo obtiene una fuente de reloj confiable. Normalmente ntpquiere una cantidad de respuestas de una fuente de tiempo confiable antes de confiar en ella. Esto se indica mediante el primer carácter en cada línea.

Si bien a NTP le gustan más fuentes, cualquier número impar de fuentes de tiempo dentro de un nivel de estrato debería funcionar bien. Como solo tiene dos servidores y un reloj GPS, la prioridad (estrato) de las fuentes debe aumentar desde el GPS, el reloj en el servidor A, el reloj en el servidor B. El aumento del estrato entre cada uno de tres o cuatro niveles garantizará que se respeten las prioridades.

EDITAR: si tiene el servidor NTP busybox en el servidor A, puede valer la pena instalar el paquete completo del servidor ntp. Comprender lo que está sucediendo con el servidor A debería ser de gran ayuda para resolver su problema. Necesitará al menos una fuente de tiempo confiable allí antes de que el servidor B confíe en él. Si ntpq -c peersno funciona, puedes intentarlo ntpdc peers. Ambos comandos le permiten consultar otros hosts. Un peerstatsregistro también podría ser útil.

En el servidor B, use ntpclient como se documenta en el busybox ntp howto para registrar lo que está sucediendo en él

Los relojes deben estar razonablemente cerca de la hora correcta si los servidores no han estado inactivos por mucho tiempo. Si necesita sincronizar los dos sistemas, eso debería ser suficiente. El GPS sincronizará el tiempo con el mundo real eventualmente.

'ntpd -q' se sincroniza rápidamente, pero sale (comportamiento ntpdate). Debe seguir un ntpdcomando sin la opción de salir para tener una sincronización continua.

EDIT2: Revisé mi servidor y encontré que uno de los servidores estaba apagado por un segundo. Mientras arreglaba esto, jugué con la configuración. iburstobtiene un servidor de confianza muy rápidamente. trueaseguró que el controlador del reloj fuera confiable si no hubiera muchas otras fuentes confiables. El reloj tardó un poco más de un minuto antes de que se confiara localmente y se pudiera confiar de forma remota.

Al realizar la prueba, debería poder reiniciar el ntpdproceso una vez que esté sincronizado y probar qué tan rápido funciona la configuración. En el caso anterior, el Servidor B puede necesitar reiniciarse para probar qué tan rápido se sincroniza. Al monitorear los ntpdcambios, uso una línea como:

while ntpq -c peers localhost; do sleep 10; done

El nombre de host y el tiempo de suspensión se ajustan según sea necesario. En algunos casos, encadena dos o más ntpqlíneas de comando en el bucle. Al hacerlo, utilizo un comando de eco y / o fecha para proporcionar una indicación de dónde cambian los conjuntos de datos.