Contents

Introduction

Prerequisites

Requirements

Componentes Utilizados

Finalidade do recurso

Configurar

Diagrama de Rede

Processo de instalação

Após a instalação, use a página da Web Admin do SO

Após a instalação, use a interface de linha de comando

Troubleshoot

Dados a Serem Coletados

Exemplo de análise

Revisão PCAP para CUCM - Sem arquivo

Revisão de PCAP para CUCM - Com arquivo

Revisão da saída CLI para CUCM

Outras considerações

Informações Relacionadas

Introduction

Este documento descreve o Network Time Protocol (NTP) para o Cisco Unified Communications Manager (CUCM).

Prerequisites

Requirements

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.

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.

Finalidade do recurso

Este documento aborda a finalidade do NTP com CUCM, a configuração do NTP, que dados coletar para solucionar problemas, exemplo de análise dos dados e recursos relacionados para pesquisa adicional.

A finalidade do NTP com CUCM é garantir que os servidores estejam cientes da hora correta. O tempo nos servidores CUCM é importante porque o Voice Over Internet Protocol (VOIP) é extremamente sensível às variações de tempo. O cluster do CUCM deve manter uma sincronização de tempo que permaneça próxima aos outros servidores no cluster, devido aos requisitos de replicação de banco de dados.

Por fim, o tempo de solução de problemas é importante, pois você deseja ter os carimbos de data/hora corretos nos registros.

Configurar

É importante observar que o CUCM requer determinados servidores NTP.

O servidor NTP do Windows não é suportado para CUCM; no entanto, outros tipos, como fontes NTP do Linux, fontes NTP do Cisco IOS® e fontes NTP do Nexus OS, são aceitáveis. Embora outras soluções da Cisco possam utilizar servidores Windows para a solução NTP, as soluções de UC como CallManager, Cisco Unity e Instant Messaging and Presence não podem fazer isso e exigem uma solução NTP baseada em Linux ou Cisco IOS®. Isso ocorre porque os Serviços de Tempo do Windows geralmente usam SNTP com o qual os sistemas Linux têm dificuldade para sincronizar.

Diagrama de Rede

O editor do CUCM precisa de uma origem NTP que não seja membro do cluster do CUCM; portanto, o editor do CUCM sincroniza seu tempo com o servidor NTP. Neste intercâmbio, o editor do CUCM é um cliente NTP.

Os assinantes do CUCM sincronizam seu tempo com o editor do CUCM. Nesta troca, o editor do CUCM é um servidor NTP onde os assinantes do CUCM são clientes NTP.

Cuidado: lembre-se de que os servidores de mensagens instantâneas e presença (IM&P) da Cisco também são considerados assinantes do cluster CUCM, portanto, eles também dependem do NTP CUCMs. Em outras palavras, se o NTP estiver fora de sincronia no servidor IM&P, ele causará problemas no sistema com sua replicação de banco de dados e alta disponibilidade.

Processo de instalação

Quando o CUCM é instalado, há um prompt para determinar se o servidor é o primeiro nó no cluster.

Se o servidor não for o primeiro nó no cluster, o assistente de instalação passará da fase de configuração do NTP; no entanto, você será solicitado a fornecer o(s) servidor(es) NTP se ele for o primeiro nó no cluster.

Após a instalação, use a página da Web Admin do SO

Após a instalação, use a interface de linha de comando

Como mostrado nas imagens, você pode encontrar os comandos usados para acessar e modificar os servidores NTP no servidor CUCM.

- O comando utils ntp server list mostra os servidores NTP configurados no sistema.

- O comando utils ntp server add ntp_address adiciona um novo servidor NTP ao sistema.

Observação: lembre-se de que, se você quiser adicionar um novo servidor NTP, o servidor CUCM testa a acessibilidade antes de adicioná-lo. Se ele falhar, o próximo erro será visto.

- O comando utils ntp server delete permite excluir qualquer um dos NTPs já configurados no sistema.

Troubleshoot

Dados a Serem Coletados

Ao solucionar um problema de NTP, você precisa coletar esses dados de qualquer servidor CUCM que tenha os problemas de NTP:

- A saída do comando utils diagnose test

- A saída do status ntp de utils

- Os registros de NTP do CUCM coletados da ferramenta Cisco Real-Time Monitor (RTMT)

