Troubleshooting NTP no gerente das comunicações unificadas de Cisco

Introdução

Este original descreve como pesquisar defeitos edições do Network Time Protocol (NTP) no Produtos do gerente das comunicações unificadas de Cisco (CUCM) e das comunicações unificadas de Cisco (UC).

Informações de Apoio

CUCM exige que o NTP esteja configurado a fim assegurar:

• O tempo nos Nós CUCM é sincronizado.
• O tempo está correto antes de toda a alteração de configuração sensível ao tempo tal como a regeneração do certificado.
• A replicação de base de dados é sincronizada em todos os Nós no conjunto.

Mecanismo de polling NTP no Produtos UC

CUCM usa o cão de guarda NTP a fim manter o tempo sincronizado com o servidor de NTP. O cão de guarda NTP periodicamente vota server externos configurados NTP e reinicia o NTP se a hora é deslocada em mais de três segundos.

O demônio NTP corrige regularmente o tempo, mas em uma escala de tempo do milissegundo. Um reinício do NTP envolve que você executa um um-tiro NTP a fim executar uma correção de tempo bruta e a seguir com um reinício do demônio NTP para micro-correções regulares continuadas.

O cão de guarda NTP vota o NTP uma vez ao minuto em VMware e uma vez cada 30 minutos em máquinas físicas. O intervalo de polling é mais curto para VMware porque o pulso de disparo nas máquinas virtuais (VMs) é menos estável do que em máquinas e em características físicas de VMware tais como VMotion, migração do armazenamento afeta adversamente o tempo.

Um nó principal que seja executado em VMware deve sempre ser configurado a fim sincronizar com os servidores de NTP externos que são executado em máquinas físicas para compensar o grau mais alto de tração do tempo ou para o atrasar em um VM. Os Nós secundários sempre são configurados automaticamente para prover o servidor de NTP do nó principal a fim assegurar-se de que todos os Nós dentro do conjunto sejam próximos a tempo.

O cão de guarda NTP mantém-se a par da taxa em que reinicia o demônio NTP para as correções de tempo brutas devido a VMware VMotions e às migrações do armazenamento. Se esta taxa excede os reinícios 10 pela hora, o cão de guarda NTP adia uns reinícios mais adicionais até que a taxa exigida de reinícios caia abaixo 10 pela hora. A taxa combinada de VMotions e de migrações do armazenamento não deve exceder o 10 pela hora, porque esta taxa é considerada excessiva.

Devido a esta aplicação do cão de guarda NTP, você não segue o intervalo de votação, que é considerado no estado NTP dos utils. Uma captação do sniffer revelou 8 votações NTP (amostra) cada 60 segundos. Isto é primeiramente porque a aplicação NTP usa o cão de guarda NTP e como o ntpdate vota o servidor de NTP na aplicação UC.

Identifique a versão NTP usada

Nota: O editor CUCM é configurado com um servidor de NTP externo e o subscritor adicionados aos sincronizars do conjunto ao editor.

Nota: A versão 9.x e mais recente CUCM exige que o server NTPv4 esteja configurado como o servidor de NTP preferido.

Execute uma captação do sniffer a fim identificar a versão NTP usada pelo servidor de 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

CUCM envia um pacote NTPv4 e na resposta você recebe um pacote NTPv3. Embora NTPv4 seja para trás-compatível a NTPv3, a aplicação CUCM do NTP varia, que conduz ao 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

A fim fixar a edição, Cisco recomenda-o usa um ^® externo Linux-baseado do servidor de NTP ou do Cisco IOS ou o servidor de NTP XE-baseado IO e assegura-se de que NTPv4 esteja configurado.

Está aqui uma descrição da terminologia NTP nas saídas de status NTP:

