Contenido

Introducción

Antecedentes

Mecanismo de sondeo NTP en productos de UC

Identificación de la versión de NTP utilizada

Diagnóstico de problemas relacionados con NTP en CUCM

Problemas conocidos comunes con la asociación NTP en CUCM

Introducción

Este documento describe cómo resolver problemas de protocolo de tiempo de red (NTP) en productos Cisco Unified Communications Manager (CUCM) y Cisco Unified Communications (UC).

Antecedentes

CUCM requiere que NTP se configure para garantizar:

- El tiempo en los nodos CUCM se sincroniza.

- El tiempo es correcto antes de cualquier cambio de configuración urgente, como la regeneración de certificados.

- La replicación de la base de datos se sincroniza en todos los nodos del clúster.

Mecanismo de sondeo NTP en productos de UC

CUCM utiliza el control NTP para mantener el tiempo sincronizado con el servidor NTP. NTP Watchdog sondea periódicamente los servidores NTP externos configurados y reinicia NTP si el tiempo se compensa en más de tres segundos.

El daemon NTP corrige el tiempo regularmente, pero en una escala de tiempo de milisegundos. Un reinicio de NTP implica que usted ejecute un NTP one-shot para realizar una corrección de tiempo bruto y seguir con un reinicio del daemon NTP para micro-correcciones regulares continuas.

NTP Watchdog sondea NTP una vez por minuto en VMware y una vez cada 30 minutos en máquinas físicas. El intervalo de sondeo es más corto para VMware porque el reloj de las máquinas virtuales (VM) es menos estable que en las máquinas físicas y las funciones de VMware, como VMotion y la migración de almacenamiento, afectan negativamente al tiempo.

Un nodo primario que se ejecuta en VMware siempre debe configurarse para sincronizarse con servidores NTP externos que se ejecutan en máquinas físicas para compensar el mayor grado de desfase o retraso en el tiempo en una VM. Los nodos secundarios siempre se configuran automáticamente para hacer referencia al servidor NTP del nodo primario a fin de asegurarse de que todos los nodos dentro del clúster se cierren en el tiempo.

NTP Watchdog realiza un seguimiento de la velocidad a la que reinicia el daemon NTP para las correcciones de tiempo bruto debidas a VMotions de VMWare y migraciones de almacenamiento. Si esta velocidad excede los 10 reinicios por hora, NTP Watchdog pospone más reinicios hasta que la tasa de reinicios requerida caiga por debajo de los 10 por hora. La velocidad combinada de las migraciones de almacenamiento y VMotions no debe superar los 10 por hora, ya que esta tasa se considera excesiva.

Debido a esta implementación de NTP Watchdog, no sigue el intervalo de sondeo, que se ve en el estado de utils ntp. Una captura de sabueso ha revelado 8 encuestas NTP (muestra) cada 60 segundos. Esto se debe principalmente a que la implementación de NTP utiliza NTP Watchdog y a cómo ntpdate sondea el servidor NTP en la implementación de UC.

Identificación de la versión de NTP utilizada

Nota: CUCM Publisher se configura con un servidor NTP externo y el suscriptor agregado al clúster se sincroniza con el editor.

Nota: CUCM versión 9.x y posteriores requieren que el servidor NTPv4 se configure como el servidor NTP preferido.

Ejecute una captura del sniffer para identificar la versión NTP utilizada por el servidor NTP configurado:

admin:utils network capture port 123

Executing command with options:

size=128         count=1000             interface=eth0

src=dest=                  port=123

ip=

16:03:03.689725 IP cucmlab.cisco.local.34063 > linux.local.ntp: NTPv4,Client, length 48

16:03:03.690174 IP linux.local.ntp > cucmlab.cisco.local.34063: NTPv3,Server, length 48

CUCM envía un paquete NTPv4 y, en respuesta, recibe un paquete NTPv3. Aunque NTPv4 es compatible con NTPv3, la implementación de NTP por parte de CUCM varía, lo que da lugar a NTP no sincronizado:

admin:utils ntp status

ntpd (pid 22458) is running...

remote      refid     st t when poll reach   delay   offset jitter

=================================================================

172.28.5.9   .INIT.     2 u   45   64 377   0.374 492.965 18.189

unsynchronised

time server re-starting

polling server every 64 s

Para solucionar el problema, Cisco recomienda que utilice un servidor NTP externo basado en Linux o un servidor NTP basado en Cisco IOS® o IOS XE y asegúrese de que NTPv4 esté configurado.

A continuación se describe la terminología NTP en el resultado del estado NTP:

- La columna refid indica el origen de la hora del mando a distancia. LOCAL(0) es el reloj de hardware local. .INIT. significa que la inicialización todavía no se ha realizado correctamente.

- La st columna es el estrato del servidor NTP remoto. 16 es un valor de estrato no válido que significa "este servidor no se considera un proveedor de tiempo". El estrato puede no ser válido por varias razones, la más común es que el "proveedor de tiempo no sincronizado", el "origen configurado no existe" o el "servidor ntp no en ejecución".

