Configuration et dépannage du protocole NTP sur CUCM et IM&P

Introduction

Ce document décrit le protocole NTP (Network Time Protocol) pour Cisco Unified Communications Manager (CUCM). 

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.

Objectif de la fonctionnalité

Ce document couvre l'objectif du protocole NTP avec CUCM, la configuration du protocole NTP, les données à collecter pour le dépannage, l'analyse des données par exemple et les ressources associées pour des recherches supplémentaires.

L'objectif du protocole NTP avec CUCM est de s'assurer que les serveurs connaissent l'heure correcte. L'heure des serveurs CUCM est importante car la voix sur IP (VOIP) est extrêmement sensible aux variations d'heure.

Le cluster CUCM doit maintenir une synchronisation temporelle proche des autres serveurs du cluster, en raison des exigences de réplication de la base de données.

Enfin, le temps de dépannage est important, car vous voulez que les horodatages corrects figurent dans les journaux.

Configurer

Le serveur NTP Windows n'est pas pris en charge pour CUCM ; cependant, d'autres types tels que les sources NTP Linux, les sources NTP Cisco IOS® et les sources NTP Nexus OS sont acceptables.

Bien que d'autres solutions Cisco puissent utiliser des serveurs Windows pour la solution NTP, les solutions UC telles que Call Manager, Cisco Unity et Instant Messaging and Presence ne peuvent pas le faire et nécessitent une solution NTP basée sur Linux ou sur Cisco IOS®.

En effet, Windows Time Services utilise souvent SNTP avec lequel les systèmes Linux ont des difficultés à se synchroniser.

Diagramme du réseau

L'éditeur CUCM a besoin d'une source NTP qui n'est pas membre du cluster CUCM ; par conséquent, l'éditeur CUCM synchronise son heure avec le serveur NTP. Dans cet échange, l'éditeur CUCM est un client NTP.

Les abonnés CUCM synchronisent leur heure avec l'éditeur CUCM. Dans cet échange, l'éditeur CUCM est un serveur NTP où les abonnés CUCM sont des clients NTP.

Attention : sachez que les serveurs Cisco Instant Messaging & Presence (IM&P) sont également considérés comme des abonnés du cluster CUCM et qu'ils dépendent donc également du protocole NTP du CUCM. En d'autres termes, si le NTP n'est pas synchronisé sur le serveur IM&P, il entraîne des problèmes dans le système avec sa réplication de base de données et sa haute disponibilité.

Procédure d'installation

Lorsque CUCM est installé, une invite s'affiche pour déterminer si le serveur est le premier noeud du cluster.

Si le serveur n'est pas le premier noeud du cluster, l'assistant d'installation passe alors la phase de configuration NTP ; cependant, vous êtes invité à indiquer le ou les serveurs NTP s'il s'agit du premier noeud du cluster.

Après l'installation, utilisez la page Web OS Admin

Après l'installation, utilisez l'interface de ligne de commande

 Comme le montrent les images, vous pouvez trouver les commandes utilisées pour accéder aux serveurs NTP et les modifier au sein du serveur CUCM.

• La commande utils ntp server list affiche les serveurs NTP configurés sur votre système.

• La commande utils ntp server add ntp_address ajoute un nouveau serveur NTP au système.

Remarque : gardez à l'esprit que si vous voulez ajouter un nouveau serveur NTP, le serveur CUCM teste l'accessibilité avant de l'ajouter, s'il échoue, l'erreur suivante s'affiche.

• La commande utils ntp server delete vous permet de supprimer n'importe lequel des NTP déjà configurés dans le système.

Dépannage

Données à collecter

Lorsque vous dépannez un problème NTP, vous devez collecter ces données à partir du ou des serveurs CUCM présentant les problèmes NTP :

• Le résultat de la commande utilise diagnose test.
• Le résultat de la commande utilise ntp status.
• Les journaux NTP du CUCM rassemblés à partir de l'outil Cisco Real-Time Monitor Tool (RTMT).

Exemple d'analyse

Par exemple, les informations suivantes du serveur de publication CUCM et du NTP ont été utilisées :

Éditeur CUCM

Version : 11.5(1) SU5

Nom de domaine complet : cucm-115.home.lab

L'adresse IP commence par 192.X.X.X

NTP