Exemplo de análise

Por exemplo, as próximas informações do Editor do CUCM e do NTP foram usadas:

Editor do CUCM

Versão: 11.5(1) SU5

FQDN: cucm-115.home.lab

O endereço IP começa com 192.X.X.X

NTP

Do servidor NTP do Google

FQDN: time1.example.com.ntp

O endereço IP começa com 216.X.X.X

Revisão PCAP para CUCM - Sem arquivo

Observe que o número da porta é 123. Esta é a porta para NTP. Na saída do comando na caixa de texto, você pode ver que a versão do NTP é 4, conforme observado pelo "NTPv4". Você também pode tomar nota do editor, que atua como um cliente quando estabelece sua comunicação com "time1.example.com"; no entanto, ele funciona como um servidor quando estabelece a comunicação com cucm-sub1, cucm-sub2 e cucm-sub3.

From the CLI of the publisher run the command "utils network capture port 123"

Wait until you see traffic (this can take a little time, or it may be instant) then hit

ctrl+c. Look in the traffic to find where your publisher is communicating with its NTP

server and the NTP server is communication with the publisher (if the NTP server isn't

replying then it is an issue in the network or with the NTP server). The primary focus of

this output is the NTP version. In CUCM 9 and later NTP version 3 (NTPv3) can cause issues

and an NTP source using NTPv4 should be the NTP server for the publisher.

admin:utils network capture size all count 10000000 port 123

Executing command with options:

size=128                count=1000              interface=eth0

src=dest=                   port=123

ip=

16:08:43.199710 IP cucm-sub3.home.lab.39417 > cucm-115.home.lab.ntp: NTPv4, Client, length 48

16:08:43.199737 IP cucm-115.home.lab.ntp > cucm-sub3.home.lab.39417: NTPv4, Server, length 48

16:08:43.199823 IP cucm-sub3.home.lab.39417 > cucm-115.home.lab.ntp: NTPv4, Client, length 48

16:08:43.199859 IP cucm-115.home.lab.ntp > cucm-sub3.home.lab.39417: NTPv4, Server, length 48

16:09:01.640980 IP cucm-115.home.lab.50141 > time1.example.com.ntp: NTPv4, Client, length 48

16:09:01.654675 IP time1.example.com.ntp > cucm-115.home.lab.50141: NTPv4, Server, length 48

16:09:01.654733 IP cucm-115.home.lab.50141 > time1.example.com.ntp: NTPv4, Client, length 48

16:09:01.667368 IP time1.example.com.ntp > cucm-115.home.lab.50141: NTPv4, Server, length 48

16:09:01.668612 IP cucm-115.home.lab.50141 > time1.example.com.ntp: NTPv4, Client, length 48

16:09:01.681366 IP time1.example.com.ntp > cucm-115.home.lab.50141: NTPv4, Server, length 48

16:09:01.681518 IP cucm-115.home.lab.50141 > time1.google.com.ntp: NTPv4, Client, length 48

16:09:01.694108 IP time1.google.com.ntp > cucm-115.home.lab.50141: NTPv4, Server, length 48

16:09:01.875016 IP cucm-115.home.lab.48422 > time1.google.com.ntp: NTPv4, Client, length 48

16:09:01.884476 IP cucm-sub3.home.lab.58072 > cucm-115.home.lab.ntp: NTPv4, Client, length 48

16:09:01.884568 IP cucm-115.home.lab.ntp > cucm-sub3.home.lab.58072: NTPv4, Server, length 48

16:09:01.884954 IP cucm-sub3.home.lab.58072 > cucm-115.home.lab.ntp: NTPv4, Client, length 48

16:09:01.884999 IP cucm-115.home.lab.ntp > cucm-sub3.home.lab.58072: NTPv4, Server, length 48

16:09:01.885381 IP cucm-sub3.home.lab.58072 > cucm-115.home.lab.ntp: NTPv4, Client, length 48

16:09:01.885423 IP cucm-115.home.lab.ntp > cucm-sub3.home.lab.58072: NTPv4, Server, length 48

16:09:01.886147 IP cucm-sub3.home.lab.58072 > cucm-115.home.lab.ntp: NTPv4, Client, length 48

