Solucionar problemas de NTP en IM&P

Introducción

Este documento describe cómo resolver problemas de sincronización del protocolo de tiempo de la red (NTP) en IM y presencia (IM&P).

Prerequisites

Cisco recomienda tener conocimientos básicos de NTP y la interfaz de línea de comandos (CLI) de IM&P antes de revisar este documento.

Requirements

No hay requisitos específicos de hardware o software para este documento.

Componentes Utilizados

La información de este documento se basa en IM&P.

Nota: gran parte de esta información también se aplica a otras plataformas de Comunicaciones Unificadas (UC); sin embargo, el objetivo de este documento es IM&P.

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.

Explicación de NTP en IM&P

El publicador de Cisco Unified Communications Manager (CUCM) es el origen NTP para IM&P. IM&P utiliza el sistema de control NTP para mantener la hora sincronizada con el publicador de CUCM. Para las plataformas de IM&P que se encuentran en una máquina virtual, NTP Watchdog sondea el Publicador de CUCM una vez cada 64 segundos de forma predeterminada. Si el desplazamiento de NTP es superior a tres segundos, el demonio NTP se reinicia.

Nota: NTP Watchdog monitorea cuántas veces se reinició el demonio NTP en la última hora. Si se producen más de 10 reinicios del demonio NTP en el plazo de una hora, los reinicios posteriores se posponen brevemente.

Requisitos para el origen NTP

Cisco recomienda encarecidamente el uso de un servidor NTP de estrato 1, estrato 2 o estrato 3 como referencia NTP externa del editor de CUCM. Ningún origen NTP para el editor de CUCM DEBE ser superior al estrato 4.

Los servidores NTP externos definidos para el nodo del editor de CUCM DEBEN ser NTP v4 para evitar posibles problemas de compatibilidad, precisión y fluctuación de red. La versión 4 de NTP es compatible con la versión 3; sin embargo, se observaron muchos problemas con los intentos de utilizar diferentes versiones de NTP.

Advertencia: no se admite el uso de Windows Time Services como servidor NTP. A menudo, los Servicios de hora de Windows utilizan el Protocolo simple de hora de red (SNTP) y CUCM no se puede sincronizar correctamente con SNTP.

Nota: todos los requisitos de NTP se indican claramente en el SRND de Cisco Collaboration System. 

Explicación de salida de estado NTP

Para determinar el estado actual de NTP en IM&P, ejecute el comando utils ntp status desde la CLI del servidor IM&P.

admin:utils ntp status
ntpd (pid 28589) is running...

  remote         refid      st  t when poll reach   delay   offset   jitter
==============================================================================
 10.0.0.1     192.0.2.0   2  u  40   64    1     0.292    0.041   0.000


synchronised to NTP server (10.0.0.1) at stratum 3
  time server re-starting
   poll server every 64 s

Current time in UTC is : Fri Sep 16 19:41:55 UTC 2016
Current time in America/New_York is : Fri Sep 16 15:41:55 EDT 2016

Estas son descripciones de las columnas vistas en la salida de estado NTP

• La columna remote define el peer remoto donde se sincroniza la hora. Si se establece en LOCAL, el reloj de hardware local está en uso. 

• La columna refid define el origen de tiempo del servidor remoto. Si se establece en .LOCL, se hace referencia al reloj de hardware local del servidor remoto. Si se establece en .INIT, la inicialización aún no se ha realizado correctamente.
  
  
• La columna st denota el estrato del peer NTP remoto. Cuando un valor de 16 está en la columna del estrato, esto significa que el sistema utiliza el reloj interno en lugar del origen NTP externo. Un sistema que utiliza su propio reloj puede ser causado por un proveedor de hora no válido. 
  
  
• La columna t indica el tipo de transmisión en uso: (l: local; u: unicast; m: multicast, o b: broadcast).
  
  
• La columna when indica cuántos segundos han pasado desde que se sondeó por última vez el par remoto. 
  
  
• La columna poll indica el intervalo de sondeo en segundos. El valor de sondeo predeterminado en IM&P es de 64 segundos. Sin embargo, este valor se puede establecer entre 64 y 1024 segundos. 

• La columna reach indica la tendencia de las pruebas de accesibilidad en octal, donde cada dígito, cuando se convierte en binario, representa si una encuesta determinada fue exitosa (binario 1) o no exitosa (binario 0). Por ejemplo, "1" significa que hasta el momento solo se ha realizado una encuesta y que fue exitosa. "3" (= binario 11) significa que las dos últimas encuestas fueron exitosas. "7" (= binario 111) significa que las tres últimas encuestas fueron exitosas. "17" ( = binario 1 111) significa que las últimas cuatro encuestas fueron exitosas. "15" (= binario 1 101) significa que las dos últimas encuestas fueron exitosas, que la encuesta anterior no fue exitosa y que la encuesta anterior fue exitosa.

• La columna delay muestra el retraso de ida y vuelta al peer remoto. Esto se determina midiendo el tiempo que transcurre entre la solicitud y la respuesta. 

• La columna offset es la desviación estimada entre el reloj de los servidores locales y el reloj de los servidores remotos. 

• La columna jitter hace referencia a la variabilidad del retraso entre las solicitudes de sondeo. Un valor de fluctuación alto limita la capacidad del servidor para sincronizar NTP con precisión.