À partir du serveur NTP Google

Nom de domaine complet : time1.example.com.ntp

L'adresse IP commence par 216.X.X.X

Examen PCAP pour CUCM - Aucun fichier

Notez que le numéro de port est 123. Il s'agit du port pour NTP. Dans le résultat de la commande dans la zone de texte, vous pouvez voir que la version de NTP est 4, comme indiqué par le NTPv4. Vous pouvez également prendre note de l'éditeur, qui agit en tant que client lorsqu'il établit sa communication avec time1.example.com ; cependant, il fonctionne en tant que serveur lorsqu'il établit la communication avec cucm-sub1, cucm-sub2 et cucm-sub3.

From the CLI of the publisher run the command "utils network capture port 123"

Wait until you see traffic (this can take a little time, or it may be instant) then hit 
ctrl+c. Look in the traffic to find where your publisher is communicating with its NTP 
server and the NTP server is communication with the publisher (if the NTP server isn't 
replying then it is an issue in the network or with the NTP server). The primary focus of 
this output is the NTP version. In CUCM 9 and later NTP version 3 (NTPv3) can cause issues
 and an NTP source using NTPv4 should be the NTP server for the publisher.

admin:utils network capture size all count 10000000 port 123
Executing command with options:
 size=128                count=1000              interface=eth0
 src=dest=                   port=123
 ip=