16:09:01.886184 IP cucm-115.home.lab.ntp > cucm-sub3.home.lab.58072: NTPv4, Server, length 48

16:09:01.888555 IP time1.google.com.ntp > cucm-115.home.lab.48422: NTPv4, Server, length 48

16:09:01.888642 IP cucm-115.home.lab.48422 > time1.google.com.ntp: NTPv4, Client, length 48

16:09:01.900926 IP time1.google.com.ntp > cucm-115.home.lab.48422: NTPv4, Server, length 48

16:09:01.901017 IP cucm-115.home.lab.48422 > time1.google.com.ntp: NTPv4, Client, length 48

16:09:01.913497 IP time1.google.com.ntp > cucm-115.home.lab.48422: NTPv4, Server, length 48

16:09:01.913566 IP cucm-115.home.lab.48422 > time1.google.com.ntp: NTPv4, Client, length 48

16:09:01.926693 IP time1.google.com.ntp > cucm-115.home.lab.48422: NTPv4, Server, length 48

16:09:02.038981 IP cucm-sub2.home.lab.42078 > cucm-115.home.lab.ntp: NTPv4, Client, length 48

16:09:02.039117 IP cucm-115.home.lab.ntp > cucm-sub2.home.lab.42078: NTPv4, Server, length 48

16:09:02.039281 IP cucm-sub2.home.lab.42078 > cucm-115.home.lab.ntp: NTPv4, Client, length 48

16:09:02.039345 IP cucm-115.home.lab.ntp > cucm-sub2.home.lab.42078: NTPv4, Server, length 48

16:09:02.039434 IP cucm-sub2.home.lab.42078 > cucm-115.home.lab.ntp: NTPv4, Client, length 48

16:09:02.039535 IP cucm-115.home.lab.ntp > cucm-sub2.home.lab.42078: NTPv4, Server, length 48

16:09:02.039607 IP cucm-sub2.home.lab.42078 > cucm-115.home.lab.ntp: NTPv4, Client, length 48

16:09:02.039814 IP cucm-115.home.lab.ntp > cucm-sub2.home.lab.42078: NTPv4, Server, length 48

16:09:02.066544 IP cucm-sub1.home.lab.46400 > cucm-115.home.lab.ntp: NTPv4, Client, length 48

16:09:02.066622 IP cucm-115.home.lab.ntp > cucm-sub1.home.lab.46400: NTPv4, Server, length 48

16:09:02.066751 IP cucm-sub1.home.lab.46400 > cucm-115.home.lab.ntp: NTPv4, Client, length 48

16:09:02.066892 IP cucm-115.home.lab.ntp > cucm-sub1.home.lab.46400: NTPv4, Server, length 48

16:09:02.066968 IP cucm-sub1.home.lab.46400 > cucm-115.home.lab.ntp: NTPv4, Client, length 48

16:09:02.067104 IP cucm-115.home.lab.ntp > cucm-sub1.home.lab.46400: NTPv4, Server, length 48

16:09:02.067155 IP cucm-sub1.home.lab.46400 > cucm-115.home.lab.ntp: NTPv4, Client, length 48

16:09:02.067189 IP cucm-115.home.lab.ntp > cucm-sub1.home.lab.46400: NTPv4, Server, length 48

Revisão de PCAP para CUCM - Com arquivo

O filtro usado para solucionar o problema de NTP na captura de pacotes é: udp.port == 123. Com esse filtro, você pode ver que o editor do CUCM estabeleceu comunicação com o servidor NTP do Google e que o editor do CUCM se comunicou com os assinantes do CUCM também.

Revisão da saída CLI para CUCM

saída de status NTP de utils

NOTE: All nodes will show the current time in UTC regardless of the time zone of the server

(listed in UTC time). This makes it easy to compare times on the different CUCM nodes.

NOTE: If there is a time difference of 15 minutes or more, it is expected that DB replication

will be broken

1) If the publisher is ahead by 15 minutes, this can result in the pub send data to the

sub and the sub would have a delay to process the data because it has not yet reached the time

in the timestamp of the packets from the publisher (this is expected behavior in this type of situation)

2) If  the subscriber is ahead by 15 minutes, this would result in the subscriber drop

the data from the publisher because the subscriber sees it as old data (15 minutes old)

