Introduzione
Questo documento descrive come risolvere i problemi relativi al Network Time Protocol (NTP) sui prodotti Cisco Unified Communications (UC).
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.
Premesse
Cisco Unified Communications Manager (CUCM) richiede la configurazione del protocollo NTP per garantire:
- L'ora sui nodi CUCM è sincronizzata.
- L'ora è corretta prima di qualsiasi modifica della configurazione che influisca sull'ora, ad esempio la rigenerazione dei certificati.
- La replica di database è sincronizzata in tutti i nodi del cluster.
Meccanismo di polling NTP nei prodotti UC
CUCM utilizza il watchdog NTP per mantenere l'ora sincronizzata con il server NTP. Il watchdog NTP effettua periodicamente il polling dei server NTP esterni configurati e riavvia NTP se il tempo è sfalsato di oltre tre secondi.
Il daemon NTP corregge regolarmente il tempo, ma su una scala temporale di millisecondi. Un riavvio dell'NTP implica l'esecuzione di un one-shot NTP al fine di eseguire una correzione del tempo lordo e seguire un riavvio del daemon NTP per continuare le micro-correzioni regolari.
NTP Watchdog effettua un sondaggio NTP una volta al minuto su VMware e una volta ogni 30 minuti su computer fisici. L'intervallo di polling è più breve per VMware in quanto il clock delle macchine virtuali (VM) è meno stabile rispetto a quello delle macchine fisiche e le funzionalità di VMware, quali VMotion e Storage Migration, influiscono negativamente sul tempo.
Un nodo primario in esecuzione su VMware deve sempre essere configurato per sincronizzarsi con i server NTP esterni in esecuzione su una o più macchine fisiche per compensare il maggiore ritardo o scostamento di tempo in una VM. I nodi secondari sono sempre configurati automaticamente per fare riferimento al server NTP del nodo primario in modo da garantire che tutti i nodi all'interno del cluster siano vicini nel tempo.
NTP Watchdog tiene traccia della frequenza con cui riavvia il daemon NTP per le correzioni del tempo lordo dovute a VMotions VMWare e migrazioni dello storage. Se questa frequenza supera i 10 riavvii all'ora, NTP Watchdog posticipa ulteriori riavvii fino a quando la frequenza di riavvii richiesta non scende al di sotto di 10 all'ora. La velocità combinata di VMotions e migrazioni dello storage non può superare il 10% all'ora, in quanto è considerata eccessiva.
A causa di questa implementazione di NTP Watchdog, non si segue l'intervallo di polling, che è visualizzato nello stato utils ntp. Una cattura di sniffer ha rivelato 8 sondaggi NTP (campione) ogni 60 secondi. Ciò è dovuto principalmente al fatto che l'implementazione NTP utilizza NTP Watchdog e al modo in cui ntpdate esegue il polling del server NTP nell'implementazione UC.
Identifica la versione NTP utilizzata
Nota: CUCM Publisher è configurato con un server NTP esterno e il sottoscrittore aggiunto al cluster esegue la sincronizzazione con il server di pubblicazione.
Nota: CUCM versione 9.x e successive richiede che il server NTPv4 sia configurato come server NTP preferito.
Eseguire un'acquisizione sniffer per identificare la versione NTP utilizzata dal server NTP configurato:
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 invia un pacchetto NTPv4 e, di conseguenza, l'utente riceve un pacchetto NTPv3. Sebbene NTPv4 sia compatibile con NTPv3 nelle versioni precedenti, l'implementazione CUCM dell'NTP varia e di conseguenza l'NTP non viene sincronizzato:
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
Per risolvere il problema, Cisco consiglia di utilizzare un server NTP esterno basato su Linux o un server NTP Cisco IOS® o Cisco IOS® XE NTP e di verificare che NTPv4 sia configurato.
Di seguito è riportata una descrizione della terminologia NTP nell'output dello stato NTP:
- La colonna refid indica l'origine ora del telecomando. LOCAL(0) è l'orologio hardware locale. .INIT. indica che l'inizializzazione non è stata ancora completata.
- La colonna st è lo strato del server NTP remoto. 16 è un valore di strato non valido, ovvero il server non è considerato un provider di servizi orari. Lo strato può non essere valido per vari motivi. Il più comune dei quali è che il provider servizi orari non è sincronizzato, l'origine configurata non esiste o il server ntp non è in esecuzione.
- La colonna t indica il tipo di server (l: locale; u: unicast; m: multicast o b: broadcast).
- La colonna quando indica quanti secondi fa è stata eseguita una query sul telecomando.
- La colonna poll indica l'intervallo di polling in secondi. Ad esempio, 64 significa che il polling del telecomando viene eseguito ogni 64 secondi. L'intervallo più breve utilizzato da NTP è ogni 64 secondi e quello più lungo è 1.024 secondi. Migliore è la classificazione di una fonte NTP nel tempo, maggiore è l'intervallo. (l'implementazione UC non segue l'intervallo definito qui).
- La colonna reach indica la tendenza dei test di raggiungibilità in ottale, dove ogni cifra, quando convertita in binario, indica se un particolare sondaggio ha avuto successo (binario 1) o se ha avuto esito negativo (binario 0). Ad esempio, 1 indica che finora è stato fatto un solo sondaggio, che ha avuto esito positivo. 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) indica 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.
- Le colonne delay, offset e jitter rappresentano il ritardo di andata e ritorno, la dispersione e il jitter in millisecondi.
Diagnosi dei problemi relativi a NTP in CUCM
Completare questi passaggi per diagnosticare i problemi relativi all'NTP:
- Verificare che CUCM sia in grado di comunicare con il server NTP sulla porta 123.
- Ottenere l'output dello stato utils ntp.
- Il livello di strato può essere inferiore a 4 sul publisher per prestazioni ottimali.
- Se sono configurati più server NTP, accertarsi che almeno un server sia raggiungibile; è possibile visualizzare il simbolo (*) sul server NTP utilizzato come riferimento da CUCM.
- Rivedere l'allarme syslog e agire di conseguenza. Le possibili cause degli allarmi del syslog sono:
- Server NTP esterno non raggiungibile.
- Lo strato NTP è superiore al limite accettabile.
- Il server di pubblicazione non è attivo, quindi il protocollo NTP del Sottoscrittore non è sincronizzato.
- Se vengono rilevati allarmi relativi a ntpdate -q, è possibile che NTP versione 4.2.6+ sia attivato con la funzione Kiss of Death (KoD). (per impostazione predefinita, l'intervallo minimo tra i pacchetti burst e burst inviati da qualsiasi client è due, il che non viola questo vincolo. I pacchetti inviati da altre implementazioni che violano questo vincolo possono essere scartati e, se abilitato, restituito un pacchetto KoD. Si consiglia di disattivare questa funzione quando si utilizza tale versione come server NTP per un prodotto UC.
- Utilizzare questo modulo diagnostico per verificare che il server NTP sia configurato.
- utilizza il modulo di diagnostica ntp_reachability
- utilizza il modulo di diagnostica ntp_clock_drift
- utilizza il modulo di diagnostica ntp_stratum
- Immettere utils ntp restart per riavviare il client/server NTP. Questo comando è utile ogni volta che è necessario eseguire immediatamente una correzione dell'ora lorda o ogni volta che i server esterni sono ancora raggiungibili e operativi, ma la sincronizzazione non riesce. Per determinare lo stato operativo dei server NTP esterni, usare il comando utils ntp status.
Problemi comuni noti con l'associazione NTP su CUCM
ID bug Cisco CSCue18813: configurazione NTP per il parametro maxdist controllato tramite CLI
Risoluzione: è possibile sollevare il caso Cisco Technical Assistance Center per aggiungere manualmente il parametro tos maxdist nel file ntp.conf.
ID bug Cisco CSCuq70611: il test NTP Stratum non viene convalidato correttamente su un singolo server NTP
Versione fissa: 10.5(2.1000.005)
ID bug Cisco CSCui85967: impossibile aggiornare il collegamento CUCM dalla versione 6.1.5 alla 9.1.2. Riferimento NTP mancante
Risoluzione: la documentazione relativa all'aggiornamento Jump è stata aggiornata e la configurazione NTP è elencata come una delle attività precedenti all'aggiornamento.
ID bug Cisco CSCtw46611: la sincronizzazione NTP non riesce a causa di un'etichettatura errata del file system di capture.txt
Versione fissa: 8.6(2.24900.017)
ID bug Cisco CSCur94973: problema di sincronizzazione temporale tra host VMH e istanza VM durante la migrazione a M1
Risoluzione: disabilitare la sincronizzazione NTP della VM con l'host ESXi utilizzando questa soluzione alternativa. Una soluzione alternativa consiste nel configurare il server ESXi e CUCM Publisher in modo che puntino allo stesso server NTP.
Feedback