Introducción
Este documento describe cómo resolver problemas de protocolo de tiempo de la red (NTP) en productos Cisco Unified Communications (UC).
Prerequisites
Requirements
No hay requisitos específicos para este documento.
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
Cisco Unified Communications Manager (CUCM) requiere que se configure NTP para garantizar lo siguiente:
- La hora de los nodos de CUCM está sincronizada.
- La hora es correcta antes de cualquier cambio de configuración sensible al tiempo, 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 vigilante NTP para mantener la hora sincronizada con el servidor NTP. El NTP Watchdog sondea periódicamente los servidores NTP externos configurados y reinicia NTP si el tiempo se desplaza en más de tres segundos.
El demonio NTP corrige el tiempo regularmente, pero en una escala de tiempo de milisegundos. Un reinicio de NTP implica que ejecute un NTP one-shot para realizar una corrección de tiempo bruto y siga con un reinicio del demonio NTP para continuar con las micro-correcciones regulares.
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 del almacenamiento afectan negativamente al tiempo.
Un nodo principal que se ejecuta en VMware siempre debe configurarse para que se sincronice con los servidores NTP externos que se ejecutan en una máquina física para compensar el mayor grado de desviación o retraso del tiempo en una máquina virtual. Los nodos secundarios siempre se configuran automáticamente para hacer referencia al servidor NTP del nodo principal con el fin de garantizar que todos los nodos del clúster están cerca en el tiempo.
NTP Watchdog realiza un seguimiento de la velocidad a la que reinicia el demonio NTP para realizar correcciones de tiempo bruto debido a VMotions de VMWare y migraciones de almacenamiento. Si esta velocidad supera los 10 reinicios por hora, NTP Watchdog pospone los reinicios posteriores hasta que la velocidad necesaria de reinicios sea inferior a 10 por hora. La tasa combinada de migraciones de VMotions y almacenamiento no puede superar los 10 por hora, ya que esta tasa se considera excesiva.
Debido a esta implementación de NTP Watchdog, usted no sigue el intervalo de sondeo, que se ve en el estado utils ntp. Una captura de sabueso ha revelado 8 sondeos 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.
Identificar versión de NTP utilizada
Nota: El publicador de CUCM está configurado con un servidor NTP externo y el suscriptor agregado al clúster se sincroniza con el publicador.
Nota: CUCM versión 9.x y posteriores requieren que el servidor NTPv4 se configure como el servidor NTP preferido.
Ejecute una captura de sabueso para identificar la versión de 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, como respuesta, recibe un paquete NTPv3. Aunque NTPv4 es compatible con versiones anteriores de NTPv3, la implementación de CUCM de NTP varía, lo que da como resultado 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 Cisco IOS® o Cisco IOS® XE y asegúrese de que NTPv4 esté configurado.
Aquí hay una descripción de la terminología NTP en la salida de estado NTP:
- La columna refid indica la fuente de tiempo del mando a distancia. LOCAL(0) es el reloj de hardware local. .INIT. significa que la inicialización aún no se ha realizado correctamente.
- La columna st es el estrato del servidor NTP remoto. 16 es un valor de estrato no válido, lo que significa que este servidor no se considera un proveedor de tiempo. El estrato puede ser inválido por varias razones. El más común de los cuales es que el proveedor de hora no está sincronizado, el origen configurado no existe o el servidor ntp no se está ejecutando.
- La columna t indica el tipo de servidor (l: local; u: unicast; 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 control remoto se sondea cada 64 segundos. El intervalo más corto que utiliza NTP es cada 64 segundos y el más largo es de 1024 segundos. Cuanto mejor se califique un origen NTP a lo largo del tiempo, más largo será el intervalo. (La implementación de UC no sigue el intervalo definido aquí.)
- 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 correcta (binario 1) o incorrecta (binario 0). Por ejemplo, 1 significa que hasta ahora solo se ha realizado una encuesta y que ha sido exitosa. 3 (= binario 11) significa que las dos últimas encuestas fueron exitosas. 7 (= 111 binario) 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. La encuesta anterior no tuvo éxito y la anterior tuvo éxito.
- Las columnas de retardo, desplazamiento y fluctuación son el retardo de ida y vuelta, la dispersión y la fluctuación en milisegundos.
Diagnosticar problemas relacionados con NTP en CUCM
Complete estos pasos para diagnosticar los problemas relacionados con NTP:
- Asegúrese de que CUCM pueda comunicarse con el servidor NTP en el puerto 123.
- Obtenga la salida del estado de utils ntp.
- El nivel de estrato puede ser inferior a 4 en el editor para obtener un rendimiento óptimo.
- Si se configuran varios servidores NTP, asegúrese de que al menos un servidor es accesible; puede ver el símbolo (*) en el servidor NTP utilizado como referencia por CUCM.
- Revise la alarma de syslog y tome las medidas correspondientes. Las causas probables de las alarmas de syslog son:
- No se puede alcanzar el servidor NTP externo.
- El estrato NTP es superior al límite aceptable.
- El publicador está inactivo, por lo que el NTP del suscriptor no está sincronizado.
- Si se ven alertas relacionadas con ntpdate -q, es posible que tenga la versión 4.2.6+ de NTP con la función Kiss of Death (KoD) habilitada. (Por diseño, el intervalo mínimo entre los paquetes de ráfaga y de ráfaga enviados por cualquier cliente es de dos, lo que no infringe esta restricción. Los paquetes enviados por otras implementaciones que violan esta restricción se pueden descartar y se puede devolver un paquete KoD (si está habilitado). Se recomienda desactivar esta función cuando utilice esa versión como servidor NTP para un producto de UC.
- 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
- Ingrese utils ntp restart para reiniciar el cliente/servidor NTP. Este comando es útil siempre que se necesita una corrección de tiempo bruto inmediatamente o siempre que los servidores externos aún estén disponibles y en funcionamiento, pero la sincronización falle. 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 error de Cisco CSCue18813: parámetro maxdist de tos de configuración NTP controlado mediante CLI
Resolución: Se puede plantear el caso del Centro de Asistencia Técnica de Cisco para agregar manualmente el parámetro tos maxdist en el archivo ntp.conf.
ID de bug de Cisco CSCuq70611: La prueba de estrato de NTP no se valida correctamente con un único servidor NTP
Versión fija: 10.5(2.10000.005)
Cisco bug ID CSCui85967: la actualización de salto de CUCM de 6.1.5 a 9.1.2 falla debido a que falta la referencia NTP
Resolución: la documentación de la actualización de Jump se ha actualizado y la configuración de NTP aparece como una de las tareas previas a la actualización.
ID de bug de Cisco CSCtw46611: la sincronización NTP falla debido al 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 a M1
Resolución: deshabilite la sincronización NTP de la máquina virtual con el host ESXi con el uso de esta solución alternativa. Una solución alternativa es configurar el servidor ESXi y el publicador CUCM para que apunten al mismo servidor NTP.
Comentarios