Contents

Introduction

Prerequisites

Requirements

Componentes Utilizados

NTP em IM&P explicado

Requisitos para origem NTP

Explicação de saída do status do NTP

Troubleshooting de NTP

Diagnósticos de NTP CLI

Verificar a comunicação e a versão do NTP

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