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:
- Verifique se o CUCM pode se comunicar com o servidor NTP na porta 123.
- 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.
- 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.
- 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
- 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.