Voix et communications unifiées : Cisco Unified Communications Manager (CallManager)

NTP dépannant sur Cisco Unified Communications Manager

18 octobre 2016 - Traduction automatique
Autres versions: PDFpdf | Anglais (22 août 2015) | Commentaires

Introduction

Ce document décrit comment dépanner des questions de Protocole NTP (Network Time Protocol) sur des Produits de Cisco Unified Communications Manager (CUCM) et de Cisco Unified Communications (UC).

Contribué par Vasanth Kumar K, ingénieur TAC Cisco.

Informations générales

CUCM exige que le NTP soit configuré afin de s'assurer :

  • Le temps sur les Noeuds CUCM sont synchronisés.
  • Le temps est correct avant n'importe quelle 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 dans la batterie.

Mécanisme de sondage de NTP dans des Produits UC

CUCM emploie la surveillance de NTP afin de maintenir le temps synchronisé avec le serveur de NTP. La surveillance de NTP périodiquement vote les serveurs externes configurés de NTP et redémarre le NTP si l'heure est compensée par plus de trois secondes.

Le démon de NTP corrige régulièrement le temps, mais sur une échelle de temps de milliseconde. Une reprise de NTP implique que vous exécutez un NTP unique afin d'exécuter une correction de temps brute et suivre avec une reprise du démon de NTP pour des micro-corrections régulières continues.

La surveillance de NTP vote le NTP une fois une minute sur le VMware et une fois toutes les 30 minutes sur les ordinateurs physiques. L'intervalle de sondage est abréviation le VMware parce que l'horloge dans des virtual machine (VMs) est moins stable que sur les ordinateurs et les caractéristiques physiques de VMware telles que VMotion, transfert de mémoire compromettent le temps.

Un noeud primaire qui fonctionne sur le VMware doit toujours être configuré afin de synchroniser avec les serveurs externes de NTP qui fonctionnent sur les ordinateurs physiques pour compenser le degré plus élevé de dérive de temps ou pour retarder dans une VM. Des Noeuds secondaires toujours sont automatiquement configurés pour mettre en référence le serveur primaire de NTP de noeud afin de s'assurer que tous les Noeuds dans la batterie sont étroits à temps.

La surveillance de NTP maintient le débit auquel elle redémarre le démon de NTP pour des corrections de temps brutes dues au VMware VMotions et aux transferts de mémoire. Si ce débit dépasse 10 reprises par heure, la surveillance de NTP remet d'autres reprises à plus tard jusqu'à ce que le débit exigé de reprises tombe en-dessous de 10 par heure. Le débit combiné de VMotions et de transferts de mémoire ne devrait pas dépasser 10 par heure, parce que ce débit est considéré excessif.

En raison de cette implémentation de surveillance de NTP, vous ne suivez pas l'intervalle entre deux invitations à émettre, qui est vu dans l'état de ntp d'utils. Une capture de renifleur a indiqué 8 balayages de NTP (échantillon) toutes les 60 secondes. C'est principalement parce que l'implémentation de NTP utilise la surveillance de NTP et comment le ntpdate vote le serveur de NTP dans l'implémentation UC.

Identifiez la version de NTP utilisée

Remarque: CUCM Publisher est configuré avec un serveur externe de NTP et l'abonné ajouté à la batterie synchronise à Publisher.

Remarque: La version 9.x et ultérieures CUCM exigent que le serveur NTPv4 soit configuré en tant que serveur préféré de NTP.

Exécutez une capture de renifleur afin d'identifier la version de NTP utilisée par le serveur configuré de NTP :

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 dans la réponse vous recevez un paquet NTPv3. Bien que NTPv4 soit rétrocompatible à NTPv3, l'implémentation CUCM du NTP varie, qui a comme conséquence le NTP non synchronisé :

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éparer la question, Cisco vous recommande utilisent un serveur externe de NTP de Linux ou le Cisco IOS® ou le serveur basé sur XE de NTP IOS et s'assurent que NTPv4 est configuré.