16:08:43.199710 IP cucm-sub3.home.lab.39417 > cucm-115.home.lab.ntp: NTPv4, Client, length 48
16:08:43.199737 IP cucm-115.home.lab.ntp > cucm-sub3.home.lab.39417: NTPv4, Server, length 48
16:08:43.199823 IP cucm-sub3.home.lab.39417 > cucm-115.home.lab.ntp: NTPv4, Client, length 48
16:08:43.199859 IP cucm-115.home.lab.ntp > cucm-sub3.home.lab.39417: NTPv4, Server, length 48
16:09:01.640980 IP cucm-115.home.lab.50141 > time1.example.com.ntp: NTPv4, Client, length 48
16:09:01.654675 IP time1.example.com.ntp > cucm-115.home.lab.50141: NTPv4, Server, length 48
16:09:01.654733 IP cucm-115.home.lab.50141 > time1.example.com.ntp: NTPv4, Client, length 48
16:09:01.667368 IP time1.example.com.ntp > cucm-115.home.lab.50141: NTPv4, Server, length 48
16:09:01.668612 IP cucm-115.home.lab.50141 > time1.example.com.ntp: NTPv4, Client, length 48
16:09:01.681366 IP time1.example.com.ntp > cucm-115.home.lab.50141: NTPv4, Server, length 48
16:09:01.681518 IP cucm-115.home.lab.50141 > time1.google.com.ntp: NTPv4, Client, length 48
16:09:01.694108 IP time1.google.com.ntp > cucm-115.home.lab.50141: NTPv4, Server, length 48
16:09:01.875016 IP cucm-115.home.lab.48422 > time1.google.com.ntp: NTPv4, Client, length 48
16:09:01.884476 IP cucm-sub3.home.lab.58072 > cucm-115.home.lab.ntp: NTPv4, Client, length 48
16:09:01.884568 IP cucm-115.home.lab.ntp > cucm-sub3.home.lab.58072: NTPv4, Server, length 48
16:09:01.884954 IP cucm-sub3.home.lab.58072 > cucm-115.home.lab.ntp: NTPv4, Client, length 48
16:09:01.884999 IP cucm-115.home.lab.ntp > cucm-sub3.home.lab.58072: NTPv4, Server, length 48
16:09:01.885381 IP cucm-sub3.home.lab.58072 > cucm-115.home.lab.ntp: NTPv4, Client, length 48
16:09:01.885423 IP cucm-115.home.lab.ntp > cucm-sub3.home.lab.58072: NTPv4, Server, length 48
16:09:01.886147 IP cucm-sub3.home.lab.58072 > cucm-115.home.lab.ntp: NTPv4, Client, length 48
16:09:01.886184 IP cucm-115.home.lab.ntp > cucm-sub3.home.lab.58072: NTPv4, Server, length 48
16:09:01.888555 IP time1.google.com.ntp > cucm-115.home.lab.48422: NTPv4, Server, length 48
16:09:01.888642 IP cucm-115.home.lab.48422 > time1.google.com.ntp: NTPv4, Client, length 48
16:09:01.900926 IP time1.google.com.ntp > cucm-115.home.lab.48422: NTPv4, Server, length 48
16:09:01.901017 IP cucm-115.home.lab.48422 > time1.google.com.ntp: NTPv4, Client, length 48
16:09:01.913497 IP time1.google.com.ntp > cucm-115.home.lab.48422: NTPv4, Server, length 48
16:09:01.913566 IP cucm-115.home.lab.48422 > time1.google.com.ntp: NTPv4, Client, length 48
16:09:01.926693 IP time1.google.com.ntp > cucm-115.home.lab.48422: NTPv4, Server, length 48
16:09:02.038981 IP cucm-sub2.home.lab.42078 > cucm-115.home.lab.ntp: NTPv4, Client, length 48
16:09:02.039117 IP cucm-115.home.lab.ntp > cucm-sub2.home.lab.42078: NTPv4, Server, length 48
16:09:02.039281 IP cucm-sub2.home.lab.42078 > cucm-115.home.lab.ntp: NTPv4, Client, length 48
16:09:02.039345 IP cucm-115.home.lab.ntp > cucm-sub2.home.lab.42078: NTPv4, Server, length 48
16:09:02.039434 IP cucm-sub2.home.lab.42078 > cucm-115.home.lab.ntp: NTPv4, Client, length 48
16:09:02.039535 IP cucm-115.home.lab.ntp > cucm-sub2.home.lab.42078: NTPv4, Server, length 48
16:09:02.039607 IP cucm-sub2.home.lab.42078 > cucm-115.home.lab.ntp: NTPv4, Client, length 48
16:09:02.039814 IP cucm-115.home.lab.ntp > cucm-sub2.home.lab.42078: NTPv4, Server, length 48
16:09:02.066544 IP cucm-sub1.home.lab.46400 > cucm-115.home.lab.ntp: NTPv4, Client, length 48
16:09:02.066622 IP cucm-115.home.lab.ntp > cucm-sub1.home.lab.46400: NTPv4, Server, length 48
16:09:02.066751 IP cucm-sub1.home.lab.46400 > cucm-115.home.lab.ntp: NTPv4, Client, length 48
16:09:02.066892 IP cucm-115.home.lab.ntp > cucm-sub1.home.lab.46400: NTPv4, Server, length 48
16:09:02.066968 IP cucm-sub1.home.lab.46400 > cucm-115.home.lab.ntp: NTPv4, Client, length 48
16:09:02.067104 IP cucm-115.home.lab.ntp > cucm-sub1.home.lab.46400: NTPv4, Server, length 48
16:09:02.067155 IP cucm-sub1.home.lab.46400 > cucm-115.home.lab.ntp: NTPv4, Client, length 48
16:09:02.067189 IP cucm-115.home.lab.ntp > cucm-sub1.home.lab.46400: NTPv4, Server, length 48

Examen PCAP pour CUCM - Avec fichier

Le filtre utilisé pour dépanner le problème NTP dans la capture de paquets est : udp.port == 123. Avec ce filtre, vous pouvez voir que l'éditeur CUCM a établi la communication avec le serveur NTP de Google et que l'éditeur CUCM a également communiqué avec les abonnés CUCM.

Révision des résultats CLI pour CUCM

utils ntp status output

NOTE: All nodes will show the current time in UTC regardless of the time zone of the server
(listed in UTC time). This makes it easy to compare times on the different CUCM nodes.

NOTE: If there is a time difference of 15 minutes or more, it is expected that DB replication
will be broken

1) If the publisher is ahead by 15 minutes, this can result in the pub send data to the
sub and the sub would have a delay to process the data because it has not yet reached the time
in the timestamp of the packets from the publisher (this is expected behavior in this type of situation)

2) If  the subscriber is ahead by 15 minutes, this would result in the subscriber drop
the data from the publisher because the subscriber sees it as old data (15 minutes old)

admin:utils ntp status
ntpd (pid 28435) is running...

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 203.0.113.0    .GOOG.           1 u   44   64    3   11.724   -0.021   0.064


unsynchronised
   polling server every 8 s

