Introduction
Ce document décrit comment dépanner les problèmes de protocole NTP (Network Time Protocol) sur les produits Cisco Unified Communications (UC).
Conditions préalables
Exigences
Aucune exigence spécifique n'est associée à ce document.
Composants utilisés
Ce document n'est pas limité à des versions de matériel et de logiciel spécifiques.
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.
Informations générales
Cisco Unified Communications Manager (CUCM) nécessite la configuration de NTP afin de garantir :
- L'heure sur les noeuds CUCM est synchronisée.
- L'heure est correcte avant toute modification de configuration sensible au temps, telle que la régénération de certificat.
- La réplication de base de données est synchronisée sur tous les noeuds du cluster.
Mécanisme d'interrogation NTP dans les produits UC
CUCM utilise le chien de garde NTP afin de garder l'heure synchronisée avec le serveur NTP. Le chien de garde NTP interroge régulièrement le ou les serveurs NTP externes configurés et redémarre NTP si l'heure est décalée de plus de trois secondes.
Le démon NTP corrige régulièrement le temps, mais sur une échelle de temps de millisecondes. Un redémarrage de NTP implique que vous exécutez un one-shot NTP afin d'effectuer une correction de temps brut et de suivre avec un redémarrage du démon NTP pour continuer les micro-corrections régulières.
NTP Watchdog interroge NTP une fois par minute sur VMware et une fois toutes les 30 minutes sur les machines physiques. L'intervalle d'interrogation est plus court pour VMware, car l'horloge des machines virtuelles (VM) est moins stable que celle des machines physiques, et les fonctionnalités VMware telles que VMotion et la migration du stockage ont un impact négatif sur le temps.
Un noeud principal qui s'exécute sur VMware doit toujours être configuré afin de se synchroniser avec les serveurs NTP externes qui s'exécutent sur une ou plusieurs machines physiques pour compenser le plus haut degré de dérive de temps ou de retard dans une machine virtuelle. Les noeuds secondaires sont toujours automatiquement configurés pour référencer le serveur NTP du noeud principal afin de s'assurer que tous les noeuds du cluster sont proches dans le temps.
NTP Watchdog garde une trace de la vitesse à laquelle il redémarre le démon NTP pour les corrections de temps brut dues à VMotions VMware et aux migrations de stockage. Si ce taux est supérieur à 10 redémarrages par heure, NTP Watchdog reporte les redémarrages jusqu'à ce que le taux de redémarrages requis soit inférieur à 10 par heure. Le taux combiné de VMotions et de migrations de stockage ne peut pas dépasser 10 par heure, car ce taux est considéré comme excessif.
En raison de cette implémentation NTP Watchdog, vous ne suivez pas l'intervalle d'interrogation, qui est vu dans l'état ntp utils. Une capture de renifleur a révélé 8 sondages NTP (échantillon) toutes les 60 secondes. Cela est principalement dû au fait que l'implémentation NTP utilise NTP Watchdog et à la manière dont ntpdate interroge le serveur NTP dans l'implémentation UC.
Identifier la version NTP utilisée
Remarque : CUCM Publisher est configuré avec un serveur NTP externe et l'abonné ajouté au cluster est synchronisé avec le serveur de publication.
Remarque : CUCM version 9.x et ultérieure nécessite que le serveur NTPv4 soit configuré en tant que serveur NTP préféré.
Exécutez une capture de renifleur afin d'identifier la version NTP utilisée par le serveur NTP configuré :
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 envoie un paquet NTPv4 et en réponse, vous recevez un paquet NTPv3. Bien que NTPv4 soit rétrocompatible avec NTPv3, l'implémentation CUCM de NTP varie, ce qui entraîne une non-synchronisation de NTP :
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
Afin de résoudre le problème, Cisco vous recommande d'utiliser un serveur NTP externe basé sur Linux ou un serveur NTP Cisco IOS® ou Cisco IOS® XE et de vous assurer que NTPv4 est configuré.
Voici une description de la terminologie NTP dans la sortie d'état NTP :
- La colonne affinée indique la source temporelle de la télécommande. LOCAL(0) est l'horloge matérielle locale. .INIT. signifie que l'initialisation n'a pas encore réussi.
- La première colonne est la strate du serveur NTP distant. 16 est une valeur de strate non valide, ce qui signifie que ce serveur n'est pas considéré comme un fournisseur de temps. La strate peut être invalide pour diverses raisons. Le plus courant est que le fournisseur de temps n'est pas synchronisé, que la source configurée n'existe pas ou que le serveur ntp n'est pas en cours d'exécution.
- La colonne t indique le type de serveur (l : local ; u : unicast ; m : multicast ou b : broadcast).
- La colonne When indique la durée en secondes de l'interrogation de la télécommande.
- La colonne de sondage indique l'intervalle de sondage en secondes. Par exemple, 64 signifie que la télécommande est interrogée toutes les 64 secondes. L'intervalle le plus court que NTP utilise est toutes les 64 secondes et le plus long est de 1 024 secondes. Mieux une source NTP est évaluée au fil du temps, plus l'intervalle est long. (L'implémentation des communications unifiées ne suit pas l'intervalle défini ici.)
- 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'à présent 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. Le sondage précédent a été un échec, et le sondage précédent a été un succès.
- Les colonnes de délai, de décalage et d'instabilité correspondent au délai aller-retour, à la dispersion et à l'instabilité en millisecondes.
Diagnostiquer les problèmes liés au protocole NTP dans CUCM
Complétez ces étapes afin de diagnostiquer les problèmes liés au NTP :
- Vérifiez que CUCM peut communiquer avec le serveur NTP sur le port 123.
- Obtenez le résultat de l’état ntp utils.
- Le niveau de strate peut être inférieur à 4 sur l'éditeur pour des performances optimales.
- Si plusieurs serveurs NTP sont configurés, assurez-vous qu'au moins un serveur est accessible ; vous pouvez voir le symbole (*) en regard du serveur NTP utilisé comme référence par CUCM.
- Vérifiez l'alarme syslog et prenez les mesures appropriées. Les causes probables des alarmes Syslog sont les suivantes :
- Le serveur NTP externe n'est pas accessible.
- La strate NTP est supérieure à la limite acceptable.
- Le serveur de publication est hors service, le protocole NTP de l'abonné n'est donc pas synchronisé.
- Si des alertes liées à ntpdate -q sont détectées, il est possible que vous ayez NTP version 4.2.6+ avec la fonctionnalité Kiss of Death (KoD) activée. (Par conception, l'intervalle minimum entre les paquets en rafale et en iburst envoyés par n'importe quel client est de deux, ce qui ne viole pas cette contrainte. Les paquets envoyés par d'autres implémentations qui violent cette contrainte peuvent être abandonnés et un paquet KoD retourné s'il est activé). Il est recommandé de désactiver cette fonctionnalité lorsque vous utilisez cette version comme serveur NTP pour un produit de communications unifiées.
- Utilisez ce module de diagnostic afin de vérifier que le serveur NTP est configuré.
- utils diagnose module ntp_reachability
- utils diagnose module ntp_clock_drift
- utils diagnose module ntp_stratum
- Entrez utils ntp restart afin de redémarrer le client/serveur NTP. Cette commande est utile lorsqu'une correction du temps brut doit être effectuée immédiatement ou lorsque des serveurs externes sont toujours accessibles et opérationnels, mais que la synchronisation échoue. Utilisez la commande utils ntp status afin de déterminer l'état opérationnel des serveurs NTP externes.
Problèmes courants connus avec l'association NTP sur CUCM
ID de bogue Cisco CSCue18813 : paramètre de configuration NTP tos maxdist contrôlé via l'interface de ligne de commande
Résolution : le cas du centre d'assistance technique Cisco peut être soulevé afin d'ajouter manuellement le paramètre tos maxdist dans le fichier ntp.conf.
ID de bogue Cisco CSCuq70611 : le test de strate NTP ne se valide pas correctement avec un seul serveur NTP
Version fixe : 10.5(2.10000.005)
ID de bogue Cisco CSCui85967 : la mise à niveau de saut CUCM de 6.1.5 à 9.1.2 échoue en raison d'une référence NTP manquante
Résolution : la documentation de mise à niveau de saut a été mise à jour et la configuration NTP est répertoriée comme l'une des tâches préalables à la mise à niveau.
Bogue Cisco ayant l'ID CSCtw4611 : la synchronisation NTP échoue en raison d'un libellé de système de fichiers incorrect de capture.txt
Version fixe : 8.6(2.24900.017)
Bogue Cisco ayant l'ID CSCur94973 : problème de synchronisation temporelle entre VMHost et l'instance de VM pendant la migration de M1
Résolution : désactivez la synchronisation NTP de la machine virtuelle avec l'hôte ESXi à l'aide de cette solution. Une autre solution consiste à configurer le serveur ESXi et le serveur de publication CUCM pour qu'ils pointent vers le même serveur NTP.
Commentaires