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 de bien comprendre le protocole NTP et l'interface de ligne de commande (CLI) IM&P avant de passer en revue ce document.
Exigences
Il n'existe aucune configuration matérielle ou logicielle spécifique requise pour ce document.
Composants utilisés
Les informations contenues dans ce document sont basées sur la GI&P.
Remarque : la plupart de ces informations s'appliquent également à d'autres plates-formes de communications unifiées (UC). Toutefois, le présent document se concentre sur la GI&P.
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.
NTP sur IM&P expliqué
Le serveur de publication Cisco Unified Communications Manager (CUCM) est la source NTP pour IM&P. IM&P utilise le chien de garde NTP pour synchroniser l'heure avec le serveur de publication CUCM. Pour les plates-formes IM&P qui se trouvent sur une machine virtuelle, le NTP Watchdog interroge l'éditeur CUCM 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.
Remarque : NTP Watchdog surveille le nombre de redémarrages du démon NTP au cours de la dernière heure. Si plus de 10 redémarrages de démon NTP ont lieu dans l'heure, les redémarrages ultérieurs sont brièvement reportés.
Configuration requise pour 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 du serveur de publication CUCM. 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 Éditeur CUCM DOIVENT être NTP v4 pour éviter les problèmes potentiels de compatibilité, de précision et de gigue réseau. La version 4 de NTP 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 de NTP.
Avertissement : l'utilisation des services de temps Windows comme serveur NTP n'est pas prise en charge. Les services de temps Windows utilisent souvent le protocole SNTP (Simple Network Time Protocol) et CUCM ne peut pas se synchroniser avec SNTP.
Remarque : toutes les exigences NTP sont clairement indiquées dans le SRND Cisco Collaboration System.
Explication de la sortie NTP Status
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 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
Voici les descriptions des colonnes affichées dans la sortie d'état NTP
- La colonne remote définit l'homologue distant où l'heure est synchronisée. Si elle est définie sur LOCAL, l'horloge matérielle locale est utilisée.
- La colonne refid définit la source de temps du serveur distant. Si la valeur est .LOCL, l'horloge matérielle locale du serveur distant est référencée. Si la valeur est .INIT, l'initialisation n'a pas encore réussi.
- La st colonne indique la strate de l'homologue NTP distant. Quand une valeur de 16 est dans la colonne strate cela signifie que le système utilise l'horloge interne au lieu de la source NTP externe. Un système qui utilise 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 : unicast ; m : multicast ou b : broadcast).
- 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 n'importe où entre 64 et 1 024 secondes.
- La colonne reach indique la tendance des tests d'accessibilité en octal, où chaque chiffre, une fois converti en binaire, représente 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'ici et qu'il a été couronné de succès. "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 mesure du temps entre la demande et la réponse.
- La colonne offset est l'écart estimé entre l'horloge des serveurs locaux et l'horloge des serveurs distants.
- La colonne jitter 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 CLI NTP
Les commandes répertoriées dans les exemples sont exécutées à partir de l'interface de ligne de commande d'IM&P. Ces commandes constituent un moyen simple de confirmer que l'homologue NTP répond aux normes Cisco.
Conseil : ces trois modules de diagnostic s'exécutent, ainsi que plusieurs autres, lorsque le test de diagnostic utilsest 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 d'homologue NTP ne dépasse pas 15000 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 la strate NTP sur l'IM&P. Ce test réussit si la strate NTP sur le serveur de publication CUCM a une valeur inférieure ou égale à 5 car le serveur de publication 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 tombe en panne sur votre système, consultez la section Spécifications pour 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 de NTP, vous devez effectuer une capture de paquets (pcap) sur le serveur IM&P.
CONSEIL : si vous voyez l'IM&P envoyer des requêtes NTP dans le pcap ; cependant, il n'y a pas de réponses NTP et un problème de réseau est probablement la cause. Rassembler 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 requêtes.
Les captures de paquets affichent une réponse de serveur NTP pour chaque requête de client NTP. Le message NTP Client\Server affiche 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 utils network capture port 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
Commentaires