admin:utils ntp status

ntpd (pid 28435) is running...

remote           refid      st t when poll reach   delay   offset  jitter

==============================================================================

203.0.113.0    .GOOG.           1 u   44   64    3   11.724   -0.021   0.064

unsynchronised

polling server every 8 s

Current time in UTC is : Fri Sep  6 20:54:50 UTC 2019

Current time in America/New_York is : Fri Sep  6 16:54:50 EDT 2019

admin:

Leia as informações a seguir, pois elas explicam a saída anterior em detalhes.

The very first column contains the "tally code" character. Short overview:

* the source you are synchronized to (syspeer)

# source selected, distance exceeds maximum value

o the PPS(Pulse Per Second) source if your ntpd (ppspeer, only if you have a PPS capable system and refclock)

+ candidate, i.e. it is considered a good source

- outlyer, i.e. quality is not good enough

x falseticker, i.e. this one is considered to distribute bad time

blank: source discarded, failed sanity

See the Select field of the Peer status word on the NTP Event Messages and

Status Words page for more information on the tally codes.

remote

the hostname or IP of the remote machine.

refid

the identification of the time source to which the remote machines is synced.

May be (for example) a radio clock or another ntp server)

st

the stratum of the remote machine. 16 is "unsynchronized". 0 is the best

value, that could be (for example) a radio clock or the ntp servers private

caesium clock (see http://www.eecis.udel.edu/~mills/ntp/html/index.html#intro

for more information about ntp in general).

t

types available:

l = local (such as a GPS, WWVB)

u = unicast (most common)

m = multicast

b = broadcast

- = netaddr

when

how many seconds since the last poll of the remote machine.

poll

the polling interval in seconds.

reach

an 8-bit left-rotating register. Any 1 bit means that a "time packet" was

received. The right most bit indicate the status of the last connection

with the NTP server. It is Octal number. Use calculator in progammer

interface to translate from OCT to BIN: For example 377 translates to

11111111. Each 1 means a successful connection to the NTP server. If you

just start a NTP service, and it connects successfully with its server, this

number will change as follows (if connectivity is good):

00000001 = 001

00000011 = 003

00000111 = 007

00001111 = 017

00011111 = 037

00111111 = 077

01111111 = 177

11111111 = 377

delay

the time delay (in milliseconds) to communicate with the remote.

offset

the offset (in milliseconds) between our time and that of the remote.

jitter

the observed jitter (in milliseconds) of time with the remote.

Utiliza o diagnóstico de saída de teste

admin:utils diagnose test

Log file: platform/log/diag1.log

Starting diagnostic test(s)

===========================

test - disk_space          : Passed (available: 6463 MB, used: 12681 MB)

skip - disk_files          : This module must be run directly and off hours

test - service_manager     : Passed

test - tomcat              : Passed

test - tomcat_deadlocks    : Passed

test - tomcat_keystore     : Passed

test - tomcat_connectors   : Passed

test - tomcat_threads      : Passed

test - tomcat_memory       : Passed

test - tomcat_sessions     : Passed

skip - tomcat_heapdump     : This module must be run directly and off hours

test - validate_network    : Passed

test - raid                : Passed

test - system_info         : Passed (Collected system information in diagnostic log)

test - ntp_reachability    : Passed

test - ntp_clock_drift     : Passed

test - ntp_stratum         : Passed

skip - sdl_fragmentation   : This module must be run directly and off hours

skip - sdi_fragmentation   : This module must be run directly and off hours

Diagnostics Completed

The final output will be in Log file: platform/log/diag1.log

Please use 'file view activelog platform/log/diag1.log' command to see the output

admin:

Se o NTP falhar na saída do teste de diagnóstico de utils, você verá algo semelhante a isto:

admin:utils diagnose test

Log file: platform/log/diag1.log

Starting diagnostic test(s)

===========================

test - disk_space          : Passed (available: 6463 MB, used: 12681 MB)

skip - disk_files          : This module must be run directly and off hours

test - service_manager     : Passed

test - tomcat              : Passed

test - tomcat_deadlocks    : Passed

test - tomcat_keystore     : Passed

test - tomcat_connectors   : Passed

test - tomcat_threads      : Passed

test - tomcat_memory       : Passed

test - tomcat_sessions     : Passed

