Uso de prácticas recomendadas para el protocolo de tiempo de red

Introducción

Este documento describe las mejores prácticas para diseñar Network Time Protocol .

Prerequisites

Requirements

Cisco le recomienda que tenga conocimiento acerca de este tema:   

• Network Time Protocol

• Servidores temporizadores públicos y tecnología de temporización

Componentes Utilizados

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.

Antecedentes

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:

• La sección Terminología proporciona definiciones generales de términos en torno a la sincronización horaria.
• La sección Descripción general proporciona información general sobre el hardware de elementos de red relacionados con la hora del sistema, una descripción general tecnológica de NTP y los aspectos de diseño clave para la arquitectura NTP.
• La sección Ejemplo de implementación de NTP proporciona ejemplos de implementación de NTP con configuraciones de ejemplo para WAN, campus de alto estrato y redes de distribución de tiempo de campus de bajo estrato.
• La sección Definiciones de Proceso proporciona una descripción general de las definiciones de proceso utilizadas para lograr la administración de NTP. Los detalles del proceso se describen en términos de objetivos, indicadores de rendimiento, entradas, salidas y tareas individuales.
• La sección Definiciones de tareas proporciona definiciones detalladas de las tareas del proceso. Cada tarea se describe en términos de objetivos, entradas de tareas, salidas de tareas, recursos necesarios para realizar la tarea y habilidades de trabajo necesarias para un implementador de tareas.
• La sección Identificación de datos describe la identificación de datos para NTP. La identificación de datos considera la fuente de la información. Por ejemplo, la información puede estar contenida en la base de información de administración (MIB) del protocolo simple de administración de red (SNMP), en archivos de registro generados por Syslog o por estructuras de datos internas a las que sólo puede tener acceso la interfaz de línea de comandos (CLI).
• La sección Recopilación de Datos describe la recopilación de los datos NTP. La recolección de los datos está estrechamente relacionada con la ubicación de los datos. Por ejemplo, los datos MIB SNMP son reunidos por varios mecanismos tales como notificaciones de trampa, eventos y alarmas de supervisión remota (RMON) o consultas. Los datos mantenidos por las estructuras de datos internas se recopilan mediante scripts automáticos o cuando un usuario inicia sesión manualmente en el sistema para ejecutar el comando CLI y registrar el resultado.
• La sección Presentación de datos proporciona ejemplos de formato de informe de cómo se pueden presentar los datos.

Terminology

• 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.

Overview

Información general del dispositivo

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.

Descripción general de NTP

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.

Criterios de diseño 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.

Modos de asociación

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

Modo cliente/servidor

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.

Modo activo/pasivo simétrico

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.

Modo de difusión y/o multidifusión

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.

Set NTP Leap Second

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

Arquitectura NTP

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.

Arquitectura NTP escalable

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.

Servidores temporizadores públicos y tecnología de temporización

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.

Gráfico comparativo

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.

Ejemplo de instalación de NTP

Red WAN de distribución de tiempo

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.

Red WAN de distribución de tiempo

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>

Distribución de tiempo en una red de oficinas centrales de alto nivel

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.

Distribución de tiempo en una red de oficinas centrales de alto nivel

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>

Red de distribución de tiempo de oficinas centrales de estrato más bajo

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.

Red de distribución de tiempo de oficinas centrales de estrato más bajo

Definiciones de procesos

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. 

Serie de procesos

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.

Propietario del proceso

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.

Metas de procesos

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.

Indicadores de rendimiento de procesos'1

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.

Entradas del proceso

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

Salidas del proceso

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

Definiciones de tareas

En las siguientes secciones se definen las tareas iterativas y de inicialización asociadas a la administración de NTP.

Tareas de inicialización

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.

Crear el diseño NTP

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	Requisitos técnicos y económicos del diseño Documentación de diseño de red actual Criterios que definen los aspectos obligatorios que se deben registrar en el diseño para habilitar las funciones de gestión Información de implementación de aplicaciones de TI Requisitos de supervisión del rendimiento
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.

Crear un archivo simiente

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: Dispositivos críticos: sondeo frecuente para obtener información de configuración Dispositivos interesantes: sondeados con menor frecuencia Todos los dispositivos habilitados para NTP: sondearon la menor cantidad
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.

Parámetros de rendimiento de NTP de referencia

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.

Tareas iterativas

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.

Mantener el archivo simiente

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

Ejecutar el análisis del nodo NTP

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

Revisar los informes de nodos NTP

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

Identificación de datos

Características de datos generales

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

Identificación de datos SNMP

Grupo del sistema Cisco NTP MIB

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

Cisco NTP MIB Peer Group - Peers Variable Table

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

Recolección de datos

Colección de datos SNMP

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.

Presentación de datos

Informe NTP de nodos críticos

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

Informe de nodos interesantes con NTP

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.

Informe de configuración de NTP

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

Información Relacionada

• RFC 1305 Protocolo de tiempo de red
• Marco RFC 2330 para las métricas de rendimiento de IP
• Funciones esenciales de Cisco IOS Todos los ISP deben considerar la versión 2.84
• Soporte técnico y descargas de Cisco