Introduction
Este documento descreve como solucionar problemas de sincronização de Network Time Protocol (NTP) em IM e Presence (IM&P).
Prerequisites
A Cisco recomenda que você tenha uma compreensão básica do NTP e da interface de linha de comando (CLI) do IM&P antes de revisar este documento.
Requirements
Não há requisitos específicos de hardware ou software para este documento.
Componentes Utilizados
As informações neste documento são baseadas em IM&P.
Observação: grande parte dessas informações também se aplica a outras plataformas de comunicações unificadas (UC); no entanto, o foco deste documento é IM&P.
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Se a rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando.
NTP em IM&P explicado
O editor do Cisco Unified Communications Manager (CUCM) é a fonte de NTP para IM&P. O IM&P usa o watchdog do NTP para manter a hora sincronizada com o Editor do CUCM. Para plataformas IM&P que estão em uma máquina virtual, o NTP Watchdog sonda o CUCM Publisher uma vez a cada 64 segundos por padrão. Se o deslocamento do NTP for superior a três segundos, o daemon do NTP reinicia-se.
Observação: o NTP Watchdog monitora quantas vezes o daemon NTP foi reiniciado na última hora. Se mais de 10 reinicializações do daemon NTP ocorrerem em uma hora, outras reinicializações serão brevemente adiadas.
Requisitos para origem NTP
A Cisco recomenda altamente o uso de um servidor NTP Stratum 1, Stratum 2 ou Stratum 3 como referência de NTP externo do Editor do CUCM. Qualquer origem de NTP para o editor do CUCM DEVE NÃO ser superior ao stratum 4.
Os servidores NTP externos definidos para o nó do editor do CUCM DEVEM ser NTP v4 para evitar possíveis problemas de compatibilidade, precisão e instabilidade da rede. O NTP versão 4 é compatível com a versão 3; no entanto, foram observados muitos problemas com tentativas de usar versões diferentes do NTP.
Aviso: não há suporte para o uso do Windows Time Services como um servidor NTP. Frequentemente, os Serviços de Tempo do Windows usam o SNTP (Simple Network Time Protocol) e o CUCM não pode sincronizar com êxito com o SNTP.
Observação: todos os requisitos de NTP são claramente observados no SRND do Cisco Collaboration System.
Explicação de saída do status do NTP
Para determinar o status atual do NTP em IM&P, execute o comando utils ntp status na CLI do servidor IM&P.
admin:utils ntp status
ntpd (pid 28589) is running...
remote refid st t when poll reach delay offset jitter
==============================================================================
10.0.0.1 192.0.2.0 2 u 40 64 1 0.292 0.041 0.000
synchronised to NTP server (10.0.0.1) at stratum 3
time server re-starting
poll server every 64 s
Current time in UTC is : Fri Sep 16 19:41:55 UTC 2016
Current time in America/New_York is : Fri Sep 16 15:41:55 EDT 2016
Estas são descrições das colunas vistas na saída de status do NTP
- A coluna remote define o peer remoto onde o tempo é sincronizado. Se definido como LOCAL, o relógio de hardware local está em uso.
- A coluna refid define a origem de tempo do servidor remoto. Se definido como .LOCL, o relógio de hardware local no servidor remoto é referenciado. Se definido como .INIT, a inicialização ainda não foi bem-sucedida.
- A primeira coluna denota o stratum do peer NTP remoto. Quando um valor de 16 está na coluna de estrato, isso significa que o sistema usa o relógio interno em vez da origem NTP externa. Um sistema que usa seu próprio relógio pode ser causado por um provedor de tempo inválido.
- A coluna t indica o tipo de transmissão em uso: (l: local; u: unicast; m: multicast, ou b: broadcast).
- A coluna when indica quantos segundos se passaram desde que o peer remoto foi interrogado pela última vez.
- A coluna poll indica o intervalo de poll em segundos. O valor de pesquisa padrão em IM&P é 64 segundos. No entanto, esse valor pode ser definido entre 64 e 1.024 segundos.
- A coluna reach indica a tendência de testes de acessibilidade 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 votações foram bem-sucedidas, a votação anterior não foi bem-sucedida e a votação anterior foi bem-sucedida.
- A coluna delay exibe o delay round trip para o peer remoto. Isso é determinado pela medição do tempo da solicitação à resposta.
- A coluna deslocamento é o desvio estimado entre o relógio dos servidores locais e o relógio dos servidores remotos.
- A coluna jitter se refere à variabilidade do atraso entre as solicitações de chamada seletiva. Um alto valor de instabilidade limita a capacidade do servidor de sincronizar o NTP com precisão.
Troubleshooting de NTP
Diagnósticos de NTP CLI
Os comandos listados nos exemplos são executados no CLI do IM&P. Esses comandos fornecem uma maneira simples de confirmar se o peer NTP atende aos padrões da Cisco.
Dica: todos os três módulos de diagnóstico são executados, juntamente com vários outros, quando os utils diagnosticam o testeé usado
O módulo de diagnóstico ntp_reachability executa um teste de ping para todos os pares NTP configurados.
admin:utils diagnose module ntp_reachability
Log file: platform/log/diag2.log
Starting diagnostic test(s)
===========================
test - ntp_reachability : Passed
Diagnostics Completed
O módulo de diagnóstico ntp_clock_drift verifica se o deslocamento de desvio do par NTP não excede 15000 milissegundos.
admin:utils diagnose module ntp_clock_drift
Log file: platform/log/diag3.log
Starting diagnostic test(s)
===========================
test - ntp_clock_drift : Passed
Diagnostics Completed
O módulo de diagnóstico ntp_stratum verifica o valor de estrato NTP no IM&P. Este teste será aprovado com êxito se o estrato de NTP no Editor do CUCM for um valor de 5 ou menos, porque o editor do CUCM é a fonte de NTP externa para IM&P.
admin:utils diagnose module ntp_stratum
Log file: platform/log/diag4.log
Starting diagnostic test(s)
===========================
test - ntp_stratum : Passed
Diagnostics Completed
DICA: se o módulo ntp_stratum falhar no sistema, consulte a seção Requisitos para a origem de NTP deste documento
Verificar a comunicação e a versão do NTP
O NTP é um protocolo Cliente\Servidor que se comunica pelo User Datagram Protocol (UDP) na porta 123. Para verificar a comunicação NTP e a versão do NTP, você precisa executar uma captura de pacote (pcap) no servidor IM&P.
DICA: se você vir o IM&P enviar solicitações de NTP no pcap, no entanto, não há respostas de NTP e um problema de rede é possivelmente a causa. Coletar simultaneamente um pcap no servidor CUCM e no servidor IM&P para confirmar se as solicitações enviadas do IM&P são recebidas no lado CUCM. Confirme se o CUCM também responde às solicitações.
As capturas de pacote exibem uma resposta do Servidor NTP para cada solicitação do Cliente NTP. A mensagem NTP Client\Server exibe a versão do NTP em uso. Verifique se a solicitação do cliente e a resposta do servidor usam NTPv4.
Execute o comando CLI utils network capture port 123 para criar uma captura de pacote na porta 123. Esse comando é o mesmo para IM&P ou CUCM.
CLI IM&P
admin:utils network capture port 123
Executing command with options:
size=128 count=1000 interface=eth0
src=dest= port=123
ip=
09:44:43.106325 IP imppub.lab.local.46476 > cucmpub.lab.local.ntp: NTPv4, Client, length 48
09:44:43.109866 IP cucmpub.lab.local.ntp > imppub.lab.local.46476: NTPv4, Server, length 48
09:44:43.109931 IP imppub.lab.local.46476 > cucmpub.lab.local.ntp: NTPv4, Client, length 48
09:44:43.112815 IP cucmpub.lab.local.ntp > imppub.lab.local.46476: NTPv4, Server, length 48
09:44:43.112895 IP imppub.lab.local.46476 > cucmpub.lab.local.ntp: NTPv4, Client, length 48
09:44:43.113305 IP cucmpub.lab.local.ntp > imppub.lab.local.46476: NTPv4, Server, length 48
09:44:43.113361 IP imppub.lab.local.46476 > cucmpub.lab.local.ntp: NTPv4, Client, length 48
09:44:43.114157 IP cucmpub.lab.local.ntp > imppub.lab.local.46476: NTPv4, Server, length 48
CLI do editor do CUCM
admin:utils network capture port 123
Executing command with options:
size=128 count=1000 interface=eth0
src=dest= port=123
ip=
09:44:43.106744 IP imppub.lab.local.46476 > cucmpub.lab.local.ntp: NTPv4, Client, length 48
09:44:43.106872 IP cucmpub.lab.local.ntp > imppub.lab.local.46476: NTPv4, Server, length 48
09:44:43.109866 IP imppub.lab.local.46476 > cucmpub.lab.local.ntp: NTPv4, Client, length 48
09:44:43.109914 IP cucmpub.lab.local.ntp > imppub.lab.local.46476: NTPv4, Server, length 48
09:44:43.112637 IP imppub.lab.local.46476 > cucmpub.lab.local.ntp: NTPv4, Client, length 48
09:44:43.112719 IP cucmpub.lab.local.ntp > imppub.lab.local.46476: NTPv4, Server, length 48
09:44:43.113532 IP imppub.lab.local.46476 > cucmpub.lab.local.ntp: NTPv4, Client, length 48
09:44:43.113575 IP cucmpub.lab.local.ntp > imppub.lab.local.46476: NTPv4, Server, length 48
Feedback