Solução de problemas de NTP no Cisco Unified Communications Manager

Introduction

Este documento descreve como solucionar problemas do Network Time Protocol (NTP) em produtos Cisco Unified Communications Manager (CUCM) e Cisco Unified Communications (UC).

Informações de Apoio

O CUCM exige que o NTP seja configurado para garantir:

• O tempo nos nós do CUCM é sincronizado.
• O tempo está correto antes de qualquer alteração de configuração sensível ao tempo, como a regeneração de certificado.
• A replicação do banco de dados é sincronizada em todos os nós no cluster.

Mecanismo de pesquisa do NTP em produtos UC

O CUCM usa o vigilante NTP para manter o tempo sincronizado com o servidor NTP. O vigia do NTP pesquisa periodicamente o(s) servidor(es) NTP externo(s) configurado(s) e reinicia o NTP se o tempo for desviado por mais de três segundos.

O daemon NTP corrige o tempo regularmente, mas em uma escala de tempo de milissegundo. Uma reinicialização do NTP envolve a execução de uma única tentativa de NTP para executar uma correção de tempo bruto e seguir com uma reinicialização do daemon NTP para microcorreções regulares contínuas.

O vigilante do NTP pesquisa o NTP uma vez por minuto no VMware e uma vez a cada 30 minutos em máquinas físicas. O intervalo de sondagem é mais curto para o VMware porque o relógio em máquinas virtuais (VMs) é menos estável do que em máquinas físicas e recursos do VMware, como o VMotion, a migração do armazenamento afeta negativamente o tempo.

Um nó primário que é executado no VMware deve sempre ser configurado para sincronizar com servidores NTP externos executados em máquinas físicas para compensar o maior grau de desvio de tempo ou atraso em uma VM. Os nós secundários são sempre configurados automaticamente para referenciar o servidor NTP do nó primário para garantir que todos os nós dentro do cluster estejam próximos no tempo.

O vigilante NTP controla a taxa na qual ele reinicia o daemon NTP para correções de tempo bruto devido a VMotions VMWare e Migrações de Armazenamento. Se essa taxa exceder 10 reinicializações por hora, o vigia NTP adiará novas reinicializações até que a taxa necessária de reinicializações caiba abaixo de 10 por hora. A taxa combinada de migrações de VMotions e armazenamento não deve exceder 10 por hora, pois essa taxa é considerada excessiva.

Devido a esta implementação do vigia do NTP, você não segue o intervalo de sondagem, que é visto no status do ntp do utilitário. Uma captura de farejador revelou 8 pesquisas NTP (amostra) a cada 60 segundos. Isso ocorre principalmente porque a implementação do NTP usa o vigilante do NTP e como o ntpdate pesquisa o servidor NTP na Implementação do UC.

Identificar a versão do NTP usada

Note: O Editor do CUCM é configurado com um servidor NTP externo e o assinante adicionado ao cluster sincroniza com o Editor.

Note: O CUCM Versão 9.x e posterior exigem que o servidor NTPv4 seja configurado como o servidor NTP preferencial.

Execute uma captura de farejador para identificar a versão NTP usada pelo 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

O CUCM envia um pacote NTPv4 e, em resposta, você recebe um pacote NTPv3. Embora o NTPv4 seja retrocompatível com o NTPv3, a implementação do CUCM do NTP varia, o que resulta em NTP não 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 corrigir o problema, a Cisco recomenda que você use um servidor NTP externo baseado em Linux ou um servidor NTP baseado em Cisco IOS^® ou IOS XE e assegure-se de que o NTPv4 esteja configurado.

Aqui está uma descrição da terminologia NTP na saída de status do NTP:

• A coluna refid indica a origem de hora do remoto. LOCAL(0) é o relógio de hardware local. .INIT. significa que a inicialização ainda não foi bem-sucedida.
  
  
• A primeira coluna é o estrato do servidor NTP remoto. 16 é um valor de stratum inválido que significa que "este servidor não é considerado um provedor de tempo". O stratum pode ser inválido por vários motivos, sendo o mais comum que o "provedor de tempo não sincronizado", o "origem configurada não existe" ou o "servidor ntp não está em execução".
  
  
• A coluna t indica o tipo de servidor (l: local; u: unicast; m: multicast, ou b: broadcast).
  
  
• A coluna quando indica quantos segundos atrás o controle remoto foi consultado.
  
  
• A coluna de pesquisa indica o intervalo de sondagem em segundos. Por exemplo, "64" significa que o controle remoto é interrogado a cada 64 segundos. O intervalo mais curto que o NTP usa é a cada 64 segundos e o mais longo é 1.024 segundos. Quanto melhor uma origem NTP for classificada ao longo do tempo, maior será o intervalo. (A implementação de UC não segue o intervalo definido aqui.)
  
  
• A coluna reach indica a tendência dos testes de acessibilidade em octal, em que cada dígito, quando convertido em binário, representa se uma pesquisa específica foi bem-sucedida (binário 1) ou malsucedida (binário 0). Por exemplo, "1" significa que apenas uma pesquisa foi feita até agora e foi bem-sucedida. "3" (= binário 11) significa que as duas últimas pesquisas foram bem-sucedidas. "7" (= binário 111) significa que as três últimas pesquisas foram bem-sucedidas. "17" ( = binário 1 111) significa que as quatro últimas pesquisas foram bem-sucedidas. "15" (= binário 1 101) significa que as duas últimas pesquisas foram bem-sucedidas, a pesquisa anterior não foi bem-sucedida e a pesquisa anterior foi bem-sucedida.
  
  
• As colunas delay, offset e jitter são o atraso de ida e volta, a dispersão e o jitter em milissegundos.

Diagnosticar problemas relacionados ao NTP no CUCM

Conclua estes passos para diagnosticar problemas relacionados ao NTP:

1. Verifique se o CUCM pode se comunicar com o servidor NTP na porta 123.
   
   
2. Obtenha a saída do status ntp do utils.
   
   
   • O nível de stratum deve ser inferior a 4 no editor para obter o desempenho ideal
   • Se vários servidores NTP estiverem configurados, certifique-se de que pelo menos um servidor esteja acessível; você deve ver o símbolo (*) no servidor NTP usado como referência pelo CUCM.
   
   
   
3. Revise o alarme do syslog e tome as medidas adequadas. As causas prováveis dos alarmes de syslog são:
   
   
   • O servidor NTP externo não está acessível.
   • O estrato NTP é superior ao limite aceitável.
   • O Publisher está inoperante, portanto, o NTP do assinante não está sincronizado.
   • Se forem vistos alertas relacionados ao ntpdate -q, é possível que você tenha o NTP versão 4.2.6+ com o recurso Kiss of Death (KoD) ativado. (Por design, o intervalo mínimo entre os pacotes de burst e iburst enviados por qualquer cliente é dois, o que não viola essa restrição. Pacotes enviados por outras implementações que violam essa restrição serão descartados e um pacote KoD será retornado, se ativado). Recomenda-se desativar esse recurso quando você usar essa versão como o servidor NTP para um produto UC.
   
   
   
4. Use este módulo de diagnóstico para verificar se o servidor NTP está configurado.
   • utils diagnose module ntp_reachability
   • utils diagnose module ntp_clock_drift
   • utils diagnose module ntp_stratum
   
   
   
5. Insira utils ntp restart para reiniciar o cliente/servidor NTP. Esse comando é útil sempre que uma correção de tempo bruto precisa ocorrer imediatamente ou sempre que os servidores externos ainda estão acessíveis e operacionais, mas a sincronização falha. Use o comando utils ntp status para determinar o status operacional dos servidores NTP externos.

Problemas conhecidos comuns com a associação NTP no CUCM

ID de bug da Cisco CSCue18813: Parâmetro "tos maxdist" de configuração de NTP controlado via CLI

Resolução: O caso do Cisco Technical Assistance Center deve ser gerado para adicionar manualmente o parâmetro tos maxdist no arquivo ntp.conf.

ID de bug da Cisco CSCuq70611: O teste do NTP Stratum não é validado corretamente com um único servidor NTP

Versão Fixa: 10,5 (2,10000,005)

ID de bug da Cisco CSCui85967: Falha na atualização do salto do CUCM de 6.1.5 para 9.1.2 devido à falta de referência do NTP

Resolução: A documentação de atualização de salto foi atualizada e a configuração do NTP está listada como uma das tarefas de pré-atualização.

ID de bug da Cisco CSCtw46611:  Falha na sincronização do NTP devido à etiquetagem incorreta do sistema de arquivos de capture.txt

Versão Fixa: 8.6(2.24900.017)

ID de bug da Cisco CSCur94973: Problema de sincronização de tempo entre VMHost e Instância de VM durante a migração M1

Resolução: Desative a sincronização NTP da VM com o host ESXi com o uso dessa solução alternativa. Uma solução alternativa é configurar o servidor ESXi e o Editor do CUCM para apontar para o mesmo servidor NTP.