Sommario

Introduzione

Premesse

Meccanismo di polling NTP nei prodotti UC

Identifica versione NTP utilizzata

Diagnosi dei problemi relativi a NTP in CUCM

Problemi comuni noti con l'associazione NTP su CUCM

Introduzione

In questo documento viene descritto come risolvere i problemi relativi al Network Time Protocol (NTP) sui prodotti Cisco Unified Communications Manager (CUCM) e Cisco Unified Communications (UC).

Premesse

CUCM richiede che NTP sia configurato per garantire:

- Tempo di sincronizzazione dei nodi CUCM.

- 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 per 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 la migrazione dello storage influiscono negativamente sul tempo.

È sempre necessario configurare un nodo primario in esecuzione su VMware per eseguire la sincronizzazione con i server NTP esterni in esecuzione su computer fisici, in modo da 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 deve 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 ntp utils. 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 alla modalità di polling del server NTP da parte di ntpdate nell'implementazione UC.

Identifica versione NTP utilizzata

Nota: Il server di pubblicazione CUCM è 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 richiedono 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 in risposta si riceve un pacchetto NTPv3. Sebbene NTPv4 sia compatibile con NTPv3 nelle versioni precedenti, l'implementazione CUCM dell'NTP varia, con conseguente NTP non 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 basato su Cisco IOS® o IOS XE 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 prima colonna è lo strato del server NTP remoto. 16 è un valore di strato non valido che significa "questo 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 di 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 viene eseguito il polling del telecomando ogni 64 secondi. L'intervallo più breve utilizzato da NTP è ogni 64 secondi e quello più lungo è 1.024 secondi. Maggiore è 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à 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, quello precedente non ha avuto successo, e quello 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:

1. Verificare che CUCM sia in grado di comunicare con il server NTP sulla porta 123.

2. Ottenere l'output dello stato ntp dell'utilità.

- Per prestazioni ottimali, il livello di stratum deve essere inferiore a 4 nel server di pubblicazione

- Se sono configurati più server NTP, verificare che almeno un server sia raggiungibile; dovrebbe essere visualizzato il simbolo (*) sul server NTP utilizzato come riferimento da CUCM.

3. Rivedere l'allarme syslog e agire di conseguenza. Le possibili cause degli allarmi 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+ con la funzione Kiss of Death (KoD) abilitata. (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 verranno eliminati e verrà restituito un pacchetto KoD, se abilitato). Si consiglia di disattivare questa funzione quando si utilizza tale versione come server NTP per un prodotto UC.

4. 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

5. 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: Parametro di configurazione NTP "tos maxdist" controllato tramite CLI

Risoluzione: È necessario sollevare il caso di 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 con un singolo server NTP

Versione fissa: 10.5(2.10000.005)

ID bug Cisco CSCui85967: L'aggiornamento a CUCM dalla versione 6.1.5 alla 9.1.2 non riesce a causa di un riferimento NTP mancante

Risoluzione: La documentazione sull'aggiornamento Jump è stata aggiornata e la configurazione NTP è elencata come una delle attività precedenti all'aggiornamento.

ID bug Cisco CSCtw4611:  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.