El conjunto de documentos para este producto aspira al uso de un lenguaje no discriminatorio. A los fines de esta documentación, "no discriminatorio" se refiere al lenguaje que no implica discriminación por motivos de edad, discapacidad, género, identidad de raza, identidad étnica, orientación sexual, nivel socioeconómico e interseccionalidad. Puede haber excepciones en la documentación debido al lenguaje que se encuentra ya en las interfaces de usuario del software del producto, el lenguaje utilizado en función de la documentación de la RFP o el lenguaje utilizado por un producto de terceros al que se hace referencia. Obtenga más información sobre cómo Cisco utiliza el lenguaje inclusivo.
Cisco ha traducido este documento combinando la traducción automática y los recursos humanos a fin de ofrecer a nuestros usuarios en todo el mundo contenido en su propio idioma. Tenga en cuenta que incluso la mejor traducción automática podría no ser tan precisa como la proporcionada por un traductor profesional. Cisco Systems, Inc. no asume ninguna responsabilidad por la precisión de estas traducciones y recomienda remitirse siempre al documento original escrito en inglés (insertar vínculo URL).
Este documento describe las mejores prácticas para diseñar Network Time Protocol .
Cisco le recomienda que tenga conocimiento acerca de este tema:
Este documento no tiene restricciones específicas en cuanto a versiones de software y de hardware.
La información que contiene este documento se creó a partir de los dispositivos en un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si tiene una red en vivo, asegúrese de entender el posible impacto de cualquier comando.
Las redes basadas en el protocolo de Internet (IP) han avanzado rápidamente desde el modelo de entrega best effort tradicional a un modelo en el que el rendimiento y la fiabilidad deben cuantificarse y, en muchos casos, garantizarse mediante acuerdos de nivel de servicio (SLA). La necesidad de una mayor perspectiva de las características de la red ha dado lugar a importantes esfuerzos de investigación que se centran en importantes métricas y capacidades de medición para caracterizar el comportamiento de la red. La base de muchas metodologías de métrica es la medición del tiempo.
La sincronización del tiempo de la red, en la medida necesaria para el análisis del rendimiento moderno, es un ejercicio esencial. Basándose en los modelos empresariales y los servicios que se proporcionan, la caracterización del rendimiento de la red se considera un importante diferenciador de servicios competitivo. En estos casos, se incurre en grandes gastos al implementar sistemas de gestión de redes y recursos de ingeniería directos para analizar los datos de rendimiento recopilados. Sin embargo, si no se presta la debida atención al principio de sincronización del tiempo, que a menudo se pasa por alto, esos esfuerzos son ineficaces.
Este documento describe una definición de proceso hipotética para la administración de funciones de administración de red para el Protocolo de tiempo de la red (NTP). Puede utilizar este artículo como un procedimiento hipotético y un ejemplo informativo. Una organización puede personalizarlo para que cumpla sus objetivos internos.
La información proporcionada en este documento se presenta en varias secciones principales:
Precisión: la proximidad del valor absoluto del reloj al desplazamiento de cero.
Preciso: cuando el desvío de un reloj es cero en un momento concreto.
Desviación (Drift): medida en la variación de la desviación o la segunda derivación del desvío del reloj con respecto al tiempo.
Resolución conjunta: cuando se comparan relojes, es la suma de las resoluciones de C1 y C2. A continuación, la resolución conjunta indica un límite inferior conservador en la precisión de cualquier intervalo de tiempo calculado mediante marcas de tiempo generadas por un reloj restado de las generadas por el otro.
Nodo: hace referencia a una instanciación del protocolo NTP en un procesador local. Un nodo también se puede denominar dispositivo.
Desplazamiento: diferencia entre la hora indicada por un reloj y la hora real definida por la hora universal coordinada (UTC). Si el reloj informa de una hora Tc y la hora verdadera es Tt, el desplazamiento del reloj es Tc - Tt.
Peer: se refiere a una instanciación del protocolo NTP en un procesador remoto conectado por una trayectoria de red desde el nodo local.
Desvío relativo: la noción de hora verdadera se sustituye por la hora indicada por el reloj C1, cuando se comparan dos relojes, C1 y C2. Por ejemplo, el desplazamiento del reloj de C2 con respecto a C1 en un momento determinado es Tc2 - Tc1, la diferencia instantánea de tiempo informada por C2 y C1.
Resolución: la unidad más pequeña en la que se actualiza la hora de un reloj. La resolución se define en términos de segundos. Sin embargo, la resolución es relativa a la hora indicada por el reloj y no a la hora verdadera. Por ejemplo, una resolución de 10 milisegundos significa que el reloj actualiza su noción de tiempo en incrementos de 0,01 segundos y no significa que esta sea la verdadera cantidad de tiempo entre actualizaciones.
Nota: Los relojes pueden tener resoluciones muy finas y seguir siendo inexactos.
Sesgar: diferencia de frecuencia de reloj o primera derivada de su desvío con respecto al tiempo.
Sincronizar: cuando dos relojes son precisos entre sí (el desvío relativo es cero), se sincronizan. Los relojes pueden sincronizarse y seguir siendo inexactos en términos de lo bien que dicen la hora real.
El corazón del servicio de hora es el reloj del sistema. El reloj del sistema se ejecuta desde el momento en que se inicia el sistema y realiza un seguimiento de la fecha y hora actuales. El reloj del sistema se puede configurar desde varias fuentes y, a su vez, se puede utilizar para distribuir la hora actual a través de varios mecanismos a otros sistemas. Algunos routers contienen un sistema de calendario alimentado por batería que realiza un seguimiento de la fecha y la hora en los reinicios del sistema y las interrupciones del suministro eléctrico. Este sistema de calendario siempre se utiliza para inicializar el reloj del sistema cuando se reinicia el sistema. También puede ser considerada como una fuente autorizada de tiempo y redistribuida a través de NTP si no hay otra fuente disponible. Además, si NTP está habilitado, el calendario se actualiza periódicamente desde NTP, y esto compensa la deriva inherente en el tiempo del calendario. Cuando se inicializa un router con un calendario del sistema, el reloj del sistema se establece en función de la hora de su calendario interno alimentado por batería. En los modelos sin calendario, el reloj del sistema se establece en una constante de tiempo predeterminada. El reloj del sistema se puede configurar a partir de las fuentes enumeradas a continuación.
NTP
Protocolo simple de tiempo de red (SNTP)
Servicio de hora del servicio de red integrada virtual (VINES)
Configuración manual
Algunos dispositivos Cisco de gama baja sólo admiten SNTP. SNTP es una versión simplificada de NTP solo para clientes. SNTP sólo puede recibir el tiempo de los servidores NTP y no se puede utilizar para proporcionar servicios de tiempo a otros sistemas. SNTP normalmente proporciona tiempo dentro de los 100 milisegundos de la hora exacta. Además, SNTP no autentica el tráfico, aunque puede configurar listas de acceso ampliadas para proporcionar cierta protección. Un cliente SNTP es más vulnerable a los servidores no conformes que un cliente NTP y sólo se debe utilizar en situaciones en las que no se requiera una autenticación fuerte.
El reloj del sistema proporciona tiempo para los servicios que se enumeran a continuación.
NTP
Servicio Horario de VINES
Comandos show del usuario
Registrar y depurar mensajes
El reloj del sistema realiza un seguimiento de la hora de forma interna en función de la hora UTC, también conocida como hora del meridiano de Greenwich (GMT). Puede configurar la información sobre la zona horaria local y el horario de verano de modo que la hora se muestre correctamente en relación con la zona horaria local. El reloj del sistema controla si la hora es autoritativa o no. Si no es autoritativo, el tiempo sólo puede estar disponible para mostrar y no se puede redistribuir.
NTP está diseñado para sincronizar la hora en una red de máquinas. NTP se ejecuta sobre el protocolo de datagramas de usuario (UDP), con el puerto 123 como origen y destino, que a su vez se ejecuta sobre IP. NTP Versión 3 RFC 1305 se utiliza para sincronizar la hora entre un conjunto de servidores y clientes de tiempo distribuido. Un conjunto de nodos de una red se identifica y configura con NTP y los nodos forman una subred de sincronización, a veces denominada red superpuesta. Aunque pueden existir varios servidores principales, no es necesario un protocolo de elección.
Una red NTP generalmente obtiene su hora de una fuente de tiempo autorizada, como un reloj de radio o un reloj atómico conectado a un servidor de tiempo. NTP luego distribuye este tiempo a través de la red. Un cliente NTP realiza una transacción con su servidor a lo largo de su intervalo de sondeo (de 64 a 1024 segundos) que cambia dinámicamente a lo largo del tiempo en función de las condiciones de red entre el servidor NTP y el cliente. La otra situación ocurre cuando el router se comunica con un servidor NTP incorrecto (por ejemplo, un servidor NTP con dispersión grande); el router también aumenta el intervalo de sondeo. No se necesita más de una transacción NTP por minuto para sincronizar dos máquinas.
NTP utiliza el concepto de un estrato para describir cuántos saltos NTP fuera de una máquina es de una fuente de tiempo autoritativa. Por ejemplo, un servidor de tiempo de estrato 1 tiene una radio o un reloj atómico conectados directamente a él. Luego envía su tiempo a un servidor de tiempo de estrato 2 a través de NTP, y así sucesivamente. Una máquina que ejecuta NTP elige automáticamente la máquina con el número de estrato más bajo que está configurada para comunicarse con NTP como su fuente de tiempo. Esta estrategia construye efectivamente un árbol auto-organizado de altavoces NTP. NTP funciona bien en las longitudes de trayectoria no determinísticas de las redes conmutadas por paquetes porque hace estimaciones robustas de las siguientes tres variables clave en la relación entre un cliente y un servidor de tiempo.
Retraso de red
Dispersión de intercambios de paquetes de tiempo: una medida del error de reloj máximo entre los dos hosts.
Desplazamiento del reloj: corrección aplicada a un reloj del cliente para sincronizarlo.
La sincronización del reloj en el nivel de 10 milisegundos en redes de área extensa (WAN) de larga distancia (2000 km) y en el nivel de 1 milisegundo en redes de área local (LAN) se consigue de forma rutinaria.
Hay dos maneras en las que NTP no se sincroniza con una máquina cuya hora no es precisa. En primer lugar, NTP nunca se sincroniza con una máquina que no está sincronizada por sí misma. En segundo lugar, NTP compara el tiempo informado por varias máquinas, y no se sincroniza con una máquina cuya hora es significativamente diferente de las otras, incluso si su estrato es menor.
Las comunicaciones entre las máquinas que ejecutan NTP (asociaciones) suelen estar configuradas estáticamente. A cada máquina se le da la dirección IP de todas las máquinas con las que debe formar asociaciones. El mantenimiento preciso de la hora es posible gracias a los mensajes NTP intercambiados entre cada par de máquinas con una asociación. Sin embargo, en un entorno LAN, el NTP se puede configurar para utilizar mensajes de broadcast IP en su lugar. Esta alternativa reduce la complejidad de la configuración, ya que cada equipo se puede configurar para enviar o recibir mensajes de difusión. Sin embargo, la precisión del mantenimiento de la hora se reduce ligeramente porque el flujo de información es solo unidireccional.
El tiempo que se mantiene en una máquina es un recurso crítico y se recomienda encarecidamente que utilice las funciones de seguridad de NTP para evitar la configuración accidental o maliciosa de la hora incorrecta. Las dos funciones de seguridad disponibles son un esquema de restricción basado en listas de acceso y un mecanismo de autenticación cifrado.
La implementación de NTP por parte de Cisco admite el servicio de estrato 1 en ciertas versiones del software Cisco IOS®. Si una versión soporta el comando ntp refclock, es posible conectar una radio o un reloj atómico. Ciertas versiones de Cisco IOS admiten el kit de sincronización NTP Trimble Palisade (solo routers de la serie Cisco 7200) o el dispositivo GPS (Sistema de posicionamiento global) de soluciones de telecomunicaciones. Si la red utiliza los servidores de hora públicos en Internet y la red está aislada de Internet, la implementación de NTP de Cisco permite configurar una máquina de modo que actúe como si estuviera sincronizada a través de NTP, cuando en realidad ha determinado la hora por otros medios. Otras máquinas se sincronizan con esa máquina a través de NTP.
Cada cliente de la subred de sincronización, que también puede ser un servidor para clientes de estrato superior, elige uno de los servidores disponibles con el que sincronizar. Normalmente, se trata de uno de los servidores de menor estrato al que tiene acceso. Sin embargo, esta no siempre es una configuración óptima, porque NTP también opera bajo la premisa de que cada tiempo del servidor debe ser visto con una cierta cantidad de desconfianza. NTP prefiere tener acceso a varias fuentes de tiempo de estrato inferior (al menos tres) ya que puede aplicar un algoritmo de acuerdo para detectar locura por parte de cualquiera de estas. Normalmente, cuando todos los servidores están de acuerdo, NTP elige el mejor servidor en términos de estrato más bajo, más cercano (en términos de retraso de la red) y precisión reclamada. Esto implica que, si bien se debe intentar proporcionar a cada cliente tres o más fuentes de tiempo de estrato inferior, varias de estas solo pueden proporcionar servicio de respaldo y pueden ser de menor calidad en términos de demora y estrato de la red. Por ejemplo, un peer del mismo estrato que recibe tiempo de orígenes de estrato inferior a los que el servidor local no accede directamente, también puede proporcionar un buen servicio de respaldo.
NTP generalmente prefiere servidores de estrato inferior a servidores de estrato superior a menos que el tiempo del servidor de estrato inferior sea significativamente diferente. El algoritmo es capaz de detectar cuando una fuente de tiempo es probable que sea extremadamente inexacta, o demente, y para evitar la sincronización en estos casos, incluso si el reloj inexacto está en un nivel de estrato más bajo. Además, nunca puede sincronizar un dispositivo con otro servidor que no esté sincronizado por sí mismo.
Para declarar si el servidor es confiable, necesita pasar muchas comprobaciones de integridad, como:
Las implementaciones deben incluir tiempos de espera de integridad que eviten las transmisiones de trampas si el programa de monitoreo no renueva esta información después de un intervalo prolongado.
Se incluyen comprobaciones de integridad adicionales para la autenticación, los límites de rango y para evitar el uso de datos muy antiguos.
Se han añadido comprobaciones para advertir de que el oscilador ha tardado demasiado sin actualizar desde un origen de referencia.
Las variables peer.valid y sys.hold se agregaron para evitar inestabilidades cuando la fuente de referencia cambia rápidamente debido a grandes retrasos de dispersión en condiciones de grave congestión de la red. Se agregaron los bits peer.config, peer.authenticable y peer.authenticable para controlar características especiales y simplificar la configuración.
Si al menos una de esas comprobaciones falla, el router lo declara loco.
En las siguientes secciones se describen los modos de asociación que utilizan los servidores NTP para asociarse entre sí.
Cliente/Servidor
Simétrico activo/pasivo
Difusión
Los clientes y servidores dependientes funcionan normalmente en modo cliente/servidor, en el que un cliente o servidor dependiente se puede sincronizar con un miembro de grupo, pero ningún miembro de grupo se puede sincronizar con el cliente o servidor dependiente. Esto proporciona protección contra fallos de funcionamiento o ataques de protocolo.
El modo cliente/servidor es la configuración de Internet más común. Funciona en el paradigma clásico de llamada a procedimiento remoto (RPC) con servidores sin estado. En este modo, un cliente envía una solicitud al servidor y espera una respuesta en el futuro. En algunos contextos, esto se describiría como una operación de sondeo, en el sentido de que el cliente sondea los datos de tiempo y autenticación del servidor. Un cliente se configura en modo cliente con el comando server y con el nombre o la dirección del servidor de nombres de dominio (DNS) especificados. El servidor no requiere configuración previa.
En un modelo cliente/servidor común, un cliente envía un mensaje NTP a uno o más servidores y procesa las respuestas según se reciben. El servidor intercambia direcciones y puertos, sobrescribe determinados campos del mensaje, vuelve a calcular la suma de comprobación y devuelve el mensaje inmediatamente. La información incluida en el mensaje NTP permite al cliente determinar la hora del servidor con respecto a la hora local y, a continuación, ajustar el reloj local según sea necesario. Además, el mensaje incluye información para calcular la precisión y fiabilidad de mantenimiento de hora esperadas, así como para seleccionar el mejor servidor.
Los servidores que proporcionan sincronización a una población considerable de clientes funcionan normalmente como un grupo de tres o más servidores mutuamente redundantes, y cada uno funciona con tres o más servidores de estrato 1 o estrato 2 en modos cliente/servidor, así como todos los demás miembros del grupo en modos simétricos. Esto proporciona protección contra fallos de funcionamiento en los que uno o más servidores no pueden funcionar o proporcionar una hora incorrecta. Los algoritmos NTP están diseñados para resistir ataques cuando alguna fracción de los orígenes de sincronización configurados accidentalmente o a propósito proporcionan una hora incorrecta. En estos casos, se utiliza un procedimiento especial de votación para identificar fuentes falsas y descartar sus datos. En aras de la fiabilidad, los hosts seleccionados pueden equiparse con relojes externos y utilizarse para realizar copias de seguridad en caso de fallo de los servidores primarios y/o secundarios, o bien rutas de comunicación entre ellos.
La configuración de una asociación en el modo cliente suele indicarse mediante una declaración de servidor en el archivo de configuración e indica que desea obtener tiempo del servidor remoto, pero que no desea proporcionar tiempo al servidor remoto.
El modo activo/pasivo simétrico está pensado para las configuraciones en las que un grupo de pares de estrato bajo funcionan como copias de seguridad mutuas. Cada par funciona con una o más fuentes de referencia primarias, como un reloj de radio, o un subconjunto de servidores secundarios confiables. Si uno de los peers pierde todos los orígenes de referencia o simplemente deja de funcionar, los otros peers se reconfiguran automáticamente para que los valores de tiempo puedan fluir de los peers actuales a todos los demás en la cola. En algunos contextos, esto se describe como una operación push-pull, en el sentido de que el peer extrae o empuja el tiempo y los valores en función de la configuración en particular.
La configuración de una asociación en modo simétrico-activo, generalmente indicada por una declaración de peer en el archivo de configuración, indica al servidor remoto que uno desea obtener tiempo del servidor remoto y que también está dispuesto a proporcionar tiempo al servidor remoto si es necesario. Este modo es adecuado en configuraciones que implican una serie de servidores de tiempo redundantes interconectados a través de diversas rutas de red, que actualmente es el caso para la mayoría de los servidores de estrato 1 y estrato 2 en Internet hoy en día.
Los modos simétricos se utilizan con mayor frecuencia entre dos o más servidores que funcionan como un grupo mutuamente redundante. En estos modos, los servidores de los miembros del grupo organizan las rutas de sincronización para obtener el máximo rendimiento, en función de la fluctuación de la red y el retraso de propagación. Si uno o más de los miembros del grupo fallan, los miembros residuales se vuelven a configurar automáticamente según sea necesario.
Un par se configura en el modo activo simétrico con el comando peer y cuando se especifica el nombre DNS o la dirección del otro par. El otro par también se configura en el modo activo simétrico de esta manera.
Nota: Si el otro peer no está configurado específicamente de esta manera, se activa una asociación pasiva simétrica al llegar un mensaje activo simétrico. Dado que un intruso puede suplantar a un peer activo simétrico e inyectar valores de tiempo falsos, el modo simétrico siempre debe ser autenticado.
Cuando los requisitos de precisión y fiabilidad son modestos, los clientes se pueden configurar para utilizar los modos de difusión o multidifusión. Normalmente, estos modos no los utilizan los servidores con clientes dependientes. La ventaja es que los clientes no necesitan ser configurados para un servidor específico, y esto permite que todos los clientes operativos utilicen el mismo archivo de configuración. El modo de difusión requiere un servidor de difusión en la misma subred. Dado que los routers no propagan los mensajes de difusión, sólo se utilizan servidores de difusión en la misma subred.
El modo de difusión está pensado para configuraciones que implican uno o unos pocos servidores y un número de clientes potencialmente grande. Un servidor de broadcast se configura con el comando broadcast y una dirección de subred local. Un cliente de broadcast se configura con el comando broadcastclient, que permite al cliente de broadcast responder a los mensajes de broadcast recibidos en cualquier interfaz. Dado que un intruso puede hacerse pasar por un servidor de difusión e introducir valores de tiempo falsos, este modo siempre debe autenticarse.
Puede utilizar el comando ntp leap {add | delete} para insertar un segundo salto. Hay opciones para agregar o eliminar segundos bisiestos. Existen dos restricciones para que esto ocurra:
El reloj debe estar en estado de sincronización.
El comando se acepta solo dentro del mes anterior a que ocurra el salto. No puede establecer el salto si la hora actual es anterior a 1 mes de la aparición del salto.
Después de configurarlo, el segundo bisiesto se agrega o elimina al último segundo, como se muestra aquí:
NTP leap second added : Show clock given continuously vl-7500-6#show clock 23:59:58.123 UTC Sun Dec 31 2006 vl-7500-6#show clock 23:59:58.619 UTC Sun Dec 31 2006 vl-7500-6#show clock 23:59:59.123 UTC Sun Dec 31 2006 vl-7500-6#show clock 23:59:59.627 UTC Sun Dec 31 2006 << 59th second occurring twice vl-7500-6#show clock 23:59:59.131 UTC Sun Dec 31 2006 vl-7500-6#show clock 23:59:59.627 UTC Sun Dec 31 2006 vl-7500-6#show clock 00:00:00.127 UTC Mon Jan 1 2007 vl-7500-6#show clock 00:00:00.623 UTC Mon Jan 1 2007
Estas tres estructuras están disponibles para la arquitectura NTP:
Estructura plana de pares
Estructura jerárquica
Estructura de estrella
En una estructura de peer plana, todos los routers se conectan entre sí, con unos pocos routers separados geográficamente configurados para apuntar a sistemas externos. La convergencia del tiempo se hace más larga con cada nuevo miembro de la malla NTP.
En una estructura jerárquica, la jerarquía de enrutamiento se copia para la jerarquía NTP. Los routers de núcleo tienen una relación cliente/servidor con fuentes de tiempo externas, los servidores de tiempo internos tienen una relación cliente/servidor con los routers de núcleo, los routers de usuario interno (servidores que no son de tiempo) tienen una relación cliente/servidor con los servidores de tiempo internos, y así sucesivamente en el árbol. Estas relaciones se denominan escalas jerárquicas. Una estructura jerárquica es la técnica preferida, ya que proporciona coherencia, estabilidad y escalabilidad.
Una arquitectura NTP escalable tiene una estructura jerárquica como se ve en el siguiente diagrama.
Nota: Serie de gráficos que muestra una implementación NTP escalable y jerárquica. El primer gráfico muestra dos dispositivos NTP de estrato 2, cada uno de los cuales está conectado a dos dispositivos de estrato 1 (mostrado en el diagrama anterior de los dispositivos de estrato 2) y un compañero en otra subred indicado por un asterisco. Además, cada dispositivo del estrato 2 tiene una flecha apuntando hacia abajo. El segundo gráfico tiene el mismo diseño, pero con dispositivos del estrato 2 donde estaban los dispositivos del estrato 1 y dispositivos del estrato 3 donde estaban los dispositivos del estrato 2. El tercer gráfico tiene un dispositivo de estrato 4 conectado a tres dispositivos de estrato 3. En resumen, la imagen muestra una topología en la que cada dispositivo está conectado a 2-3 dispositivos con un estrato inferior (mejor) al suyo.
En una estructura de estrella, todos los routers tienen una relación cliente/servidor con unos pocos servidores de tiempo en el núcleo. Los servidores de tiempo dedicados son el centro de la estrella y generalmente son sistemas UNIX sincronizados con fuentes de tiempo externas, o su propio receptor GPS.
Actualmente, la subred NTP de Internet incluye más de 50 servidores primarios públicos sincronizados directamente con UTC por radio, satélite o módem. Normalmente, las estaciones de trabajo clientes y los servidores con un número de clientes relativamente pequeño no sincronizan con los servidores primarios. Aproximadamente 100 servidores secundarios públicos se sincronizan con los servidores principales y proporcionan sincronización a un total de más de 100 000 clientes y servidores en Internet. Las listas Public NTP Time Servers se actualizan con frecuencia. También hay numerosos servidores privados primarios y secundarios que normalmente no están disponibles para el público.
Nota: PIX y ASA no se pueden configurar como un servidor NTP, pero se pueden configurar como un cliente NTP.
En determinados casos, cuando se requieren servicios de hora de gran precisión en la empresa privada, como los indicadores unidireccionales para las mediciones de voz sobre IP (VoIP), los diseñadores de redes pueden optar por implementar fuentes de tiempo externas privadas. El siguiente diagrama muestra un gráfico comparativo de la precisión relativa de las tecnologías actuales.
Nota: Un gráfico que presenta formas cada vez más precisas de mantener el tiempo desde cuarzo (10 a la 8a potencia negativa) hasta el maestro de hidrógeno (10 a la 15a potencia negativa). Este último indica aproximadamente 1 segundo en pérdida de precisión durante 32 millones de años. Los otros métodos enumerados entre estos dos (de menor a más preciso) son Rubidium, Cesium, Loran C, GPS, y CDMA. Los tres últimos (Loran C, GPS y CDMA) se enumeran juntos.
Hasta hace poco, el uso de fuentes de tiempo externas no se había implementado ampliamente en las redes empresariales debido al alto coste de las fuentes de tiempo externas de calidad. Sin embargo, a medida que los requisitos de calidad del servicio (QoS) aumentan y el coste de la tecnología Time continúa disminuyendo, las fuentes de tiempo externas para redes empresariales son una opción viable.
En el siguiente diagrama, un sistema autónomo corporativo (AS) obtiene información de tiempo de tres servidores de tiempo públicos. El AS corporativo se muestra como servidores de tiempo de Área 0 y Área 1. En este ejemplo, la jerarquía NTP describe la jerarquía OSPF (Open Shortest Path First). Sin embargo, OSPF no es un requisito previo para NTP. Sólo se utiliza como ejemplo ilustrativo. NTP se puede implementar a lo largo de otros límites jerárquicos lógicos, como una jerarquía de protocolo de routing de gateway interior mejorado (EIGRP) o la jerarquía de núcleo, distribución o acceso estándar.
Nota: Un diagrama que establece una topología NTP que abarca varias redes. Tres dispositivos en el Área 1 (OSPF) son pares entre sí y clientes de servidores en el Área 0. Tres dispositivos en el Área 0 son pares entre sí, clientes de servidores de tiempo públicos y servidores de clientes en el Área 1. Los Servidores de hora públicos solo se muestran como servidores para clientes en el Área 0.
Este ejemplo es la configuración del IOS de Cisco para el dispositivo A0-R1 como se muestra en el diagrama anterior.
clock timezone CST -5 clock summer-time CDT recurring !--- This router has a hardware calendar.
!--- To configure a system as an
!--- authoritative time source for a network
!--- based on its hardware clock (calendar),
!--- use the clock calendar-valid global
!--- configuration command. Notice later that
!--- NTP can be allowed to update the calendar
!--- and Cisco IOS can be configured to be an
!--- NTP master clock source.
!--- Cisco IOS can then obtain its clock from
!--- the hardware calendar. clock calendar-valid !--- This allows NTP to update the hardware
!--- calendar chip. ntp update-calendar !--- Configures the Cisco IOS software as an
!--- NTP master clock to which peers synchronize
!--- themselves when an external NTP source is
!--- not available. Cisco IOS can obtain the
!--- clock from the hardware calendar based on
!--- the previous line. This line can keep the
!--- whole network in Sync even if Router1 loses
!--- its signal from the Internet. Assume, for
!--- this example, that the Internet time servers
!--- are stratum 2. ntp master 3 !--- When the system sends an NTP packet, the
!--- source IP address is normally set to the
!--- address of the interface through which the
!--- NTP packet is sent.
!--- Change this to use loopback0. ntp source Loopback0 !--- Enables NTP authentication. ntp authenticate ntp authentication-key 1234 md5 104D000A0618 7 ntp trusted-key 1234 !--- Configures the access control groups for
!--- the public servers and peers for additional
!--- security. access-list 5 permit <I-TS-1> access-list 5 permit <I-TS-2> access-list 5 permit <I-TS-3> access-list 5 permit <A0-R2> access-list 5 permit <A0-R3> access-list 5 deny any !--- Configures the access control groups for the
!--- clients to this node for additional security. access-list 6 permit <A1-R1> access-list 6 permit <A1-R2> access-list 6 permit <A1-R3> access-list 6 deny any !--- Restricts the IP addresses for the peers
!--- and clients. ntp access-group peer 5 ntp access-group serve-only 6 !--- Fault tolerant configuration polling for 3 NTP
!--- public servers, peering with 2 local servers. ntp server <I-TS-1> ntp server <I-TS-2> ntp server <I-TS-3> ntp peer <A0-R2> ntp peer <A0-R3>
En la sección anterior se describe una red WAN de distribución del tiempo. Esta sección se desplaza un paso hacia abajo en la jerarquía para tratar la distribución del tiempo en una red de campus de alto nivel.
La diferencia principal que se considera para la distribución del tiempo en una red de campus de alto estrato es el uso potencial del modo de asociación de difusión. Como se ha descrito anteriormente, el modo de asociación de difusión simplifica las configuraciones de las LAN, pero reduce la precisión de los cálculos de tiempo. Por lo tanto, la compensación de los costes de mantenimiento debe considerarse en relación con la exactitud de las mediciones de rendimiento.
Nota: Diagrama titulado Red de distribución del tiempo de campus de alto estrato que incluye una topología genérica de tres niveles (red troncal, distribución y acceso). Los switches de acceso son clientes de switches de distribución, los switches de distribución son clientes de switches de red troncal y los switches de red troncal son clientes de servidores de hora de área (no se muestra en la imagen). Los switches de distribución se dividen en pares y tienen una relación de par sólo con el otro switch del par. Los dos switches de red troncal también son pares entre sí. Cuatro switches de acceso (en la parte superior izquierda) se muestran como clientes de difusión con flechas punteadas, mientras que el resto de las relaciones cliente-servidor y par-par no son de difusión.
La red de campus de alto estrato, que se muestra en el diagrama anterior, se ha tomado del diseño de red de campus estándar de Cisco y contiene tres componentes. El núcleo del campus consta de dos dispositivos de capa 3 con las etiquetas CB-1 y CB-2. El componente de servidor, ubicado en la sección inferior de la figura, tiene dos routers de Capa 3 con las etiquetas SD-1 y SD-2. Los otros dispositivos del bloque de servidores son dispositivos de capa 2. En la parte superior izquierda hay un bloque de acceso estándar con dos dispositivos de distribución de capa 3 con las etiquetas dl-1 y dl-2. El resto de los dispositivos son switches de capa 2. En este bloque de acceso de cliente, el tiempo se distribuye con la opción de difusión. En la parte superior derecha, hay otro bloque de acceso estándar que utiliza una configuración de distribución de tiempo cliente/servidor.
Los dispositivos de red troncal de las instalaciones se sincronizan con los servidores de hora de área en un modelo cliente/servidor.
Esta es la configuración para los dispositivos de distribución de capa 3 dl-1:
!--- In this case, dl-1 can be a broadcast server
!--- for the Layer 2 LAN. internet Ethernet0 ntp broadcast clock timezone CST -5 clock summer-time CDT recurring !--- When the system sends an NTP packet, the
!--- source IP address is normally set to the
!--- address of the interface through which the
!--- NTP packet is sent.
!--- Change this to use loopback0. ntp source Loopback0 !--- Enables NTP authentication. ntp authenticate ntp authentication-key 1234 md5 104D000A0618 7 ntp trusted-key 1234 !--- Configures the access control groups for
!--- the public servers and peers for
!--- additional security. access-list 5 permit <CB-1> access-list 5 permit <CB-2> access-list 5 permit <dl-2> access-list 5 deny any !--- Restricts the IP addresses for the peers
!--- and clients. ntp access-group peer 5 !--- Fault tolerant configuration polling 2
!--- local time servers and 1 local peer. ntp server <CB-1> ntp server <CB-2> ntp peer <dl-2>
En el siguiente diagrama, se proporciona una fuente de tiempo GPS o Cesium en el Data Center central para la red de campus de estrato bajo. Esto aprovisiona una fuente de tiempo de estrato 1 en la red privada. Si hay varias fuentes de tiempo GPS o Cesium ubicadas en la red privada, se debe modificar la distribución de tiempo en la red privada para aprovechar las fuentes de tiempo disponibles.
En general, se aplican los mismos principios y configuraciones que en los ejemplos anteriores. La diferencia principal en este caso es que la raíz del árbol de sincronización es una fuente horaria privada en lugar de una fuente horaria pública de Internet. Esto cambia el diseño de la red de distribución de tiempo para aprovechar la fuente de tiempo privada de alta precisión. La fuente de tiempo privada se distribuye por toda la red privada con los principios de jerarquía y modularidad que se han descrito en las secciones anteriores.
Nota: Diagrama titulado Red de distribución del tiempo de campus de estrato bajo que incluye una topología genérica de tres niveles (red troncal, distribución y acceso). Dos interruptores de distribución tienen GPS o relojes de cesio conectados. Los switches de acceso conectados directamente a estos switches de distribución y los switches de red troncal son clientes de estos switches de distribución. Todos los demás switches de distribución de la red son clientes de los switches de la red troncal y los switches de acceso restantes también son clientes de sus switches de distribución conectados directamente. Cuatro switches de acceso (en la parte superior izquierda) se muestran como clientes de difusión con flechas punteadas, mientras que el resto de las relaciones cliente-servidor y par-par no son de difusión.
Una definición de proceso es una serie conectada de acciones, actividades y cambios realizados por agentes que pretenden satisfacer un propósito o alcanzar un objetivo. El control de procesos es el proceso de planificación y regulación, con el objetivo de realizar un proceso de una manera efectiva y eficiente. Esto se muestra en el siguiente diagrama.
Nota: Un diagrama que especifica el significado de un proceso utilizado por este documento. Hay cinco regiones. La región izquierda tiene un borde sólido. Contiene entradas, SNMP y Syslog. Hay una flecha de una dirección desde la región izquierda hasta la región central. La región derecha también tiene un borde sólido. Contiene resultados, informes y métricas. Hay una flecha de una dirección desde la región central a la región derecha. La región superior tiene un borde punteado. Contiene propietario, objetivos e indicadores de rendimiento. Hay círculos con bordes sólidos alrededor de los tres. Existen flechas bidireccionales entre (a) el propietario y los indicadores de rendimiento (b) los objetivos y los indicadores de rendimiento y (c) la región superior y la región central. La región inferior también tiene un borde punteado. Contiene recursos y funciones. Hay círculos con bordes sólidos alrededor de ambos. Existen flechas bidireccionales que parecen conectar recursos y roles con la región central, pero se detienen en el borde de la región inferior. La región central tiene un borde sólido y un encabezado que dice Proceso. También contiene una de cada una de las tareas y subtareas. Cada uno tiene un borde circular sólido. Tareas tiene más espacio en blanco dentro del círculo que cualquier otro elemento del gráfico.
El resultado del proceso debe cumplir con las normas operativas definidas por una organización y basadas en los objetivos de la empresa. Si el proceso cumple con el conjunto de normas, se considera eficaz ya que se puede repetir, medir, administrar y además, contribuye con los objetivos comerciales. Si las actividades se realizan con un mínimo esfuerzo, el proceso también se considera eficaz.
Los procesos abarcan varios límites organizativos. Por consiguiente, es importante tener un único propietario del proceso que sea responsable de la definición del proceso. El propietario es el punto focal que determina e informa si el proceso es efectivo y eficiente. Si el proceso no es eficaz o eficiente, el titular del proceso será quien haga las modificaciones al proceso. La modificación del proceso está regida por los procesos de control y revisión de cambios.
Los objetivos del proceso son establecidos para especificar la dirección y el alcance para la definición del proceso. Las metas también se utilizan para definir mediciones que se utilizan para medir la eficacia de un proceso.
El objetivo de este proceso es proporcionar criterios que se documentarán durante la fase de diseño de NTP y proporcionar una capacidad de auditoría para una arquitectura NTP implementada para garantizar el cumplimiento a largo plazo con el diseño previsto.
Los indicadores de funcionamiento del proceso se utilizan para medir la efectividad de la definición del proceso. Los indicadores de rendimiento deben ser mensurables y cuantificables. Por ejemplo, los indicadores de rendimiento que se muestran a continuación son numéricos o se miden por tiempo.
La cantidad de tiempo requerida para ejecutar todo el proceso.
Frecuencia de ejecución necesaria para detectar de forma proactiva los problemas de NTP antes de que afecten a los usuarios.
La carga de la red asociada a la ejecución del proceso.
Cantidad de medidas correctivas recomendadas por el proceso.
El número de acciones correctivas implementadas como resultado del proceso.
La cantidad de tiempo solicitado para instrumentar las acciones correctivas.
La acumulación de acciones correctivas.
Los errores en la resolución de problemas o en el diagnóstico de problemas se atribuyen a problemas relacionados con NTP.
El número de elementos agregados, eliminados o modificados en el archivo simiente. Ésta es una indicación de precisión y estabilidad.
Las entradas del proceso se utilizan para definir los criterios y los requisitos previos de un proceso. Muchas veces, la identificación de las entradas del proceso proporciona información sobre las dependencias externas. A continuación se proporciona una lista de entradas relacionadas con la administración de NTP.
documentación de diseño de NTP
Datos NTP MIB recopilados por sondeo SNMP
Los resultados del proceso se definen como:
Informes de configuración de NTP definidos en la sección Presentación de Datos de este documento
acciones correctivas NTP
En las siguientes secciones se definen las tareas iterativas y de inicialización asociadas a la administración de NTP.
Las tareas de inicialización se ejecutan una vez durante la implementación del proceso y no deben ejecutarse durante cada iteración del proceso.
Cuando se comprueban las tareas previas, si se determina que alguna de las tareas no está implementada o no proporciona suficiente información para satisfacer eficazmente las necesidades de este procedimiento, el propietario del proceso debe documentar este hecho y enviarlo a la administración. En la tabla siguiente se describen las tareas de inicialización necesarias.
Tarea previa necesaria | Descripción |
---|---|
Objetivos de la Tarea |
Cree un documento de diseño detallado para la arquitectura NTP que cumpla los requisitos de diseño y los objetivos de costes. |
Entradas de tareas |
|
Resultado de la tarea |
Documentación de diseño de NTP. |
Recursos de la tarea |
Arquitecto ingeniero de redes Arquitecto de operaciones de red. |
Funciones de tarea |
Aprobación técnica de diseño de red por parte de revisores de ingeniería y operaciones Costes de diseño de red aprobados por el gestor de presupuesto responsable. |
El proceso de administración de NTP requiere el uso de un archivo simiente para eliminar la necesidad de una función de detección de red. El archivo simiente registra el conjunto de routers gobernados por el proceso NTP y también se utiliza como punto focal para coordinar con los procesos de administración de cambios en una organización. Por ejemplo, si se ingresan nuevos nodos en la red, deben agregarse al archivo simiente NTP. Si se realizan cambios en los nombres de comunidad SNMP debido a los requisitos de seguridad, esas modificaciones deberán reflejarse en el archivo simiente. La siguiente tabla describe cómo crear un archivo simiente.
Tarea previa necesaria | Descripción |
---|---|
Objetivos de la Tarea |
Cree un archivo simiente que identifique tres categorías de dispositivos de red:
|
Entradas de tareas |
Documentación de diseño de NTP Documentación de topología de red. |
Resultado de la tarea |
Archivo de inicialización. |
Recursos de la tarea |
Criterios de diseño que se pueden utilizar para identificar y priorizar los nodos implicados en la arquitectura NTP. |
Varios de los parámetros disponibles para monitorear la red NTP exhiben algunas variaciones normales esperadas. El proceso de referencia se utiliza para caracterizar las variaciones esperadas normales y para establecer umbrales que definan condiciones inesperadas o anormales. Esta tarea se utiliza para establecer la línea de base del conjunto variable de parámetros para la arquitectura NTP.
Proceso | Descripción |
---|---|
Objetivos de la Tarea |
Parámetros de variable de línea base. |
Entradas de tareas |
Identifique los parámetros de variable cntpSysRootDelay cntpSysRootDispersion cntpPeersRootDelay cntpPeersRootDispersion cntpPeersOffset cntpPeersDelay cntpPeersDispersion. |
Salida de la tarea |
Valores de referencia y umbrales. |
Recursos de la tarea |
Herramientas que recopilan datos SNMP y calculan líneas de base. |
Función de la tarea |
Ingeniero de redes Ingeniero de NMS. |
Las tareas iterativas se ejecutan durante cada iteración del proceso y su frecuencia se determina y modifica con el fin de mejorar los indicadores de rendimiento.
El archivo simiente es crítico para la implementación efectiva del proceso de administración de NTP. Por consiguiente, el estado actual del archivo simiente debe ser administrado en forma activa. El propietario del proceso de administración NTP debe realizar un seguimiento de los cambios en la red que afectan al contenido del archivo simiente.
Proceso | Descripción |
---|---|
Objetivos de la Tarea | Mantener la precisión del archivo simiente |
Entradas de tareas | Información sobre cambios en la red |
Salida de la tarea | Archivo simiente |
Recursos de la tarea | Informes, notificaciones y reuniones relacionadas con cambios |
Función de la tarea | Ingeniero de redes Ingeniero de NMS |
Recopile información sobre análisis críticos, interesantes y de configuración definidos por este procedimiento. Ejecute estos tres escáneres a diferentes frecuencias.
Los nodos críticos son dispositivos que se consideran muy importantes para los puntos de datos de recopilación de rendimiento. El análisis crítico de nodos se ejecuta a menudo, por ejemplo, cada hora o a petición antes y después de los cambios. Los nodos interesantes son dispositivos que se consideran importantes para la integridad general de la arquitectura NTP pero que no pueden estar en el árbol de sincronización de tiempo para la recopilación de datos de rendimiento críticos. Este informe se ejecuta periódicamente, por ejemplo, diariamente o mensualmente. El informe de configuración es un informe exhaustivo y que utiliza muchos recursos que se utiliza para caracterizar la configuración de implementación NTP general comparándola con los registros de diseño. Este informe se ejecuta con menos frecuencia, por ejemplo, mensualmente o trimestralmente. Un punto importante a tener en cuenta es que la frecuencia con la que se recopilan los informes se puede ajustar en función de la estabilidad observada de la arquitectura NTP y las necesidades empresariales.
Proceso | Descripción |
---|---|
Objetivo de la tarea | Supervisar la arquitectura NTP |
Entrada de tarea | Datos del dispositivo de red |
Resultado de la tarea | Informes |
Recursos de la tarea | Aplicaciones de software para recopilar datos y generar informes |
Función de la tarea | Ingeniero de redes |
Esta tarea requiere que se revisen y analicen los informes críticos, interesantes y de configuración. Si se detectan problemas, se deben iniciar acciones correctivas.
Proceso | Descripción |
---|---|
Entradas de tareas | Analizar informes |
Salida de la tarea | Análisis de estabilidad Acciones correctivas |
Recursos de la tarea | Acceso a los dispositivos de red para su posterior investigación y verificación |
Función de la tarea | Ingeniero de redes |
En la siguiente tabla se describen los datos que se consideran significativos cuando se analiza la arquitectura NTP.
Datos | Descripción |
---|---|
ID de nodos | Un dispositivo que tiene NTP configurado |
Pares | Los pares configurados para el dispositivo |
Origen de sincronización | El par seleccionado para la sincronización |
datos de configuración NTP | Parámetros utilizados para juzgar la consistencia del diseño NTP |
datos de calidad NTP | Parámetros utilizados para caracterizar la calidad de las asociaciones NTP |
Los datos SNMP de NTP son definidos por Cisco-NTP-MIB. Para obtener información actual sobre las versiones que admiten esta MIB, utilice la herramienta CCO Feature Navigator y seleccione la opción MIB Locator. Se accede a esta herramienta a través de la página Herramientas TAC para Tecnologías de Voz, Telefonía y Mensajería.
El grupo del sistema en Cisco NTP MIB proporciona información para el nodo de destino que ejecuta NTP. El nodo de destino es el destino de las consultas SNMP.
Nombre del Objeto | Descripción del Objeto |
---|---|
cntpSysStratum | El estrato del reloj local. Si el valor se establece en 1, una referencia primaria, entonces el procedimiento de Reloj Primario descrito en la Sección 3.4.6, en RFC-1305 se invoca. ::= { cntpSystem 2 } identificador de objeto = .1.3.6.1.4.1.9.9.168.1.1.2 |
cntpSysPrecision | Entero con signo que indica la precisión del reloj del sistema, en segundos, a la potencia más cercana de dos. El valor debe redondearse a la siguiente potencia mayor de dos. Por ejemplo, a un reloj de frecuencia de alimentación de 50 Hz (20 ms) o 60 Hz (16,67 ms) se le asigna el valor -5 (31,25 ms), mientras que a un reloj controlado por cristal de 1000 Hz (1 ms) se le asigna el valor -9 (1,95 ms). ::= { cntpSystem 3 } identificador de objeto = .1.3.6.1.4.1.9.9.168.1.1.3 |
cntpSysRootDelay | Un número de punto fijo firmado que indica la demora de ida y vuelta total en segundos al origen de referencia principal en la raíz de la subred de sincronización. ::= { cntpSystem 4 } identificador de objeto = .1.3.6.1.4.1.9.9.168.1.1.4 |
cntpSysRootDispersion | El error máximo en segundos, relativo al origen de referencia principal en la raíz de la subred de sincronización. Sólo son posibles los valores positivos mayores que cero. ::= { cntpSystem 5 } identificador de objeto = .1.3.6.1.4.1.9.9.168.1.1.4 |
cntpSysRefTime | Hora local en la que se actualizó el reloj local por última vez. Si el reloj local nunca se ha sincronizado, el valor es cero. ::= { cntpSystem 7 } identificador de objeto = .1.3.6.1.4.1.9.9.168.1.1.7 |
cntpSysPeer | El origen de sincronización actual que contiene el identificador de asociación único cntpPeersAssocId de la entrada de peer correspondiente en cntpPeersVarTable del peer que actúa como el origen de sincronización. Si no hay ningún par, el valor es cero. ::= { cntpSystem 9 } identificador de objeto = .1.3.6.1.4.1.9.9.168.1.1.9 |
cntpSysClock | La hora local actual. La hora local se deriva del reloj de hardware de la máquina en particular y se incrementa a intervalos basados en el diseño utilizado. ::= { cntpSystem 10 } identificador de objeto = .1.3.6.1.4.1.9.9.168.1.1.10 |
El grupo de peers de Cisco NTP MIB proporciona información sobre los peers del nodo de destino.
Nombre del Objeto | Descripción del Objeto |
---|---|
cntpPeersVarTable | Esta tabla proporciona información sobre los peers con los cuales el servidor NTP local tiene asociaciones. Los peers también son servidores NTP que se ejecutan en diferentes hosts. Ésta es una tabla de cntpPeersVarEntry ::= { cntpPeers 1 } identificador de objeto = .1.3.6.1.4.1.9.9.168.1.2.1 |
cntpPeersVarEntry | La entrada de cada par proporciona información NTP recuperada de un servidor NTP par determinado. Cada par se identifica mediante un identificador de asociación único. Las entradas se crean automáticamente cuando el usuario configura el servidor NTP para que se asocie con peers remotos. Del mismo modo, las entradas se eliminan cuando el usuario quita la asociación de peer del servidor NTP. La estación de administración también puede crear entradas estableciendo valores para cntpPeersPeerAddress, cntpPeersHostAddress, cntpPeersMode y estableciendo cntpPeersEntryStatus como active (1). Como mínimo, la estación de administración debe establecer un valor para cntpPeersPeerAddress para activar la fila. INDEX { cntpPeersAssocId } ::= { cntpPeersVarTable 1 } identificador de objeto = .1.3.6.1.4.1.9.9.168.1.2.1.1 |
cntpPeersAssocId | Un valor entero mayor que cero que identifica de forma única un par con el cual el servidor NTP local está asociado. ::= { cntpPeersVarEntry 1 } identificador de objeto = .1.3.6.1.4.1.9.9.168.1.2.1.1.1 |
cntpPeersConfigured | Se trata de un bit que indica que la asociación se creó a partir de la información de configuración y no se debe desasociar incluso si el par se vuelve inalcanzable. ::= { cntpPeersVarEntry 2 } identificador de objeto = .1.3.6.1.4.1.9.9.168.1.2.1.1.2 |
cntpPeersPeerAddress | La dirección IP del par. Cuando se crea una nueva asociación, se debe establecer un valor para este objeto antes de activar la fila. ::= { cntpPeersVarEntry 3 } identificador de objeto = .1.3.6.1.4.1.9.9.168.1.2.1.1.3 |
cntpPeersMode | SYNTAX INTEGER { unspecified (0), symmetricActive (1), symmetricPassive (2), client (3), server (4), broadcast (5), reservedControl (6), reservedPrivate (7) } Cuando se crea una nueva asociación de peer, si no se especifica ningún valor para este objeto, se establece de forma predeterminada symmetricActive (1). ::= { cntpPeersVarEntry 8 } identificador de objeto = .1.3.6.1.4.1.9.9.168.1.2.1.1.1.1.1.1.1.1.1.1.1.1.1.8 |
cntpPeersStratum | El estrato del reloj de peer. ::= { cntpPeersVarEntry 9 } identificador de objeto = .1.3.6.1.4.1.9.9.168.1.2.1.1.9 |
cntpPeersRootDelay | Un número de punto fijo firmado que indica la demora de ida y vuelta total en segundos, desde el par al origen de referencia principal en la raíz de la subred de sincronización. ::= { cntpPeersVarEntry 13 } identificador de objeto = .1.3.6.1.4.1.9.9.168.1.2.1.1.13 |
cntpPeersRootDispersion | El error máximo, en segundos, del reloj de peer relativo al origen de referencia principal en la raíz de la subred de sincronización. Sólo son posibles los valores positivos mayores que cero. ::= { cntpPeersVarEntry 14 } identificador de objeto = .1.3.6.1.4.1.9.9.168.1.2.1.1.14 |
cntpPeersRefTime | La hora local del par cuando se actualizó su reloj por última vez. Si el reloj de par nunca se ha sincronizado, el valor es cero. ::= { cntpPeersVarEntry 16 } identificador de objeto = .1.3.6.1.4.1.9.9.168.1.2.1.1.16 |
cntpPeersReach | Registro de turno utilizado para determinar el estado de disponibilidad del par, con bits que entran desde el extremo menos significativo (el más a la derecha). Un par se considera alcanzable si al menos un bit en este registro se establece en uno (el objeto es distinto de cero). Los datos del registro de turnos se rellenan mediante los procedimientos del protocolo NTP. ::= { cntpPeersVarEntry 21 } identificador de objeto = .1.3.6.1.4.1.9.9.168.1.2.1.1.21 |
cntpPeersOffset | El desplazamiento estimado del reloj de peer con respecto al reloj local, en segundos. El host determina el valor de este objeto que utiliza el algoritmo de filtro de reloj NTP. ::= { cntpPeersVarEntry 23 } identificador de objeto = .1.3.6.1.4.1.9.9.168.1.2.1.1.21 |
cntpPeersDelay | La demora de ida y vuelta estimada del reloj de peer en relación con el reloj local en el trayecto de red entre ellos, en segundos. El host determina el valor de este objeto que utiliza el algoritmo de filtro de reloj NTP. ::= { cntpPeersVarEntry 24 } identificador de objeto = .1.3.6.1.4.1.9.9.168.1.2.1.1.24 |
cntpPeersDispersion | El error máximo estimado del reloj de peer con respecto al reloj local en el trayecto de red entre ellos, en segundos. El host determina el valor de este objeto que utiliza el algoritmo de filtro de reloj NTP. ::= { cntpPeersVarEntry 25 } identificador de objeto = .1.3.6.1.4.1.9.9.168.1.2.1.1.25 |
Toda la información requerida por este procedimiento se puede recopilar mediante consultas SNMP. Para analizar los datos y producir los informes, se deben desarrollar scripts personalizados o programas de software.
Los nodos críticos son dispositivos importantes en el árbol de sincronización de los puntos de recopilación de datos de rendimiento seleccionados. Si hay un servicio VoIP de ingresos altos que se monitorea y se recopilan métricas de variación de demora unidireccional, los nodos de origen y destino donde se registran las marcas de tiempo se consideran nodos críticos.
En este ejemplo, el diseño NTP se ha establecido junto a una jerarquía OSPF de ejemplo. Por lo tanto, los informes que se describen a continuación están formateados para agrupar los dispositivos NTP por el área OSPF del dispositivo. En los casos en los que un nodo tiene interfaces en varias áreas, el software de generación de informes debe decidir en qué área se puede incluir el nodo a efectos de informes. Como se mencionó anteriormente, OSPF no es un requisito previo para NTP. Sólo se utiliza en este documento como ejemplo ilustrativo.
Área | Dispositivo | Datos del dispositivo | Valor |
---|---|---|---|
AreaId #n | DeviceId #1 | cntpSysStratum | |
cntpSysPrecision | |||
cntpSysRootDelay | |||
cntpSysRootDispersion | |||
cntpSysRefTime | |||
cntpSysPeer | |||
cntpSysClock | |||
DeviceId #n | cntpSysStratum | ||
cntpSysPrecision | |||
cntpSysRootDelay | |||
cntpSysRootDispersion | |||
cntpSysRefTime | |||
cntpSysPeer | |||
cntpSysClock |
El formato del informe de nodo interesante es el mismo que el del informe de nodo crítico. Los nodos interesantes son aquellos que se consideran importantes para la arquitectura NTP general, pero que no pueden contribuir directamente a la sincronización temporal de los puntos críticos de supervisión del rendimiento.
El informe de configuración es un informe completo que recopila información sobre la arquitectura NTP general. Este informe se utiliza para registrar y comprobar la implementación de NTP con los registros de diseño.
Área | Dispositivo | Entidad par | Datos de peer | Valor |
---|---|---|---|---|
AreaId #n | DeviceId #n | PeerId #1 | cntpPeersAssocId | |
cntpPeersConfigured | ||||
cntpPeersPeerAddress | ||||
cntpPeersMode | ||||
cntpPeersStratum | ||||
cntpPeersRootDelay | ||||
cntpPeersRootDispersion | ||||
cntpPeersRefTime | ||||
cntpPeersReach | ||||
cntpPeersOffset | ||||
cntpPeersDelay | ||||
cntpPeersDispersion | ||||
PeerId #n | cntpPeersAssocId | |||
cntpPeersConfigured | ||||
cntpPeersPeerAddress | ||||
cntpPeersMode | ||||
cntpPeersStratum | ||||
cntpPeersRootDelay | ||||
cntpPeersRootDispersion | ||||
cntpPeersRefTime | ||||
cntpPeersReach | ||||
cntpPeersOffset | ||||
cntpPeersDelay | ||||
cntpPeersDispersion |
Revisión | Fecha de publicación | Comentarios |
---|---|---|
4.0 |
14-Mar-2024 |
Recertificación |
1.0 |
15-Feb-2002 |
Versión inicial |