Voici une description de la terminologie de NTP dans l'état de NTP sorti :

  • La colonne de refid indique la source temporelle du distant. LOCAL(0) est l'horloge de matériel local. .INIT signifie que l'initialisation n'a pas encore réussi.

  • La colonne St est la strate du serveur distant de NTP. 16 est une valeur non valide de strate qui signifie que « ce serveur n'est pas considéré un fournisseur de temps ». La strate peut être non valide pour différentes raisons, le plus commun dont est que le « fournisseur de temps non synchronisé », « la source configurée n'existe pas », ou le « serveur de ntp ne s'exécutant pas ».

  • La colonne t indique le type de serveur (l : gens du pays ; u : unicast ; m : Multidiffusion, ou b : émission).

  • Quand la colonne indique il y a combien de secondes le distant a été questionné.

  • La colonne de balayage indique l'intervalle de sondage en quelques secondes. Par exemple, "64" signifie que le distant est voté toutes les 64 secondes. Les utilisations de NTP d'intervalle les plus courtes est toutes les 64 secondes et le plus long est de 1,024 secondes. Plus un ntp source est évalué au fil du temps mieux, plus l'intervalle est long. (L'implémentation UC ne suit pas l'intervalle défini ici.)

  • La colonne de portée indique la tendance des tests d'accessibilité dans octal, où chaque chiffre, une fois converti en binaire, représente si un balayage particulier était réussi (binaire 1) ou infructueux (binaire 0). Par exemple, "1" signifie que seulement un balayage a été fait jusqu'ici et il était réussi. "3" (= binaire 11) signifie que les deux derniers balayages étaient réussis. "7" (= binaire 111) signifie que les trois derniers balayages étaient réussis. "17" (= binaire 1 111) signifie que les quatre derniers balayages étaient réussis. "15" (= binaire 1 101) signifie que les deux derniers balayages étaient réussis, le balayage avant celui était infructueux, et le balayage avant celui était réussi.

  • Le retard, le décalage, et les colonnes de jitter sont le délai d'aller-retour, la dispersion, et le jitter en quelques millisecondes.

Diagnostiquez les questions liées à la ntp dans CUCM

Terminez-vous ces étapes afin de diagnostiquer les questions liées à la ntp :

  1. Assurez-vous que CUCM peut communiquer avec le serveur de NTP sur le port 123.

  2. Obtenez la sortie de l'état de ntp d'utils.

    • La strate de niveau devrait être moins de 4 sur l'éditeur pour des performances optimales
    • Si de plusieurs serveurs de NTP sont configurés, assurez au moins sur le serveur est accessible ; vous devriez voir (*) le symbole contre le serveur de NTP utilisé comme référence par CUCM.


  3. Passez en revue l'alarme de Syslog et agissez en conséquence. Les causes probables des alarmes de Syslog sont :

    • Le serveur externe de NTP n'est pas accessible.
    • La strate de NTP est supérieur à la limite acceptable.
    • Publisher est vers le bas, ainsi le NTP d'abonné est non synchronisé.
    • Si ntpdate - des alertes associées par q sont vues, il est possible que vous ayez la version 4.2.6+ de NTP avec la fonction activée de coup de grâce (KoD). (Par conception, l'intervalle minimum entre la rafale et des paquets d'iburst envoyés par n'importe quel client est deux, qui ne viole pas cette contrainte. Paquets envoyés par d'autres réalisations qui violent cette contrainte seront abandonnées et un paquet de KoD retourné, si activé). Il est recommandé pour désactiver cette configuration quand vous utilisez cette version en tant que serveur de NTP pour un produit UC.


  4. Utilisez ce module de diagnostic afin de vérifier le serveur de NTP est configuré.

    • les utils diagnostiquent le ntp_reachability de module
    • les utils diagnostiquent le ntp_clock_drift de module
    • les utils diagnostiquent le ntp_stratum de module


  5. Écrivez la reprise de ntp d'utils afin de redémarrer le client/serveur de NTP. Cette commande est utile toutes les fois qu'une correction de temps brute doit se produire immédiatement ou toutes les fois que les serveurs externes sont encore accessibles et opérationnels, mais la synchronisation échoue. Employez la commande NTP status d'utils afin de déterminer l'état opérationnel des serveurs externes de NTP.

Problèmes connus communs avec l'association de NTP sur CUCM

ID de bogue Cisco CSCue18813 : Paramètre de « maxdist de tos » de configuration de NTP commandé par l'intermédiaire du CLI

Résolution : Le cas de centre d'assistance technique Cisco devrait être augmenté afin d'ajouter manuellement le paramètre de maxdist de tos dans le fichier ntp.conf.

ID de bogue Cisco CSCuq70611 : Le test de strate de NTP ne valide pas correctement avec le serveur simple de NTP

Version corrigée : 10.5(2.10000.005)

ID de bogue Cisco CSCui85967 : La mise à jour d'accès CUCM de 6.1.5 à 9.1.2 échoue en raison des disparus de référence de NTP

Résolution : La documentation de mise à jour d'accès a été mise à jour et la configuration de NTP est répertoriée en tant qu'en fonction de la tâche de pré-mise à jour.

ID de bogue Cisco CSCtw46611 :  La synchronisation de NTP échoue en raison de l'écriture de labels incorrecte de système de fichiers de capture.txt

Version corrigée : 8.6(2.24900.017)

ID de bogue Cisco CSCur94973 : Betn VMHost de question de synchronisation horaire et exemple VM pendant le transfert M1

Résolution : Désactivez le sync du NTP de la VM avec l'hôte d'ESXi avec l'utilisation de ce contournement. Un contournement alternatif est de configurer le serveur et le CUCM Publisher d'ESXi pour indiquer le même serveur de NTP. 



Document ID: 118718