Risoluzione dei problemi NTP su IM&P

Introduzione

Questo documento descrive come risolvere i problemi relativi alla sincronizzazione Network Time Protocol (NTP) su IM e Presenza (IM&P).

Prerequisiti

Cisco consiglia di avere una conoscenza di base di NTP e dell'interfaccia della riga di comando IM&P (CLI) prima di consultare questo documento.

Requisiti

Nessun requisito hardware o software specifico previsto per questo documento.

Componenti usati

Le informazioni fornite in questo documento si basano su IM&P.

Nota: molte di queste informazioni si applicano anche ad altre piattaforme per le comunicazioni unificate (UC); tuttavia, il focus di questo documento è IM&P.

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.

Spiegazione di NTP su IM&P

Cisco Unified Communications Manager (CUCM) Publisher è l'origine NTP per IM&P. IM&P utilizza il watchdog NTP per mantenere l'ora sincronizzata con l'editore CUCM. Per le piattaforme IM&P che si trovano su una macchina virtuale, NTP Watchdog effettua il polling a CUCM Publisher ogni 64 secondi per impostazione predefinita. Se l'offset NTP è superiore a tre secondi, il daemon NTP si riavvia da solo.

Nota: NTP Watchdog controlla quante volte il daemon NTP è stato riavviato nell'ultima ora. Se si verificano più di 10 riavvii del daemon NTP in un'ora, ulteriori riavvii vengono posticipati brevemente.

Requisiti per l'origine NTP

Cisco consiglia di utilizzare un server NTP Stratum 1, Stratum 2 o Stratum 3 come riferimento NTP esterno di CUCM Publisher. Qualsiasi origine NTP per l'editore CUCM DEVE NON essere superiore allo strato 4.

I server NTP esterni definiti per il nodo CUCM Publisher DEVONO essere NTP v4 per evitare potenziali problemi di compatibilità, accuratezza e jitter di rete. NTP versione 4 è compatibile con la versione precedente 3; tuttavia, sono stati osservati molti problemi con i tentativi di utilizzare versioni NTP diverse.

Avviso: l'utilizzo di Servizi ora di Windows come server NTP non è supportato. Spesso i servizi ora di Windows utilizzano il protocollo SNTP (Simple Network Time Protocol) e CUCM non riesce a eseguire correttamente la sincronizzazione con SNTP.

Nota: tutti i requisiti NTP sono chiaramente indicati in Cisco Collaboration System SRND. 

Spiegazione output stato NTP

Per determinare lo stato corrente di NTP su IM&P, eseguire il comando utils ntp status dalla CLI del server 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

Descrizioni delle colonne visualizzate nell'output dello stato NTP

• La colonna remote definisce il peer remoto in cui l'ora è sincronizzata. Se impostato su LOCAL, l'orologio hardware locale è in uso. 

• La colonna refid definisce l'origine ora del server remoto. Se impostato su .LOCL, viene fatto riferimento all'orologio hardware locale del server remoto. Se impostato su .INIT, l'inizializzazione non è ancora riuscita.
  
  
• La prima colonna indica lo strato del peer NTP remoto. Quando il valore 16 è nella colonna dello strato, significa che il sistema utilizza l'orologio interno al posto dell'origine NTP esterna. Un sistema che utilizza un proprio orologio può essere causato da un provider di servizi orari non valido. 
  
  
• La colonna t indica il tipo di trasmissione in uso: (l: locale; u: unicast; m: multicast o b: broadcast).
  
  
• La colonna quando indica quanti secondi sono trascorsi dall'ultimo polling del peer remoto. 
  
  
• La colonna poll indica l'intervallo di polling in secondi. Il valore di polling predefinito per IM&P è 64 secondi. Tuttavia, questo valore può essere impostato in un intervallo compreso tra 64 e 1.024 secondi. 