skip - tomcat_heapdump     : This module must be run directly and off hours

test - validate_network    : Passed

test - raid                : Passed

test - system_info         : Passed (Collected system information in diagnostic log)

test - ntp_reachability    : Warning

The NTP service is restarting, it can take about 5 minutes.

test - ntp_clock_drift     : Warning

The local clock is not synchronised.

None of the designated NTP servers are reachable/functioning or legitimate.

test - ntp_stratum         : Warning

The local clock is not synchronised.

None of the designated NTP servers are reachable/functioning or legitimate.

skip - sdl_fragmentation   : This module must be run directly and off hours

Confirme se o NTP estava bom no momento da instalação. Execute o comando:

execute sql select pkid,name,dbinfo('utc_to_datetime', cdrtime) as CDRTIME do dispositivo onde cdrtime > getCurrTime()

Esse comando compara a hora atual com a hora do cdrtime (quando a tabela foi modificada). Se você usou um NTP inválido na instalação/atualização e corrigiu o NTP, o banco de dados perderá a sincronização toda vez que uma alteração for feita. Esse problema não seria visto quando você executa os comandos NTP típicos (por exemplo, utils ntp status) porque você mudou da origem NTP incorreta para uma boa.

Seria bom que você saísse do NTP incorreto para um bom; no entanto, um movimento para uma boa origem de NTP não corrigiria as tabelas que foram criadas durante a instalação/atualização.

Quando se executa esse comando, a saída esperada é esta:

admin:run sql select pkid,name,dbinfo('utc_to_datetime', cdrtime) as CDRTIME  from device where cdrtime > getCurrTime()

pkid name cdrtime

==== ==== =======

admin:

Se você tiver uma saída semelhante à seguinte, é um sinal de que o NTP usado para a instalação/atualização não foi usado e causou problemas que afetam a replicação do banco de dados:

admin:run sql select pkid,name,dbinfo('utc_to_datetime', cdrtime) as CDRTIME from device where cdrtime > getCurrTime()

pkid                                    name          cdrtime

=============================           =====         =====================

bf80dd31-9911-43ce-81fd-a99ec0333fb5    MTP_2         2016-09-11 14:38:14.0

4c38fc05-760d-4afb-96e8-69333c195e74    CFB_2         2016-09-11 14:38:14.0

90878c80-e213-4c7e-82b9-6c780aac72f3    ANN_2         2016-09-11 14:38:14.0

08b5bff4-da94-4dfb-88af-ea9ffa96872c    MOH_2         2016-09-11 14:38:14.0

93320e4d-1b73-4099-9a7c-c4cddfadb5d9    MTP_3         2016-09-11 14:38:14.0

a6850d42-5f0a-49ce-9fa3-80d45b800e23    CFB_3         2016-09-11 14:38:14.0

9963c9cb-58b0-4191-93e1-8676584f6461    ANN_3         2016-09-11 14:38:14.0

def79fb7-c801-4fb3-85fb-4e94310bf0bd    MOH_3         2016-09-11 14:38:14.0

4cd64584-089b-4331-9291-79774330cbc     2 MTP_4       2016-09-11 14:38:14.0

27b18882-db83-4d14-8bce-d3f8dc439610    CFB_4         2016-09-11 14:38:14.0

a40da882-e04f-4649-b2eb-2f79d1289e81    ANN_4         2016-09-11 14:38:14.0

36575ff4-cdea-4945-87e7-638cc555463e    MOH_4         2016-09-11 14:38:14.0

Outras considerações

1) Se você atualizar os hosts ESXi sem considerar as considerações de hardware da VM, poderá ter problemas de NTP.

2) Certifique-se de que a versão do ESXi esteja em conformidade com a matriz de virtualização.

3) Garantir que a versão do ESXi e a versão do hardware sejam compatíveis

Informações Relacionadas

- Suporte técnico e documentação - Cisco Sistemas

- Designs de rede de referência da solução Cisco Collaboration System 10.x (SRND)

- Alterar a fonte de NTP no CUCM a partir da CLI e de outras informações úteis

- Solução de problemas de NTP no Cisco Unified Communications Manager

- Network Time Protocol: White paper sobre práticas recomendadas

- Captura de pacotes no modelo do dispositivo CUCM