Servidor de tiempo NTP - DTS 4138

SNTP (Simple Network Time Protocol) y NTP (Network Time Protocol) describen exactamente el mismo formato de paquete de red, las diferencias se encuentran en la forma en que un sistema trata el contenido de estos paquetes para sincronizar su hora. Básicamente son dos formas diferentes de tratar la sincronización horaria.

Mientras que un servidor o -cliente NTP completo alcanza un nivel de precisión muy elevado y evita en la medida de lo posible las marcas de tiempo abruptas mediante el uso de diferentes métodos matemáticos y estadísticos y ajustes suaves de la velocidad del reloj, SNTP sólo puede recomendarse para aplicaciones sencillas, en las que los requisitos de precisión y fiabilidad no son demasiado exigentes.

Al no tener en cuenta los valores de deriva y utilizar formas simplificadas de métodos de ajuste del reloj del sistema (a menudo un simple paso de tiempo), SNTP sólo consigue una sincronización horaria de baja calidad en comparación con una implementación NTP completa. La versión 4 de SNTP se define en RFC2030, donde dice

«Se recomienda encarecidamente utilizar SNTP sólo en los extremos de la subred de sincronización. Los clientes SNTP deben operar sólo en las hojas (estrato más alto) de la subred y en configuraciones en las que ningún cliente NTP o SNTP dependa de otro cliente SNTP para la sincronización. Los servidores SNTP deberían operar sólo en la raíz (estrato 1) de la subred y sólo en configuraciones en las que no se disponga de otra fuente de sincronización que no sea un servicio fiable de hora por radio o módem. El grado completo de fiabilidad que normalmente se espera de los servidores primarios sólo es posible utilizando las fuentes redundantes, las diversas rutas de subred y los algoritmos elaborados de una implementación NTP completa.»

Por lo tanto, el término «servidor de tiempo NTP» o «cliente compatible NTP» puede -por definición- describir un sistema con un NTP totalmente implementado, así como cualquier otro producto que utilice y comprenda el protocolo NTP pero que alcance niveles mucho peores de fiabilidad, precisión y seguridad.

Existen básicamente dos formas de tener en cuenta el segundo bisiesto en su propio sistema horario informático. La primera solución (DTS4160, DTS4210) consiste en que el segundo bisiesto se lee automáticamente a través del receptor GPS y el servidor de tiempo puede implementarlo en el sello de tiempo NTP que se emite. El trasfondo de este automatismo del dispositivo es que los operadores de los satélites GPS suelen tener en cuenta en consecuencia la especificación IERS, que está garantizada por el preaviso y el propio segundo intercalar. Sólo sobre la base de ambos componentes pueden los receptores GPS y los servidores de tiempo procesar el segundo bisiesto correctamente y en el momento exacto e implementarlo también en términos de tecnología del sistema.

Por otra parte, algunos operadores de infraestructuras críticas prefieren el procedimiento manual porque existe un cierto riesgo residual en lo que respecta a la recepción segura de los dos componentes mencionados y, de todos modos, el segundo intercalar suele tener que seguirse por separado para otros sistemas informáticos. Además, la definición de los segundos intercalares no es un procedimiento estándar, por lo que esto también puede hablar de un proceso consciente, y luego manual, por parte del usuario. Con esta solución alternativa de ajuste manual, puede realizar a tiempo el ajuste correspondiente con nuestros dispositivos DTS, por ejemplo a través de MOBA NMS o Telnet SSH, con lo que el servidor horario DTS procesa entonces de forma segura el segundo bisiesto y lo implementa en consecuencia.

Por regla general, los clientes NTP envían un paquete de solicitud cada 64 segundos como máximo. Con un código de dispositivo de 100 «peticiones por segundo», ya podrían estar sincronizados en la red 6.400 clientes NTP. Por ejemplo, si utiliza el servidor horario DTS 4160 con 10.000 «peticiones por segundo», hay incluso 640.000 clientes que podrían estar sincronizados con este tipo de servidor horario en la red. Dado que las versiones NTP más actuales multiplican por 16 el intervalo de sondeo con una sincronización horaria estable, el resultado es un número aún mayor de posibles dispositivos finales NTP. Por lo tanto, hay que tener en cuenta este hecho a la hora de seleccionar la especificación de dispositivo realmente necesaria para la necesidad concreta. En redes de mayor tamaño, también es habitual que se creen estructuras jerárquicas de servidores de tiempo, compuestas por varios segmentos o niveles de red, cada uno con un servidor de tiempo asignado. De este modo, los servidores horarios del nivel inferior se sincronizan siempre con los del nivel superior hasta llegar al servidor horario central. Este servidor horario central suele tener las características de mayor rendimiento y suele ser redundante.

La posible solución de problemas puede proceder de la siguiente manera:

• El cortafuegos o el filtro de puertos está bloqueando los paquetes NTP.
• Asegúrese de que la configuración del cortafuegos en Windows permite el protocolo UDP en ambos sentidos (entrada/salida) en el puerto 123.
• Algunas versiones de w32time que vienen con Windows XP o Windows Server 2003 pueden ser incapaces de consultar la hora de los servidores NTP.
• Una solución para el problema reconocido es cambiar el comportamiento del w32time.

Si una conexión a Internet funciona correctamente, NTP puede determinar y contabilizar los retrasos en la transmisión de paquetes de forma bastante fiable. Sin embargo, si la conexión a internet está al límite de su capacidad, la sincronización horaria puede degradarse significativamente debido a la gran dispersión en los retrasos de transmisión de paquetes. Los motivos pueden ser ataques de piratas informáticos, que no deben dirigirse a su propia red, o nuevos virus que provoquen una gran avalancha de correos electrónicos, como ya ha ocurrido en el pasado. Un servidor NTP propio no puede ser fácilmente comprometido fuera de Internet.