• La colonna reach indica la tendenza dei test di raggiungibilità nell'ottale, dove ogni cifra, quando convertita in formato binario, indica se un particolare polling ha avuto esito positivo (binario 1) o negativo (binario 0). Ad esempio, "1" significa che finora è stato fatto un solo sondaggio che ha avuto successo. "3" (= binario 11) significa che gli ultimi due sondaggi hanno avuto successo. "7" (= binario 111) significa che gli ultimi tre sondaggi hanno avuto successo. "17" ( = binario 1 111) significa che gli ultimi quattro sondaggi hanno avuto successo. "15" (= binario 1 101) significa che gli ultimi due sondaggi hanno avuto successo, il sondaggio precedente non ha avuto successo, e il sondaggio precedente ha avuto successo.

• Nella colonna delay viene visualizzato il ritardo di andata e ritorno per il peer remoto. Questo valore è determinato dalla misurazione del tempo che intercorre tra la richiesta e la risposta. 

• La colonna offset rappresenta la deviazione stimata tra l'orologio del server locale e quello del server remoto. 

• La colonna jitter fa riferimento alla variabilità del ritardo tra le richieste di polling. Un valore di jitter elevato limita la capacità del server di sincronizzare l'NTP in modo accurato.

Risoluzione dei problemi NTP

Diagnostica NTP CLI

I comandi elencati negli esempi vengono eseguiti dalla CLI di IM&P. Questi comandi forniscono un modo semplice per verificare che il peer NTP soddisfi gli standard Cisco. 

Suggerimento: tutti e tre i moduli di diagnostica vengono eseguiti, insieme a molti altri, quando l'utilità diagnostica il testviene utilizzato il comando

Il modulo diagnostico ntp_reachability esegue un test ping su tutti i peer NTP configurati. 

admin:utils diagnose module ntp_reachability

Log file: platform/log/diag2.log

Starting diagnostic test(s)
===========================
test - ntp_reachability : Passed

Diagnostics Completed

Il modulo di diagnostica ntp_clock_drift verifica che l'offset del peer NTP non superi i 15000 millisecondi.

admin:utils diagnose module ntp_clock_drift

Log file: platform/log/diag3.log

Starting diagnostic test(s)
===========================
test - ntp_clock_drift : Passed

Diagnostics Completed

Il modulo di diagnostica ntp_stratum verifica il valore dello strato NTP sulla IM&P. Questo test viene superato correttamente se lo strato NTP nell'editore CUCM ha un valore uguale o inferiore a 5 in quanto l'editore CUCM è l'origine NTP esterna per IM&P. 

admin:utils diagnose module ntp_stratum

Log file: platform/log/diag4.log

Starting diagnostic test(s)
===========================
test - ntp_stratum : Passed

Diagnostics Completed

SUGGERIMENTO: se il modulo ntp_stratum ha esito negativo sul sistema, consultare la sezione Requisiti per l'origine NTP di questo documento

Verifica della comunicazione e della versione NTP

NTP è un protocollo Client\Server che comunica tramite UDP (User Datagram Protocol) sulla porta 123. Per verificare la comunicazione NTP e la versione NTP, è necessario eseguire un'acquisizione pacchetti (pcap) sul server IM&P. 

SUGGERIMENTO: se l'IM&P invia le richieste NTP nel PCAP, non vi sono risposte NTP e la causa potrebbe essere un problema di rete. Raccogliere simultaneamente una capsula sul server CUCM e sul server IM&P per confermare che le richieste inviate da IM&P sono state ricevute dal lato CUCM. Conferma CUCM risponde anche alle richieste.

Il pacchetto acquisisce e visualizza una risposta del server NTP per ciascuna richiesta del client NTP. Nei messaggi Client\Server NTP viene visualizzata la versione NTP in uso. Verificare che la richiesta del client e la risposta del server utilizzino NTPv4. 

Eseguire il comando CLI per creare un'acquisizione di pacchetto sulla porta 123 utilizzando la porta 123 di Network Capture. Questo comando è lo stesso per IM&P o 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 di CUCM Publisher

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