Voz y Comunicaciones unificadas : Cisco Unified Communications Manager (CallManager)

Troubleshooting NTP en el administrador de las Comunicaciones unificadas de Cisco

18 Octubre 2015 - Traducción Automática
Otras Versiones: PDFpdf | Inglés (22 Agosto 2015) | Comentarios

Introducción

Este documento describe cómo resolver problemas los problemas del Network Time Protocol (NTP) en los Productos del administrador de las Comunicaciones unificadas de Cisco (CUCM) y de las Comunicaciones unificadas de Cisco (UC).

Contribuido por Vasanth Kumar K, ingeniero de Cisco TAC.

Antecedentes

CUCM requiere que el NTP esté configurado para asegurar:

  • El tiempo en los Nodos CUCM se sincroniza.
  • El tiempo está correcto antes de cualquier cambio de configuración sensible al tiempo tal como regeneración del certificado.
  • La réplica de base de datos se sincroniza en todos los Nodos en el cluster.

Mecanismo de sondeo NTP en Productos UC

CUCM utiliza el perro guardián NTP para mantener el tiempo sincronizado con el servidor NTP. El perro guardián NTP sondea los servidores externos configurados NTP y recomienza periódicamente el NTP si la hora se compensa por más de tres segundos.

La daemon NTP corrige regularmente el tiempo, pero en una línea de tiempo del milisegundo. Un reinicio del NTP implica que usted ejecuta un NTP paso a paso para realizar una corrección de tiempo gruesa y seguir con un reinicio de la daemon NTP para las micro-correcciones regulares continuas.

El perro guardián NTP sondea el NTP una vez al minuto en VMware y una vez cada 30 minutos en las máquinas físicas. El intervalo de sondeo es más corto para VMware porque el reloj en las máquinas virtuales (VM) es menos estable que en las máquinas y las características físicas de VMware tales como VMotion, migración del almacenamiento afecta al contrario al tiempo.

Un Nodo primario que se ejecuta en VMware se debe configurar siempre para sincronizar con los servidores NTP externos que se ejecutan en las máquinas físicas para compensar el grado más alto de deriva del tiempo o para retrasar en un VM. Los Nodos secundarios siempre se configuran automáticamente para referirse al servidor NTP del Nodo primario para asegurarse de que todos los Nodos dentro del cluster están cercanos a tiempo.

El perro guardián NTP no pierde de vista la tarifa en la cual recomienza la daemon NTP para las correcciones de tiempo gruesas debido a VMware VMotions y a las migraciones del almacenamiento. Si esta tarifa excede 10 reinicios por la hora, el perro guardián NTP pospone otros reinicios hasta que el índice requerido de reinicios baje debajo de 10 por la hora. El índice combinado de VMotions y de migraciones del almacenamiento no debe exceder de 10 por la hora, porque esta tarifa se considera excesiva.

Debido a esta implementación del perro guardián NTP, usted no sigue el intervalo de encuesta, que se considera en el estatus NTP del utils. Una captura del sniffer ha revelado 8 encuestas NTP (muestra) cada 60 segundos. Esto es sobre todo porque la implementación NTP utiliza el perro guardián NTP y cómo el ntpdate sondea el servidor NTP en la implementación UC.

Identifique la versión NTP usada

Nota: CUCM Publisher se configura con un servidor NTP externo y el suscriptor agregado al cluster sincroniza a Publisher.

Nota: La versión 9.x y posterior CUCM requiere que el servidor NTPv4 esté configurado como el servidor NTP preferido.

Ejecute una captura del sniffer para identificar la versión NTP usada 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 la respuesta usted recibe un paquete NTPv3. Aunque NTPv4 sea compatible con versiones anteriores a NTPv3, la implementación CUCM del NTP varía, que da lugar al NTP unsynchronized:

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 reparar el problema, Cisco le recomienda utiliza un servidor NTP externo o un ® Linux-basado del Cisco IOS o un servidor NTP XE-basado IOS y se asegura de que NTPv4 está configurado.