- La columna t indica el tipo de servidor (l: local; u: unidifusión; m: multicast, o b: broadcast).

- La columna when indica cuántos segundos atrás se consultó el mando a distancia.

- La columna de sondeo indica el intervalo de sondeo en segundos. Por ejemplo, "64" significa que el mando a distancia se sondea cada 64 segundos. El intervalo más corto que utiliza NTP es cada 64 segundos y el más largo es 1024 segundos. Cuanto mejor se califique un origen NTP con el tiempo, mayor será el intervalo. (La implementación de UC no sigue el intervalo definido aquí.)

- La columna alcance indica la tendencia de las pruebas de alcance en octal, donde cada dígito, cuando se convierte en binario, representa si un sondeo determinado fue exitoso (binario 1) o no exitoso (binario 0). Por ejemplo, "1" significa que sólo se ha hecho una encuesta hasta ahora y tuvo éxito. "3" (= binario 11) significa que las últimas dos encuestas fueron exitosas. "7" (= binario 111) significa que las últimas tres encuestas fueron exitosas. "17" ( = binario 1 111) significa que las últimas cuatro encuestas fueron exitosas. "15" (= binario 1 101) significa que las últimas dos encuestas fueron exitosas, la encuesta anterior a eso no tuvo éxito y la encuesta anterior fue exitosa.

- Las columnas retardo, desplazamiento y fluctuación son el retardo de ida y vuelta, la dispersión y la fluctuación en milisegundos.

Diagnóstico de problemas relacionados con NTP en CUCM

Complete estos pasos para diagnosticar los problemas relacionados con NTP:

1. Asegúrese de que CUCM pueda comunicarse con el servidor NTP en el puerto 123.

2. Obtenga el resultado del estado de utils ntp.

- El nivel de Estrato debe ser inferior a 4 en el editor para obtener un rendimiento óptimo

- Si se configuran varios servidores NTP, asegúrese de que se pueda alcanzar al menos en el servidor; debe ver el símbolo (*) frente al servidor NTP utilizado como referencia por CUCM.

3. Revise la alarma de syslog y realice las acciones correspondientes. Las causas probables de las alarmas syslog son:

- No se puede alcanzar el servidor NTP externo.

- El estrato NTP es superior al límite aceptable.

- Publisher no funciona, por lo que el NTP del suscriptor no está sincronizado.

- Si se ven alertas relacionadas con ntpdate-q, es posible que tenga NTP versión 4.2.6+ con la función Beso de muerte (KoD) activada. (Por diseño, el intervalo mínimo entre los paquetes de ráfaga y ráfaga enviados por cualquier cliente es de dos, lo que no viola esta restricción. Los paquetes enviados por otras implementaciones que violan esta restricción se descartarán y se devolverá un paquete KoD, si está habilitado). Se recomienda desactivar esta función cuando se utiliza esa versión como servidor NTP para un producto UC.

4. Utilice este módulo de diagnóstico para verificar que el servidor NTP esté configurado.

- utils diagnose module ntp_reachability

- utils diagnose module ntp_clock_drift

- utils diagnose module ntp_stratum

5. Ingrese utils ntp restart para reiniciar el cliente/servidor NTP. Este comando es útil cuando se necesita realizar una corrección de tiempo bruto inmediatamente o cuando los servidores externos todavía son accesibles y están operativos, pero la sincronización falla. Utilice el comando utils ntp status para determinar el estado operativo de los servidores NTP externos.

Problemas conocidos comunes con la asociación NTP en CUCM

Id. de bug Cisco CSCue18813: Parámetro de configuración NTP "tos maxdist" controlado mediante CLI

Resolución: El caso del Centro de asistencia técnica de Cisco se debe plantear para agregar manualmente el parámetro tos maxdist en el archivo ntp.conf.

Id. de bug Cisco CSCuq70611: La prueba de Estrato NTP no se valida correctamente con un único servidor NTP

Versión fija: 10.5(2.1000.005)

Id. de bug Cisco CSCui85967: La actualización de salto de CUCM de 6.1.5 a 9.1.2 falla debido a la falta de referencia de NTP

Resolución: Se ha actualizado la documentación de actualización de saltos y la configuración de NTP aparece como una de las tareas previas a la actualización.

Id. de bug Cisco CSCtw46611:  La sincronización NTP falla debido a un etiquetado incorrecto del sistema de archivos de capture.txt

Versión fija: 8.6(2.24900.017)

Id. de error de Cisco CSCur94973: problema de sincronización horaria entre VMHost e instancia de VM durante la migración M1

Resolución: Inhabilite la sincronización NTP de la máquina virtual con el host ESXi con el uso de esta solución alternativa . Otra solución alternativa es configurar el servidor ESXi y CUCM Publisher para que apunten al mismo servidor NTP.