¿Por qué se sincroniza NTP a LOCAL en lugar de servidor remoto?

Entonces, estoy tratando de depurar mi configuración actual de NTP, y descubrí que el desplazamiento de mi único servidor configurado es de más de 3 segundos y no se ajusta. El asterisco en LOCAL (0) en la salida ntpq parece indicar que el sistema se está sincronizando felizmente consigo mismo en lugar del servidor 10.130.33.201 (que es otro cuadro de Linux en nuestro sistema al que queremos que todo se sincronice).

ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 10.130.33.201   LOCAL(0)         9 u   49   64  377    0.242  -3742.2   1.049
*LOCAL(0)        .LOCL.          10 l    2   64  377    0.000    0.000   0.001

Y este es mi archivo ntp.conf. Escrito por otra persona, así que no estoy 100% seguro de que todo sea correcto.

server 10.130.33.201 burst iburst minpoll 4 maxpoll 11
driftfile /mnt/active/etc/ntp.drift

restrict -4 default  nomodify nopeer notrap
restrict -6 default  ignore

# Undisciplined Local Clock. This is a fake driver intended for backup
# and when no outside source of synchronized time is available.
server  127.127.1.0     # local clock
fudge   127.127.1.0 stratum 10

He leído sobre la explosión y el iburst y minpoll / maxpoll, así que me doy cuenta de que podrían no ser necesarios, pero no creo que tenga nada que ver con mi problema actual.

Además, debido a cómo se implementa, ese archivo de configuración requerirá mucho trabajo para cambiar, así que espero que no haya nada que realmente deba cambiarse. Espero que este sea un caso en el que no entiendo cómo funciona NTP.

EDITAR -

Entonces, parece que esto es un duplicado de esta pregunta , pero no creo que el póster haya recibido una respuesta suficiente, por lo que aún me gustaría saber por qué se prefiere la hora local en lugar del servidor. Además, según una de las respuestas a continuación, intenté usar la preferpalabra clave en la línea del servidor de la configuración y reiniciar, pero eso no parece haber tenido efecto.

Si elimino todas las líneas "locales" en la configuración como sugiere la respuesta a la otra pregunta, ¿qué sucederá si no se puede acceder al servidor? ¿NTP muere o simplemente sigue intentándolo?

EDICIÓN IMPORTANTE -

Ok, normalmente, 10.130.33.201 (El "servidor") no tiene acceso a Internet, y no tiene una fuente de tiempo GPS para usar. La parte importante es que todos los dispositivos en el sistema tienen el mismo tiempo que el servidor, independientemente de cuán correcta sea esa hora en realidad.

Entonces, solo para ver qué sucedería, agregué uno de los servidores del grupo NTP al archivo de configuración del servidor para que obtuviera tiempo desde allí en lugar de hacerlo desde el local. Ahora obtiene correctamente el tiempo del servidor de hora NTP.

Después de hacer eso, los clientes ahora se sincronizan con el servidor en lugar de preferir LOCAL (0)

 ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*10.130.33.201   38.229.71.1      3 u   58   64  377    0.216  715621.   1.001
 LOCAL(0)        .LOCL.          10 l   18   64  377    0.000    0.000   0.001

NUEVA PREGUNTA: cuando mi servidor usa local (ejemplo original que se dio), parece que los clientes dicen: "Oh, 10.130.33.201 está usando LOCAL (0). Hmm, también tengo un servidor LOCAL (0) - - Solo lo usaré directamente en lugar de obtener la misma información a través de 10.130.33.201 ".

¿Es ese el caso? ¿Están tratando de ir "directamente a la fuente" que es incorrectamente LOCAL (0)? Necesito que mi servidor obtenga tiempo de LOCAL (0), y necesito que los clientes obtengan tiempo del servidor. En este momento, eliminar el servidor "local" de los archivos de configuración del cliente es la única opción, pero me gustaría entender por qué sucede esto y, si es posible, evitar cambiar sus configuraciones (el cambio de configuración será mucho trabajo debido a nuestro ambiente...).

Además, esto parece otro duplicado sin una buena respuesta.

Con solo un servidor NTP configurado, el algoritmo no está completamente seguro de en quién confiar. Aunque el estrato es más bajo con el host remoto, apuesto a que el algoritmo cree que la hora local es más confiable.

Intente usar la preferpalabra clave con su serverdeclaración para establecer eso como una fuente de tiempo preferencial.

EDITAR -

Entonces, parece que esto es un duplicado de esta pregunta, pero no creo que el póster haya recibido una respuesta suficiente, por lo que aún me gustaría saber por qué se prefiere la hora local en lugar del servidor.

