Sommario

Introduzione

Prerequisiti

Requisiti

Componenti usati

Scopo della funzionalità

Configurazione

Esempio di rete

Processo di installazione

Dopo l'installazione, utilizzare la pagina Web Amministrazione del sistema operativo

Dopo l'installazione, utilizzare l'interfaccia della riga di comando

Risoluzione dei problemi

Dati da raccogliere

Analisi di esempio

Analisi PCAP per CUCM - Nessun file

Analisi PCAP per CUCM - Con file

Revisione dell'output CLI per CUCM

Ulteriori considerazioni

Informazioni correlate

Introduzione

Questo documento descrive il protocollo NTP (Network Time Protocol) per Cisco Unified Communications Manager (CUCM).

Prerequisiti

Requisiti

Nessun requisito specifico previsto per questo documento.

Componenti usati

Il documento può essere consultato per tutte le versioni software o hardware.

Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.

Scopo della funzionalità

Questo documento descrive lo scopo dell'NTP con CUCM, la configurazione dell'NTP, i dati da raccogliere per la risoluzione dei problemi, l'analisi di esempio dei dati e le risorse correlate per ulteriori ricerche.

Lo scopo dell'NTP con CUCM è quello di garantire che i server siano a conoscenza dell'ora corretta. Il tempo nei server CUCM è importante perché il protocollo VOIP (Voice Over Internet Protocol) è estremamente sensibile alle variazioni di tempo. Il cluster CUCM deve mantenere una sincronizzazione dell'ora che rimanga vicina agli altri server del cluster, a causa dei requisiti di replica del database.

Infine, il tempo necessario per la risoluzione dei problemi è importante, in quanto si desidera che nei log vengano inseriti i timestamp corretti.

Configurazione

È importante notare che CUCM richiede alcuni server NTP.

Il server Windows NTP non è supportato per CUCM; tuttavia, altri tipi, quali origini NTP Linux, origini NTP Cisco IOS® e origini Nexus OS NTP, sono accettabili. Anche se altre soluzioni Cisco possono utilizzare i server Windows per la soluzione NTP, le soluzioni UC come CallManager, Cisco Unity, e Instant Messaging e Presence, non sono in grado di farlo e richiedono una soluzione NTP basata su Linux o Cisco IOS®. Questo perché i servizi ora di Windows utilizzano spesso SNTP con cui i sistemi Linux hanno difficoltà a sincronizzarsi.

Esempio di rete

L'editore CUCM necessita di un'origine NTP che non sia membro del cluster CUCM; pertanto l'editore CUCM sincronizza l'ora con il server NTP. In questo scambio, l'editore CUCM è un client NTP.

Gli abbonati CUCM sincronizzano l'ora con l'editore CUCM. In questo scambio, l'editore CUCM è un server NTP in cui i sottoscrittori CUCM sono client NTP.

Attenzione: si tenga presente che anche i server Cisco Instant Messaging & Presence (IM&P) sono considerati sottoscrittori del cluster CUCM, quindi si basano anche sul protocollo NTP del cluster CUCM. In altre parole, se l'NTP non è sincronizzato sul server IM&P, si verificano problemi nel sistema con la replica di database e l'alta disponibilità.

Processo di installazione

Quando viene installato CUCM, viene richiesto se il server è il primo nodo del cluster.

Se il server non è il primo nodo del cluster, l'installazione guidata si sposta oltre la fase di configurazione NTP. Tuttavia, viene richiesto di specificare i server NTP se si tratta del primo nodo del cluster.

Dopo l'installazione, utilizzare la pagina Web Amministrazione del sistema operativo

Dopo l'installazione, utilizzare l'interfaccia della riga di comando

Come mostrato nelle immagini, è possibile trovare i comandi utilizzati per accedere e modificare i server NTP all'interno del server CUCM.

- Il comando utilizza l'elenco dei server ntp per visualizzare i server NTP configurati sul sistema.

- Il comando utilizza il server ntp add indirizzo_ntp per aggiungere un nuovo server NTP al sistema.

Nota: se si desidera aggiungere un nuovo server NTP, il server CUCM verifica la raggiungibilità prima di aggiungerlo. Se l'operazione non riesce, viene visualizzato l'errore successivo.