Current time in UTC is : Fri Sep  6 20:54:50 UTC 2019
Current time in America/New_York is : Fri Sep  6 16:54:50 EDT 2019
admin:

Lisez les informations suivantes, car elles expliquent en détail le résultat précédent.

The very first column contains the "tally code" character. Short overview: 

    * the source you are synchronized to (syspeer)
    # source selected, distance exceeds maximum value
    o the PPS(Pulse Per Second) source if your ntpd (ppspeer, only if you have a PPS capable system and refclock)
    + candidate, i.e. it is considered a good source
    - outlyer, i.e. quality is not good enough
    x falseticker, i.e. this one is considered to distribute bad time
    blank: source discarded, failed sanity 

See the Select field of the Peer status word on the NTP Event Messages and
Status Words page for more information on the tally codes.

remote

    the hostname or IP of the remote machine. 

refid

    the identification of the time source to which the remote machines is synced.
    May be (for example) a radio clock or another ntp server) 

st

    the stratum of the remote machine. 16 is "unsynchronized". 0 is the best
    value, that could be (for example) a radio clock or the ntp servers private
    caesium clock (see http://www.eecis.udel.edu/~mills/ntp/html/index.html#intro
    for more information about ntp in general). 

t

    types available:

        l = local (such as a GPS, WWVB)
        u = unicast (most common)
        m = multicast
        b = broadcast
        - = netaddr 

when

    how many seconds since the last poll of the remote machine. 

poll

    the polling interval in seconds. 

reach

    an 8-bit left-rotating register. Any 1 bit means that a "time packet" was
    received. The right most bit indicate the status of the last connection
    with the NTP server. It is Octal number. Use calculator in progammer
    interface to translate from OCT to BIN: For example 377 translates to
    11111111. Each 1 means a successful connection to the NTP server. If you
    just start a NTP service, and it connects successfully with its server, this
    number will change as follows (if connectivity is good): 

    00000001 = 001
    00000011 = 003
    00000111 = 007
    00001111 = 017
    00011111 = 037
    00111111 = 077
    01111111 = 177
    11111111 = 377 

delay

    the time delay (in milliseconds) to communicate with the remote. 

offset

    the offset (in milliseconds) between our time and that of the remote. 

jitter

    the observed jitter (in milliseconds) of time with the remote. 

Utilise les résultats de test de diagnostic

admin:utils diagnose test

Log file: platform/log/diag1.log

Starting diagnostic test(s)
===========================
test - disk_space          : Passed (available: 6463 MB, used: 12681 MB)
skip - disk_files          : This module must be run directly and off hours
test - service_manager     : Passed
test - tomcat              : Passed
test - tomcat_deadlocks    : Passed
test - tomcat_keystore     : Passed
test - tomcat_connectors   : Passed
test - tomcat_threads      : Passed
test - tomcat_memory       : Passed
test - tomcat_sessions     : Passed
skip - tomcat_heapdump     : This module must be run directly and off hours
test - validate_network    : Passed
test - raid                : Passed
test - system_info         : Passed (Collected system information in diagnostic log)
test - ntp_reachability    : Passed
test - ntp_clock_drift     : Passed
test - ntp_stratum         : Passed
skip - sdl_fragmentation   : This module must be run directly and off hours
skip - sdi_fragmentation   : This module must be run directly and off hours

Diagnostics Completed


 The final output will be in Log file: platform/log/diag1.log


 Please use 'file view activelog platform/log/diag1.log' command to see the output

admin:

Si NTP échoue dans le résultat du test de diagnostic de l'utilitaire, vous verrez quelque chose de similaire à ceci :

admin:utils diagnose test

Log file: platform/log/diag1.log

Starting diagnostic test(s)
===========================
test - disk_space          : Passed (available: 6463 MB, used: 12681 MB)
skip - disk_files          : This module must be run directly and off hours
test - service_manager     : Passed
test - tomcat              : Passed
test - tomcat_deadlocks    : Passed
test - tomcat_keystore     : Passed
test - tomcat_connectors   : Passed
test - tomcat_threads      : Passed
test - tomcat_memory       : Passed
test - tomcat_sessions     : Passed
skip - tomcat_heapdump     : This module must be run directly and off hours
test - validate_network    : Passed
test - raid                : Passed
test - system_info         : Passed (Collected system information in diagnostic log)
test - ntp_reachability    : Warning
The NTP service is restarting, it can take about 5 minutes.

