Dépannage de NTP sur IM&P

Introduction

Ce document décrit comment dépanner la synchronisation NTP (Network Time Protocol) sur IM and Presence (IM&P).

Conditions préalables

Cisco vous recommande d'avoir une compréhension de base de NTP et de l'interface de ligne de commande (CLI) IM&P avant de passer en revue ce document.

Conditions requises

Il n'y a aucune configuration matérielle ou logicielle spécifique pour ce document.

Components Used

Les informations contenues dans ce document sont basées sur IM&P.

Note: Une grande partie de ces informations s'appliquent également à d'autres plates-formes de communications unifiées (UC) ; toutefois, le présent document est axé sur la GI-P.

Les informations contenues dans ce document ont été créées à partir des périphériques dans un environnement de laboratoire spécifique. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

NTP sur IM&P expliqué

Cisco Unified Communications Manager (CUCM) Publisher est la source NTP de IM&P. IM&P utilise le chien de garde NTP pour synchroniser l'heure avec CUCM Publisher. Pour les plates-formes IM&P qui se trouvent sur une machine virtuelle, NTP Watchdog interroge CUCM Publisher une fois toutes les 64 secondes par défaut. Si le décalage NTP est supérieur à trois secondes, le démon NTP redémarre lui-même.

Note: NTP Watchdog surveille le nombre de fois où le démon NTP a redémarré au cours de la dernière heure. Si plus de 10 redémarrages de démon NTP se produisent dans l'heure, les redémarrages supplémentaires sont brièvement reportés.

Exigences relatives à la source NTP

Cisco recommande vivement l'utilisation d'un serveur NTP Stratum 1, Stratum 2 ou Stratum 3 comme référence NTP externe de CUCM Publisher. Toute source NTP pour l'éditeur CUCM NE DOIT PAS être supérieure à la strate 4.

Les serveurs NTP externes définis pour le noeud serveur de publication CUCM DOIVENT être NTP v4 pour éviter des problèmes potentiels de compatibilité, de précision et de gigue réseau. NTP version 4 est rétrocompatible avec la version 3 ; cependant, de nombreux problèmes ont été observés lors de tentatives d'utilisation de différentes versions NTP.

Avertissement : L'utilisation de Windows Time Services en tant que serveur NTP n'est pas prise en charge. Souvent, Windows Time Services utilise le protocole SNTP (Simple Network Time Protocol) et CUCM ne peut pas se synchroniser avec SNTP.

Note: Toutes les exigences NTP ci-dessus sont clairement indiquées dans le système de collaboration Cisco SRND. 

Explication de sortie du statut NTP

Pour déterminer l'état actuel de NTP sur IM&P, exécutez la commande utils ntp status à partir de l'interface de ligne de commande du serveur 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     172.32.16.15   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
   polling 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

Ci-dessous sont décrites les colonnes affichées dans le résultat d'état NTP

• La colonne distante définit l'homologue distant à partir duquel le temps est synchronisé. Si la valeur est LOCAL, l'horloge matérielle locale est utilisée. 

• La colonne refid définit la source temporelle du serveur distant. Si défini sur .LOCL. ensuite, l'horloge matérielle locale sur le serveur distant est référencée. Si défini sur .INIT. l'initialisation n'a pas encore réussi.
  
  
• La première colonne indique la strate de l'homologue NTP distant. Lorsqu'une valeur de 16 est dans la colonne de strate, cela signifie que le système utilise l'horloge interne au lieu de la source NTP externe. Un système utilisant sa propre horloge peut être causé par un fournisseur de temps non valide. 
  
  
• La colonne t indique le type de transmission utilisé : (l : local ; u : monodiffusion ; m : multicast, ou b : ).
  
  
• La colonne when indique le nombre de secondes écoulées depuis la dernière interrogation de l'homologue distant. 
  
  
• La colonne d'interrogation indique l'intervalle d'interrogation en secondes. La valeur d'interrogation par défaut sur IM&P est de 64 secondes. Cependant, cette valeur peut être définie entre 64 et 1 024 secondes. 