Aquí está una descripción de la terminología NTP en el estado NTP hecho salir:

  • La columna del refid indica la fuente horaria del telecontrol. LOCAL(0) es el reloj del hardware local. .INIT significa que la inicialización todavía no ha tenido éxito.

  • La columna st es el estrato del servidor NTP remoto. 16 es un valor inválido del estrato que significa que “este servidor no está considerado un proveedor del tiempo”. El estrato puede ser inválido por las diversas razones, el más común cuyo es que no existe el “proveedor del tiempo no sincronizado”, la “fuente configurada”, o el “servidor NTP que no se ejecuta”.

  • La columna t indica el tipo de servidor (l: local; u: unicast; m: Multicast, o b: broadcast).

  • Cuando la columna indica hace cuántos segundos fue preguntado el telecontrol.

  • La columna de la encuesta indica el intervalo de sondeo en los segundos. Por ejemplo, el "64" significa que el telecontrol está sondeado cada 64 segundos. Las aplicaciones más cortas del intervalo NTP son cada 64 segundos y el más largo es 1,024 segundos. Cuanto mejor una fuente NTP se valora en un cierto plazo, más largo es el intervalo. (La implementación UC no sigue el intervalo definido aquí.)

  • La columna del alcance indica la tendencia de las pruebas del accesibilidad en octal, donde cada dígito, cuando está convertido al binario, representa si una encuesta determinada era acertada (el binario 1) o fracasado (binario 0). Por ejemplo, el "1" significa que solamente una encuesta se ha hecho hasta el momento y era acertada. el "3" (= binario 11) significa que las dos encuestas más recientes eran acertadas. el "7" (= binario 111) significa que las tres encuestas más recientes eran acertadas. el "17" (= binario 1 111) significa que las cuatro encuestas más recientes eran acertadas. el "15" (= binario 1 101) significa que las dos encuestas más recientes eran acertadas, la encuesta antes de ésa era fracasada, y la encuesta antes de ésa era acertada.

  • El retardo, el desplazamiento, y las columnas del jitter son el retardo de ida y vuelta, la dispersión, y el jitter en los milisegundos.

Diagnostique los problemas NTP-relacionados en CUCM

Complete estos pasos para diagnosticar los problemas NTP-relacionados:

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

  2. Obtenga la salida del estatus NTP del utils.

    • El Nivel de estrato debe ser menos de 4 en el editor para el rendimiento óptimo
    • Si se configuran los servidores NTP múltiples, asegure por lo menos en el servidor es accesible; usted debe ver (*) el símbolo contra el servidor NTP usado como referencia por CUCM.


  3. Revise la alarma del Syslog y tome medidas por consiguiente. Las causas probables de las alarmas del Syslog son:

    • El servidor NTP externo no es accesible.
    • El estrato NTP es más alto que el límite aceptable.
    • Publisher está abajo, así que el suscriptor NTP es unsynchronized.
    • Si ntpdate - se consideran las alertas relacionadas q, él son posibles que usted tiene versión 4.2.6+ NTP con la característica del golpe de gracia (KoD) habilitada. (Por el diseño, el intervalo mínimo entre la explosión y los paquetes del iburst enviados por cualquier cliente es dos, que no viole este obstáculo. Paquetes enviados por otras implementaciones que violan este obstáculo serán caídas y un paquete de KoD vuelto, si es habilitado). Se recomienda para inhabilitar esta característica cuando usted utiliza esa versión como el servidor NTP para un producto UC.


  4. Utilice este módulo de la diagnosis para verificar el servidor NTP se configura.

    • el utils diagnostica el ntp_reachability del módulo
    • el utils diagnostica el ntp_clock_drift del módulo
    • el utils diagnostica el ntp_stratum del módulo


  5. Ingrese el reinicio NTP del utils para recomenzar el cliente NTP/el servidor. Este comando es útil siempre que una corrección de tiempo gruesa necesite ocurrir inmediatamente o siempre que los servidores externos son todavía accesibles y operativos, pero la sincronización falla. Utilice el comando status NTP del utils para determinar el estado operacional de servidores NTP externos.

Problemas conocidos comunes con la asociación NTP en CUCM

Id. de bug Cisco CSCue18813: Configuración del NTP “parámetro del maxdist TOS” controlado vía el CLI

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

Id. de bug Cisco CSCuq70611: La prueba del estrato NTP no valida correctamente con el solo servidor NTP

Versión corregida: 10.5(2.10000.005)

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

Resolución: Se ha puesto al día la documentación de la actualización del salto y la configuración del NTP se enumera como encendido de la tarea previa a la actualización.

Id. de bug Cisco CSCtw46611:  El synch NTP falla debido al etiquetado incorrecto del sistema de archivos de capture.txt

Versión corregida: 8.6(2.24900.017)

Id. de bug Cisco CSCur94973: Betn VMHost del problema de la sincronización horaria y caso VM durante la migración M1

Resolución: Inhabilite la sincronización NTP VM con el host de ESXi con el uso de esta solución alternativa. Un método alternativo es configurar el servidor y el CUCM Publisher de ESXi para señalar al mismo servidor NTP. 


Discusiones relacionadas de la comunidad de soporte de Cisco

La Comunidad de Soporte de Cisco es un foro donde usted puede preguntar y responder, ofrecer sugerencias y colaborar con colegas.


Document ID: 118718