Troubleshooting de NTP

Diagnósticos NTP CLI

Los comandos enumerados en los ejemplos se ejecutan desde la CLI de IM&P. Estos comandos proporcionan una manera sencilla de confirmar que el peer NTP cumple con los estándares de Cisco. 

Consejo: Los tres módulos de diagnóstico se ejecutan, junto con varios otros, cuando la prueba de diagnóstico utilsse utiliza el comando

El módulo de diagnóstico ntp_reachability realiza una prueba de ping a todos los peers NTP configurados. 

admin:utils diagnose module ntp_reachability

Log file: platform/log/diag2.log

Starting diagnostic test(s)
===========================
test - ntp_reachability : Passed

Diagnostics Completed

El módulo de diagnóstico ntp_clock_drift verifica que el desplazamiento de deriva del peer NTP no exceda 15000 milisegundos.

admin:utils diagnose module ntp_clock_drift

Log file: platform/log/diag3.log

Starting diagnostic test(s)
===========================
test - ntp_clock_drift : Passed

Diagnostics Completed

El módulo de diagnóstico ntp_stratum verifica el valor del estrato NTP en IM&P. Esta prueba se supera correctamente si el estrato NTP del publicador de CUCM tiene un valor de 5 o menos, ya que el publicador de CUCM es el origen NTP externo para IM&P. 

admin:utils diagnose module ntp_stratum

Log file: platform/log/diag4.log

Starting diagnostic test(s)
===========================
test - ntp_stratum : Passed

Diagnostics Completed

SUGERENCIA: Si el módulo ntp_stratum falla en su sistema, revise la sección Requisitos para el Origen NTP de este documento

Verificar comunicación y versión de NTP

NTP es un protocolo Cliente\Servidor que se comunica a través del Protocolo de datagramas de usuario (UDP) en el puerto 123. Para verificar la comunicación NTP y la versión de NTP, debe realizar una captura de paquetes (pcap) en el servidor IM&P. 

SUGERENCIA: Si ve que IM&P envía solicitudes NTP en el pcap; sin embargo, no hay respuestas NTP y un problema de red es posiblemente la causa. Recopile simultáneamente un pcap en el servidor CUCM y en el servidor IM&P para confirmar que las solicitudes enviadas desde IM&P se reciben en el lado CUCM. Confirme que CUCM también responde a las solicitudes.

Las capturas de paquetes muestran una respuesta del servidor NTP para cada solicitud del cliente NTP. El mensaje NTP Client\Server (Cliente/servidor NTP) muestra la versión de NTP en uso. Verifique que tanto la solicitud del cliente como la respuesta del servidor utilicen NTPv4. 

Ejecute el comando CLI utils network capture port 123 para crear una captura de paquetes en el puerto 123. Este comando es el mismo para IM&P o CUCM. 

CLI IM&P

admin:utils network capture port 123
Executing command with options:
 size=128 count=1000 interface=eth0
 src=dest= port=123
 ip=
09:44:43.106325 IP imppub.lab.local.46476 > cucmpub.lab.local.ntp: NTPv4, Client, length 48
09:44:43.109866 IP cucmpub.lab.local.ntp > imppub.lab.local.46476: NTPv4, Server, length 48
09:44:43.109931 IP imppub.lab.local.46476 > cucmpub.lab.local.ntp: NTPv4, Client, length 48
09:44:43.112815 IP cucmpub.lab.local.ntp > imppub.lab.local.46476: NTPv4, Server, length 48
09:44:43.112895 IP imppub.lab.local.46476 > cucmpub.lab.local.ntp: NTPv4, Client, length 48
09:44:43.113305 IP cucmpub.lab.local.ntp > imppub.lab.local.46476: NTPv4, Server, length 48
09:44:43.113361 IP imppub.lab.local.46476 > cucmpub.lab.local.ntp: NTPv4, Client, length 48
09:44:43.114157 IP cucmpub.lab.local.ntp > imppub.lab.local.46476: NTPv4, Server, length 48

CLI de CUCM Publisher

admin:utils network capture port 123
Executing command with options:
 size=128 count=1000 interface=eth0
 src=dest= port=123
 ip=
09:44:43.106744 IP imppub.lab.local.46476 > cucmpub.lab.local.ntp: NTPv4, Client, length 48
09:44:43.106872 IP cucmpub.lab.local.ntp > imppub.lab.local.46476: NTPv4, Server, length 48
09:44:43.109866 IP imppub.lab.local.46476 > cucmpub.lab.local.ntp: NTPv4, Client, length 48
09:44:43.109914 IP cucmpub.lab.local.ntp > imppub.lab.local.46476: NTPv4, Server, length 48
09:44:43.112637 IP imppub.lab.local.46476 > cucmpub.lab.local.ntp: NTPv4, Client, length 48
09:44:43.112719 IP cucmpub.lab.local.ntp > imppub.lab.local.46476: NTPv4, Server, length 48
09:44:43.113532 IP imppub.lab.local.46476 > cucmpub.lab.local.ntp: NTPv4, Client, length 48
09:44:43.113575 IP cucmpub.lab.local.ntp > imppub.lab.local.46476: NTPv4, Server, length 48