• La colonne reach indique la tendance des tests d'accessibilité octal, où chaque chiffre, lorsqu'il est converti en binaire, indique si un sondage particulier a réussi (binaire 1) ou échoué (binaire 0). Par exemple, « 1 » signifie qu'un seul sondage a été effectué jusqu'à présent et qu'il a réussi. « 3 » (= binaire 11) signifie que les deux derniers sondages ont réussi. « 7 » (= binaire 111) signifie que les trois derniers sondages ont réussi. « 17 » ( = binaire 1 111) signifie que les quatre derniers sondages ont réussi. « 15 » (= binaire 1 101) signifie que les deux derniers sondages ont réussi, que le sondage précédent a échoué et que le sondage précédent a réussi.

• La colonne delay affiche le délai aller-retour vers l'homologue distant. Cela est déterminé par la surveillance du temps passé entre la demande et la réponse. 

• La colonne offset représente l'écart estimé entre l'horloge des serveurs locaux et l'horloge des serveurs distants. 

• La colonne gigue fait référence à la variabilité du délai entre les demandes d'interrogation. Une valeur de gigue élevée limite la capacité du serveur à synchroniser NTP avec précision.

Dépannage NTP

Diagnostics NTP CLI

Les commandes répertoriées dans les exemples ci-dessous sont exécutées à partir de l'interface de ligne de commande de IM&P. Ces commandes fournissent un moyen simple de confirmer que l'homologue NTP répond aux normes Cisco. 

Astuce : Ces trois modules de diagnostic s'exécutent, ainsi que plusieurs autres, lorsque les tests de diagnostic de l'utilitairecommande utilisée

Le module de diagnostic ntp_reachability effectue un test ping sur tous les homologues NTP configurés. 

admin:utils diagnose module ntp_reachability

Log file: platform/log/diag2.log

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

Diagnostics Completed

Le module de diagnostic ntp_clock_drift vérifie que le décalage de dérive des homologues NTP ne dépasse pas 15 000 millisecondes.

admin:utils diagnose module ntp_clock_drift

Log file: platform/log/diag3.log

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

Diagnostics Completed

Le module de diagnostic ntp_stratum vérifie la valeur de strate NTP sur IM&P. Ce test ne réussira que si la strate NTP sur le serveur de publication CUCM a une valeur égale ou inférieure à 5, car l'éditeur CUCM est la source NTP externe pour IM&P. 

admin:utils diagnose module ntp_stratum

Log file: platform/log/diag4.log

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

Diagnostics Completed

CONSEIL : Si le module ntp_stratum est défectueux sur votre système, consultez la section Exigences relatives à la source NTP de ce document

Vérification de la communication et de la version NTP

NTP est un protocole client\serveur qui communique via le protocole UDP (User Datagram Protocol) sur le port 123. Pour vérifier la communication NTP et la version NTP, vous devez effectuer une capture de paquets (pcap) sur le serveur IM&P. 

CONSEIL : Si vous voyez que IM&P envoie des requêtes NTP dans pcap ; cependant, il n’y a pas de réponse NTP. Un problème réseau peut être la cause. Collecter simultanément un pcap sur le serveur CUCM et le serveur IM&P pour confirmer que les requêtes envoyées par IM&P sont reçues du côté CUCM. Confirmez que CUCM répond également aux demandes.

Les captures de paquets doivent afficher une réponse de serveur NTP pour chaque requête de client NTP. Les messages NTP Client\Server affichent la version NTP utilisée. Vérifiez que la requête du client et la réponse du serveur utilisent NTPv4. 

Exécutez la commande CLI jusqu'au port de capture réseau 123 pour créer une capture de paquets sur le port 123. Cette commande est identique pour IM&P ou 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 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