- Il comando utilizza ntp server delete per eliminare qualsiasi NTP già configurato nel sistema.

Risoluzione dei problemi

Dati da raccogliere

Quando si risolve un problema NTP, è necessario raccogliere questi dati dai server CUCM che hanno problemi NTP:

- L'output del comando utilizza il test di diagnosi

- L'output dello stato ntp degli utilità

- I log NTP dal CUCM raccolti dallo strumento Cisco Real-Time Monitor Tool (RTMT)

Analisi di esempio

A titolo di esempio, sono state utilizzate le seguenti informazioni fornite da CUCM Publisher e NTP:

Autore CUCM

Versione: 11.5(1) SU5

FQDN: cucm-115.home.lab

L'indirizzo IP inizia con 192.X.X.X

NTP

Da Google NTP Server

FQDN: time1.example.com.ntp

L'indirizzo IP inizia con 216.X.X.X

Analisi PCAP per CUCM - Nessun file

Si noti che il numero di porta è 123. Questa è la porta per NTP. Nell'output del comando nella casella di testo, è possibile vedere che la versione NTP è 4 come indicato da "NTPv4". È inoltre possibile prendere nota dell'editore, che agisce come client quando stabilisce la comunicazione con "time1.example.com"; tuttavia, funziona come server quando stabilisce la comunicazione con 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

Analisi PCAP per CUCM - Con file

Il filtro usato per risolvere il problema NTP nell'acquisizione del pacchetto è: udp.port = 123. Con questo filtro, si può vedere che l'editore CUCM ha stabilito la comunicazione con il server Google NTP e che l'editore CUCM ha comunicato anche con gli abbonati CUCM.

Revisione dell'output CLI per CUCM

output stato ntp 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:

Leggere le informazioni seguenti, in cui viene illustrato in dettaglio l'output precedente.

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.

Utils diagnostica output test

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 l'NTP non riesce nell'output del test di diagnostica degli utenti, si otterrebbe qualcosa di simile a quanto riportato di seguito:

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

Verificare che il protocollo NTP fosse valido al momento dell'installazione. Eseguire il comando:

eseguire sql select pkid,name,dbinfo('utc_to_datetime', cdrtime) as CDRTIME dal dispositivo dove cdrtime > getCurrTime()

Con questo comando viene confrontata l'ora corrente con la cdrtime (quando la tabella è stata modificata). Se durante l'installazione o l'aggiornamento è stato utilizzato un NTP non valido e quindi il NTP è stato corretto, il database non sarà sincronizzato ogni volta che viene apportata una modifica. Questo problema non si verifica quando si eseguono i comandi NTP tipici (ad esempio, utilizza lo stato ntp) perché si è passati dalla sorgente NTP errata a una buona.

Sarebbe bene allontanarsi dall'NTP errato per passare a un buon NTP; tuttavia, il passaggio a una buona origine NTP non correggerebbe le tabelle create durante l'installazione o l'aggiornamento.

Quando si esegue questo comando, l'output previsto è il seguente:

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

pkid name cdrtime

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

admin:

Se si dispone di un output simile a quello successivo, è possibile che il protocollo NTP utilizzato per l'installazione o l'aggiornamento non sia stato utilizzato e abbia causato problemi che influiscono sulla replica del database:

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

Ulteriori considerazioni

1) Se si aggiornano gli host ESXi senza tenere conto delle considerazioni relative all'hardware della VM, è possibile riscontrare problemi NTP.

2) Verificare che la versione ESXi sia conforme alla matrice di virtualizzazione.

3) Verificare che la versione ESXi e la versione hardware siano compatibili

Informazioni correlate

- Documentazione e supporto tecnico - Cisco Sistemas

- Progetti di rete di riferimento per soluzioni Cisco Collaboration System 10.x (SRND)

- Modifica dell'origine NTP in CUCM da CLI e altre informazioni utili

- Risoluzione dei problemi NTP su Cisco Unified Communications Manager

- Protocollo ora di rete: white paper sulle best practice

- Acquisizione di pacchetti sul modello di accessorio CUCM