Para obtener una respuesta realmente suficiente, va a cavar en las entrañas de un algoritmo muy complejo. La documentación ni siquiera es demasiado específica, pero estoy seguro de que hay un documento técnico o una especificación.

Si elimino todas las líneas "locales" en la configuración como sugiere la respuesta a la otra pregunta, ¿qué sucederá si no se puede acceder al servidor? ¿NTP muere o simplemente sigue intentándolo?

El demonio NTP no muere ni se detiene, pero deja el tiempo de sincronización después de que no llega al servidor remoto. Esta es la razón por la cual las mejores prácticas sugerirán un mínimo de tres servidores remotos y no usar el LCL a menos que esté desconectado de la red. Se sugieren tres servidores porque cuando solo hay dos y no están de acuerdo, ¿cuál elegirá? El tercer servidor debería ayudar al algoritmo a eliminar el servidor falso.

Por último, me di cuenta de que no define a driftfile. Esto podría ayudar?

Me parece que el intervalo de compensación (diferencia entre la hora de su sistema y la del tiempo de host de NTP) es demasiado diferente para que NTP lo configure correctamente.

Mi sugerencia,

 1. Stop the NTP service
 2. As root ntpdate -bs 10.130.33.201 to reset your time to something close
 3. Start the NTP service

No deberías tener problemas después de eso.

El estrato de 10.130.33.201 como servidor LOCAL es 9, lo que hace que el estrato local calculado a partir de esto (9 + 1 = 10) compita con el servidor LOCAL local en el estrato 10. Dado que el estrato LOCAL local no tiene retrasos ni fluctuaciones en la red, puede parecer un poco mejor para ntpd que el remoto.

Si desea que esta configuración funcione, configure el servidor LOCAL 'maestro' en un estrato inferior a 9. No demasiado bajo si desea que se prefiera un tiempo rastreable a un servidor del estrato 1.

Sé que esto es viejo, pero creo que tienes razón. Nadie muestra ninguna forma de depurar problemas de ntpd. Resulta que es factible.

Creo que estaba en el camino correcto cuando sospechaba que el uso de LOCAL (0) localmente y en el servidor ascendente puede ser un problema.

Ciertamente fue en una isla de 4 servidores con los que tuve un problema similar. Todos estos fueron configurados para ser iguales entre sí, por lo que posiblemente sea un problema diferente al suyo.

Primero, sin embargo, hay una mejor manera de manejar las islas de tiempo llamada modo huérfano que es compatible con las versiones ntpd de los últimos años:

Modo huérfano en doc.ntp.org

Inicialmente, los 4 servidores tenían el mismo estrato de 10 y preferían su reloj local. Lo arreglé y todavía preferían su reloj local (aunque el estrato parece ser importante).

Utilicé el comando ntpq pe (peer), as, rv para tener una idea de lo que estaba sucediendo. Debe usar rv (readvar) en el número de asociación para que el servidor descargue la información. pe y como parecen estar ordenados por el mismo índice para que pueda obtener el número como de esa manera. como tiene un campo llamado condición que puede mostrar el valor rechazado si no le gusta el servidor.

En la salida rv hay un campo llamado flash. Si todo está bien, será cero. Si no, es una máscara de bits (que se muestra en hexadecimal) de los problemas. Se pueden buscar aquí:

decodificaciones internas ntpd

El problema que tuve fue 0800 peer_loop. Resultó que la devolución del reloj es importante. Al ver LOCAL (0) tanto en el reloj local como en el servidor remoto, ntpd pensó que había un bucle. David Mills confirma que en publicaciones en comp.protocols.time 'Cómo evitar el bucle en NTP' (¡He alcanzado mi límite de 2 enlaces, lo siento!)

El uso del argumento refid para fudge para establecer un refid único no funcionó, todavía se muestra como LOCAL (0) en el destinatario.

Lo que parecía funcionar era usar números de instancia únicos para el controlador local. 127.127.1. [0-3]. Use la misma ID tanto en el servidor como en la línea de dulce de azúcar. Cuando hice esto, los servidores generalmente se sincronizaron con el servidor de estrato más bajo que generalmente usaba su reloj local. Sin embargo, ocasionalmente intentó usar uno de los otros servidores que lo usaban como fuente. Sin embargo, los tiempos se sincronizaron y parecen mantenerse así.

Probablemente sea demasiado tarde para ayudar, pero lo ofrezco para mostrar que NTP es susceptible de lógica y solución de problemas. Me tomó horas llegar a la respuesta por prueba y error y luego encontré los documentos más tarde.

Use iburst para forzar al servidor a enviar la solicitud NTP al NTS deseado, incluso si una solicitud falla