Servidor de hora 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 pueden encontrar en la forma en que un sistema maneja el contenido de estos paquetes para sincronizar su tiempo. Básicamente, son dos formas diferentes de cómo lidiar con la sincronización de tiempo.

Si bien un servidor o cliente NTP con todas las funciones alcanza un nivel muy alto de precisión y evita las marcas de tiempo abruptas tanto como sea posible mediante el uso de diferentes métodos matemáticos y estadísticos y ajustes suaves de la velocidad del reloj, SNTP solo puede ser recoModificado para aplicaciones simples, donde los requisitos de precisión y confiabilidad no son demasiado exigentes.

Al ignorar los valores de deriva y utilizar formas simplificadas de métodos de ajuste del reloj del sistema (a menudo, pasos de tiempo simples), SNTP solo logra una sincronización de tiempo de baja calidad en comparación con una implementación de NTP completa. La versión 4 de SNTP se define en RFC2030, donde dice:

“Es fuertemente recoSe recomendó que SNTP se utilice solo en los extremos de la subred de sincronización. Los clientes SNTP deben operar solo en las hojas (estrato más alto) de la subred y en configuraciones donde ningún cliente NTP o SNTP depende de otro cliente SNTP para la sincronización. Los servidores SNTP deben operar solo en la raíz (estrato 1) de la subred y luego solo en configuraciones en las que no haya otra fuente de sincronización disponible que no sea un servicio de tiempo de módem o radio confiable. El grado completo de confiabilidad que normalmente se espera de los servidores primarios solo es posible utilizando fuentes redundantes, diversas rutas de subred y algoritmos diseñados de una implementación completa de NTP ".

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

Básicamente hay dos formas de dar el salto second en cuenta en su propio sistema de tiempo de TI. La primera solución (DTS4160, DTS4210) es que el salto second se lee automáticamente a través del receptor GPS y el servidor de tiempo puede implementar esto en la marca de tiempo NTP que se emite. El trasfondo del automatismo de este dispositivo es que los operadores de satélites GPS generalmente tienen en cuenta la especificación IERS en consecuencia, que está garantizada por aviso previo y los saltos reales.econd sí mismo. Solo sobre la base de ambos componentes, los receptores GPS y los servidores de tiempo pueden procesar los saltos.econd correctamente y exactamente en el momento adecuado y también implementarlo en términos de tecnología de sistemas.

Algunos operadores de infraestructuras críticas, en cambio, prefieren el procedimiento manual porque existe un cierto riesgo residual con respecto a la recepción segura tanto de los componentes antes mencionados como de los saltos.econd normalmente tiene que ser rastreado por separado para otros sistemas de TI de todos modos. Además, la definición de saltoseconds no es un procedimiento estándar, por lo que también puede hablar de un proceso consciente, luego manual, por parte del usuario. Con esta solución alternativa de configuración manual, puede realizar la configuración correspondiente a su debido tiempo con nuestros dispositivos DTS, por ejemplo, a través de MOBA NMS o Telnet SSH, por lo que el servidor de tiempo DTS procesa los saltos de manera segura.econd y lo implementa en consecuencia.

Como regla general, los clientes NTP envían un paquete de solicitud cada 64 seconds como máximo. Con un código de dispositivo de 100 "solicitudes por second ”, ya se podían sincronizar 6,400 clientes NTP en la red. Por ejemplo, si utiliza el servidor de hora DTS 4160 con 10,000 "solicitudes por segundoecond ”, existen incluso 640,000 clientes que podrían sincronizarse con este tipo de servidor horario en la red. Dado que las versiones más actuales de NTP aumentan el intervalo de sondeo en un factor de 16 con sincronización de tiempo estable, esto da como resultado un número aún mayor de posibles dispositivos finales NTP. Por lo tanto, se debe tener en cuenta este hecho al seleccionar la especificación del dispositivo que es realmente necesaria para la necesidad específica. Para redes más grandes, también es común que se creen estructuras jerárquicas de servidores de tiempo, que constan de varios segmentos o niveles de red, cada uno con un servidor de tiempo asignado. De esta manera, los servidores horarios del nivel inferior siempre se sincronizan con el nivel superior hasta el servidor horario central. Este servidor de hora central suele tener las características de rendimiento más altas y, a menudo, es redundante.

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

• El cortafuegos o el filtro de puerto está bloqueando los paquetes NTP.
• Asegúrese de que la configuración del firewall en Windows habilite el protocolo UDP en ambos sentidos (entrante / saliente) en el puerto 123.
• Es posible que algunas versiones de w32time que vienen con Windows XP o Windows Server 2003 no puedan consultar la hora de los servidores NTP.
• Una solución para la recoEl problema gnizado es cambiar el comportamiento de 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á en su límite de capacidad, la sincronización de tiempo puede degradarse significativamente debido a la alta dispersión en los retrasos en la transmisión de paquetes. Las razones de esto pueden ser ataques de piratas informáticos, que no deben dirigirse a su propia red, o nuevos virus que causan una gran cantidad de correos electrónicos, como ya sucedió en el pasado. Un servidor NTP propio no se puede comprometer fácilmente fuera de Internet.