• A coluna do refid indica o origem de tempo do telecontrole. LOCAL(0) são o pulso de disparo do hardware local. .INIT significa que a iniciação não sucedeu ainda.
  
  
• A coluna st é o estrato do servidor de NTP remoto. 16 são um valor inválido do estrato que signifique que “este server não está considerado um fornecedor do tempo”. O estrato pode ser inválido por razões diversas, o mais comum de que é que do “o fornecedor tempo não sincronizado”, “a fonte configurada não existe”, ou “o server NTP que não é executado”.
  
  
• A coluna t indica o tipo de servidor (l: local; u: unicast; m: Multicast, ou b: transmissão).
  
  
• Quando a coluna indicar quantos segundos há o telecontrole esteve perguntado.
  
  
• A coluna da votação indica o intervalo de polling nos segundos. Por exemplo, "64" significa que o telecontrole está votado cada 64 segundos. Os usos os mais curtos do intervalo NTP são cada 64 segundos e o mais longo é 1,024 segundos. Uma fonte NTP é avaliada melhor ao longo do tempo, mais longo o intervalo. (A aplicação UC não segue o intervalo definido aqui.)
  
  
• A coluna do alcance indica a tendência de testes do reachability em octal, onde cada dígito, quando convertido ao binário, representa se uma votação particular era bem sucedida (binário 1) ou mal sucedida (binário 0). Por exemplo, "1" significa que somente uma votação esteve feita até aqui e era bem sucedida. "3" (= binário 11) significa que as últimas duas votações eram bem sucedidas. "7" (= binário 111) significa que as últimas três votações eram bem sucedidas. "17" (= binário 1 111) significa que as últimas quatro votações eram bem sucedidas. "15" (= binário 1 101) significa que as últimas duas votações eram bem sucedidas, a votação antes daquela era mal sucedida, e a votação antes daquela era bem sucedida.
  
  
• O atraso, o offset, e as colunas do tremor são o retardo round trip, a dispersão, e o tremor nos milissegundos.

Diagnostique edições NTP-relacionadas em CUCM

Termine estas etapas a fim diagnosticar edições NTP-relacionadas:

1. Assegure-se de que CUCM possa se comunicar com o servidor de NTP na porta 123.
   
   
2. Obtenha a saída do estado NTP dos utils.
   
   
   • O nível de estrato deve ser menos de 4 no editor para o desempenho ótimo
   • Se os servidores de NTP múltiplos são configurados, assegure pelo menos no server é alcançável; você deve ver (*) o símbolo contra o servidor de NTP usado como uma referência por CUCM.
   
   
   
3. Reveja o alarme do Syslog e tome ações em conformidade. As causas prováveis de alarmes do Syslog são:
   
   
   • O servidor de NTP externo não é alcançável.
   • O estrato NTP é mais alto do que o limite aceitável.
   • O editor está para baixo, assim que o subscritor NTP é não-sincronizado.
   • Se ntpdate - os alertas relativos q são considerados, ele são possíveis que você tem a versão 4.2.6+ NTP com a característica do golpe de graça (KoD) permitida. (Pelo projeto, pelo intervalo mínimo entre a explosão e pelos pacotes do iburst enviados por todo o cliente são dois, que não violar esta limitação. Pacotes enviados por outras aplicações que violam esta limitação serão deixadas cair e um pacote de KoD retornado, se permitido). Recomenda-se desabilitar esta característica quando você usa essa versão como o servidor de NTP para um produto UC.
   
   
   
4. Use este módulo do diagnóstico a fim verificar que o servidor de NTP está configurado.
   • os utils diagnosticam o ntp_reachability do módulo
   • os utils diagnosticam o ntp_clock_drift do módulo
   • os utils diagnosticam o ntp_stratum do módulo
   
   
   
5. Incorpore o reinício NTP dos utils a fim reiniciar o cliente de NTP/server. Este comando é útil sempre que uma correção de tempo bruta precisa de ocorrer imediatamente ou sempre que os servidores internos são ainda alcançáveis e operacionais, mas a sincronização falha. Use o comando status NTP dos utils a fim determinar o status operacional de servidores de NTP externos.

Problemas conhecidos comuns com associação NTP em CUCM

Identificação de bug Cisco CSCue18813: Configuração de NTP “parâmetro do maxdist tos” controlado através do CLI

Resolução: O exemplo do centro de assistência técnica da Cisco deve ser aumentado a fim adicionar manualmente o parâmetro do maxdist tos no arquivo ntp.conf.

Identificação de bug Cisco CSCuq70611: O teste do estrato NTP não valida corretamente com único servidor de NTP

verões fixa: 10.5(2.10000.005)

Identificação de bug Cisco CSCui85967: A elevação do salto CUCM de 6.1.5 a 9.1.2 falha devido aos desaparecidos da referência NTP

Resolução: A documentação da elevação do salto foi atualizada e a configuração de NTP é alistada como sobre das tarefas prévias ao upgrade.

Identificação de bug Cisco CSCtw46611:  A sincronização NTP falha devido à rotulagem incorreta do sistema de arquivos de capture.txt

verões fixa: 8.6(2.24900.017)

Identificação de bug Cisco CSCur94973: Betn VMHost da edição da sincronização de tempo & exemplo VM durante a migração M1

Resolução: Desabilite a sincronização NTP do VM com o host de ESXi com o uso desta ação alternativa. Um contorno alternado é configurar o server de ESXi e o editor CUCM para apontar ao mesmo servidor de NTP.