test - ntp_clock_drift     : Warning
The local clock is not synchronised.
None of the designated NTP servers are reachable/functioning or legitimate.

test - ntp_stratum         : Warning
The local clock is not synchronised.
None of the designated NTP servers are reachable/functioning or legitimate.

skip - sdl_fragmentation   : This module must be run directly and off hours

Confirmez que le protocole NTP était correct au moment de l'installation. Exécutez la commande suivante :

run sql select pkid,name, dbinfo('utc_to_datetime', cdrtime) as CDRTIME from device where cdrtime > getCurrTime()

Cette commande compare l'heure actuelle à l'heure cdrtime (lorsque la table a été modifiée). Si vous avez utilisé un NTP incorrect dans l'installation/la mise à niveau, puis corrigé le NTP, la base de données se désynchronise chaque fois qu'une modification est effectuée. Ce problème ne serait pas vu quand vous exécutez les commandes NTP typiques (par exemple, utils ntp status) parce que vous avez déplacé loin de la mauvaise source NTP à une bonne.

Il serait bon que vous vous éloigniez du mauvais NTP pour un bon ; cependant, un mouvement vers une bonne source NTP ne corrigerait pas les tables qui ont été créées lors de l'installation / mise à niveau.

Lorsque vous exécutez cette commande, le résultat attendu est le suivant :

admin:run sql select pkid,name,dbinfo('utc_to_datetime', cdrtime) as CDRTIME  from device where cdrtime > getCurrTime()

pkid name cdrtime

==== ==== =======

admin:

Si vous obtenez un résultat similaire au suivant, cela indique que le protocole NTP utilisé pour l'installation/la mise à niveau n'a pas été utilisé et a causé des problèmes qui affectent la réplication de la base de données :

admin:run sql select pkid,name,dbinfo('utc_to_datetime', cdrtime) as CDRTIME from device where cdrtime > getCurrTime()

pkid                                    name          cdrtime

=============================           =====         =====================

bf80dd31-9911-43ce-81fd-a99ec0333fb5    MTP_2         2016-09-11 14:38:14.0
4c38fc05-760d-4afb-96e8-69333c195e74    CFB_2         2016-09-11 14:38:14.0
90878c80-e213-4c7e-82b9-6c780aac72f3    ANN_2         2016-09-11 14:38:14.0
08b5bff4-da94-4dfb-88af-ea9ffa96872c    MOH_2         2016-09-11 14:38:14.0
93320e4d-1b73-4099-9a7c-c4cddfadb5d9    MTP_3         2016-09-11 14:38:14.0
a6850d42-5f0a-49ce-9fa3-80d45b800e23    CFB_3         2016-09-11 14:38:14.0
9963c9cb-58b0-4191-93e1-8676584f6461    ANN_3         2016-09-11 14:38:14.0
def79fb7-c801-4fb3-85fb-4e94310bf0bd    MOH_3         2016-09-11 14:38:14.0
4cd64584-089b-4331-9291-79774330cbc     2 MTP_4       2016-09-11 14:38:14.0
27b18882-db83-4d14-8bce-d3f8dc439610    CFB_4         2016-09-11 14:38:14.0
a40da882-e04f-4649-b2eb-2f79d1289e81    ANN_4         2016-09-11 14:38:14.0
36575ff4-cdea-4945-87e7-638cc555463e    MOH_4         2016-09-11 14:38:14.0

Autres considérations

1) Si vous mettez à niveau les hôtes ESXi sans tenir compte des considérations matérielles de la machine virtuelle, vous pouvez rencontrer des problèmes NTP.

2) Assurez-vous que la version ESXi est conforme à la matrice de virtualisation.
3) Assurez-vous que la version ESXi et la version matérielle sont compatibles.

Informations connexes

• Assistance et documentation techniques - Cisco Systems
• Cisco Collaboration System 10.x Solution Reference Network Designs (SRND)
• Modification de la source NTP dans CUCM à partir de la CLI et d'autres informations utiles
• Dépannage NTP sur Cisco Unified Communications Manager
• Livre blanc sur le protocole NTP (Network Time Protocol)
• Saisie de paquets dans le modèle de l’appareil CUCM