Por lo general, cuando una máquina pierde la conexión por completo, ntpd pierde un par de encuestas y marca todas las fuentes como de cordura fallida. Lo cual parece bastante lógico. Pero me encontré con una situación en la que un servidor permanece marcado como fuente de tiempo actual mientras su alcance era 0.
El servidor se implementa en la misma subred que la máquina de destino y proporciona muy bajos retrasos, desplazamientos y fluctuaciones. La situación se modeló cerrando físicamente la conexión: simplemente desconectando un cable de una máquina cliente. Intenté recrear esto, pero desde entonces la misma máquina siempre pierde el estado de sincronización después de 5 o 6 encuestas fallidas.
La verdadera pregunta es: ¿qué determina exactamente el estado de sincronización cuando se pierde la conexión?
Respuesta1
Hay una explicación definitiva sobre el registro de alcance en RFC-1305:
El registro de accesibilidad se desplaza una posición hacia la izquierda y el cero reemplaza el bit vacante. Si todos los bits de este registro son cero, se llama al procedimiento de borrado para purgar el filtro de reloj y volver a seleccionar la fuente de sincronización, si es necesario. Si la asociación no fue configurada mediante el procedimiento de inicialización, la asociación se desmoviliza.
Sin embargo, RFC-1305 queda obsoleto por RFC-5905, que no es tan distintivo:
A continuación, se utiliza el registro de desplazamiento p.reach de 8 bits en el proceso de sondeo descrito en la Sección 13 para determinar si se puede acceder al servidor y si los datos están actualizados. El registro se desplaza un bit hacia la izquierda cuando se envía un paquete y el bit más a la derecha se establece en cero. A medida que llegan paquetes válidos, el bit más a la derecha se establece en uno. Si el registro contiene bits distintos de cero, el servidor se considera accesible; de lo contrario, es inalcanzable.
No se menciona ningún procedimiento claro en la Sección 13. Pero aun así parece que un par irrealizable debería perder su estado de sincronización en algún momento.
Logré recrear el estado sincronizado con una situación de alcance 0 para garantizar que sea poco común y no permanente. Fue necesario deshabilitar la "ráfaga" en la configuración de los servidores e interrumpir la conexión inmediatamente después de la sincronización.
remote refid st t when poll reach delay offset jitter
==============================================================================
91.198.10.4 194.190.168.1 2 u 20 64 177 51.137 -2.192 11.049
192.168.1.1 193.67.79.202 2 u 65 64 77 0.459 -1.818 0.922
remote refid st t when poll reach delay offset jitter
==============================================================================
*91.198.10.4 194.190.168.1 2 u 21 64 177 51.137 -2.192 11.049
+192.168.1.1 193.67.79.202 2 u - 64 177 0.449 -3.192 1.828
El alcance fue 177, que es 01111111 en binario. Así que fueron necesarias 7 encuestas para establecer la sincronización.
La sincronización se perdió entonces en esta posición:
remote refid st t when poll reach delay offset jitter
==============================================================================
+91.198.10.4 194.190.168.1 2 u 574 64 0 63.846 -9.652 0.756
*192.168.1.1 193.67.79.202 2 u 553 64 0 0.449 -3.192 0.505
remote refid st t when poll reach delay offset jitter
==============================================================================
91.198.10.4 194.190.168.1 2 u 575 64 0 69.871 -10.409 0.002
192.168.1.1 193.67.79.202 2 u 554 64 0 0.449 -3.192 0.505
Cuando los números son un poco extraños como 64*9 = 576, no 575, pero supongo que la representación puede tener una imprecisión de 1 segundo. Considerando esto, fueron necesarias 9 encuestas fallidas para romper el estado de sincronización.
Entonces, considerando tanto la teoría como la práctica, parece que el estado en el que una fuente con alcance 0 podría considerarse fuente de tiempo actual es posible, pero también raro y temporal.