Introdução
Este documento descreve como solucionar problemas do Network Time Protocol (NTP) em produtos Cisco Unified Communications (UC).
Pré-requisitos
Requisitos
Não existem requisitos específicos para este documento.
Componentes Utilizados
Este documento não se restringe a versões de software e hardware específicas.
As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se a rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando.
Informações de Apoio
O Cisco Unified Communications Manager (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 está sincronizada em todos os nós do cluster.
Mecanismo de pesquisa NTP em produtos UC
O CUCM usa o watchdog do NTP para manter a hora sincronizada com o servidor NTP. O Watchdog do NTP pesquisa periodicamente servidores NTP externos configurados e reinicia o NTP se o tempo for deslocado em mais de três segundos.
O daemon NTP corrige o tempo regularmente, mas em uma escala de tempo de milissegundos. A reinicialização do NTP envolve a execução de um NTP one-shot para executar uma correção bruta de tempo e seguir com uma reinicialização do daemon NTP para microcorreções regulares contínuas.
O NTP Watchdog pesquisa o NTP uma vez por minuto no VMware e uma vez a cada 30 minutos em máquinas físicas. O intervalo de pesquisa é menor para o VMware porque o relógio nas máquinas virtuais (VMs) é menos estável do que nas máquinas físicas, e os recursos do VMware, como VMotion e Migração de armazenamento, afetam o tempo de forma adversa.
Um nó primário que é executado no VMware deve sempre ser configurado para sincronizar com servidores NTP externos que são executados em uma ou mais 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 a fim de garantir que todos os nós dentro do cluster estejam próximos a tempo.
O NTP Watchdog controla a taxa na qual reinicia o daemon NTP para correções de tempo bruto devido a VMotions e Migrações de armazenamento do VMWare. Se essa taxa exceder 10 reinicializações por hora, o NTP Watchdog adiará reinicializações adicionais até que a taxa necessária de reinicializações caia abaixo de 10 por hora. A taxa combinada de VMotions e Migrações de armazenamento não pode exceder 10 por hora, pois essa taxa é considerada excessiva.
Devido a essa implementação do Watchdog do NTP, você não segue o intervalo de pesquisa, que é visto no status ntp do utils. Uma captura do farejador revelou 8 enquetes de NTP (exemplo) a cada 60 segundos. Isso ocorre principalmente porque a implementação de NTP usa o NTP Watchdog e como o ntpdate pesquisa o servidor NTP na Implementação de UC.
Identificar a versão do NTP usada
Observação: o Editor do CUCM está configurado com um servidor NTP externo, e o assinante adicionado ao cluster sincroniza com o Publicador.
Observação: o CUCM versão 9.x e posterior requer que o servidor NTPv4 seja configurado como o servidor NTP preferencial.
Execute uma captura de farejador para identificar a versão do 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 compatível com NTPv3, a implementação 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 Cisco IOS® ou Cisco IOS® XE e verifique se o NTPv4 está configurado.
Esta é uma descrição da terminologia NTP na saída do status NTP:
- A coluna refid indica a origem de tempo 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 é a camada do servidor NTP remoto. 16 é um valor de stratum inválido, o que significa que esse servidor não é considerado um provedor de tempo. O stratum pode ser inválido por vários motivos. O mais comum deles é que o provedor de tempo não está sincronizado, a fonte 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 há quantos segundos o controle remoto foi consultado.
- A coluna de pesquisa indica o intervalo de pesquisa em segundos. Por exemplo, 64 significa que o controle remoto é interrogado a cada 64 segundos. O menor intervalo que o NTP usa é a cada 64 segundos e o maior é 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 alcançabilidade em octal, onde cada dígito, quando convertido em binário, representa se uma determinada pesquisa foi bem-sucedida (binário 1) ou malsucedida (binário 0). Por exemplo, 1 significa que apenas uma pesquisa foi realizada até o momento e foi bem-sucedida. 3 (= binário 11) significa que as duas últimas sondagens foram bem-sucedidas. 7 (= binário 111) significa que as últimas três votações foram bem-sucedidas. 17 ( = binário 1 111) significa que as últimas quatro votações foram bem-sucedidas. 15 (= binário 1 101) significa que as duas últimas pesquisas foram bem-sucedidas. A pesquisa anterior não teve êxito e a anterior foi bem-sucedida.
- As colunas de atraso, deslocamento e variação são o atraso de ida e volta, a dispersão e a variação em milissegundos.
Diagnosticar problemas relacionados ao NTP no CUCM
Conclua estas etapas 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 do utils ntp.
- O nível de estrato pode ser menor que 4 no editor para desempenho ideal.
- Se vários servidores NTP estiverem configurados, certifique-se de que pelo menos um servidor esteja acessível; você pode ver o símbolo (*) no servidor NTP usado como referência pelo CUCM.
- Revise o alarme de syslog e aja de acordo. As causas prováveis dos alarmes de syslog são:
- O servidor NTP externo não está acessível.
- O stratum do NTP é superior ao limite aceitável.
- O editor está inoperante, portanto o NTP do Assinante está dessincronizado.
- Se alertas relacionados a ntpdate -q forem vistos, é possível que você tenha a versão 4.2.6+ do NTP com o recurso Kiss of Death (KoD) habilitado. (Por padrão, o intervalo mínimo entre os pacotes de intermitência e de intermitência enviados por qualquer cliente é de dois, o que não viola essa restrição. Os pacotes enviados por outras implementações que violam esta restrição podem ser descartados e um pacote KoD pode ser devolvido (se habilitado). É recomendável desabilitar esse recurso ao usar essa versão como o servidor NTP para um produto de UC.
- Use este módulo de diagnóstico para verificar se o servidor NTP está configurado.
- utils diagnosticam o módulo ntp_reachability
- utils diagnosticam o módulo 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 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 de servidores NTP externos.
Problemas conhecidos comuns com a associação NTP no CUCM
ID de bug Cisco CSCue18813: parâmetro de configuração NTP tos maxdist controlado via CLI
Resolução: o caso do Cisco Technical Assistance Center pode ser levantado para adicionar manualmente o parâmetro tos maxdist no arquivo ntp.conf.
ID do Cisco Bug CSCuq70611: O teste 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 de salto do CUCM de 6.1.5 para 9.1.2 devido à ausência da referência NTP
Resolução: a documentação de atualização do salto foi atualizada e a configuração NTP é listada como uma das tarefas de pré-atualização.
ID de bug da Cisco CSCtw46611: Falha na sincronização de NTP devido à rotulação incorreta do sistema de arquivos de capture.txt
Versão fixa: 8.6(2.24900.017)
ID de bug Cisco CSCur94973: Problema de sincronização de tempo entre VMHost e VM Instance 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.
Feedback