Inhalt

Einleitung

Voraussetzungen

Anforderungen

Verwendete Komponenten

Zweck der Funktion

Konfigurieren

Netzwerkdiagramm

Installationsprozess

Nach der Installation verwenden Sie die OS Admin-Webseite

Verwenden Sie nach der Installation die Befehlszeilenschnittstelle.

Fehlerbehebung

Zu erfassende Daten

Beispielanalyse

PCAP-Prüfung für CUCM - keine Datei

PCAP-Bewertung für CUCM - mit Datei

CLI-Ausgabeprüfung für CUCM

Weitere Überlegungen

Zugehörige Informationen

Einleitung

In diesem Dokument wird das Network Time Protocol (NTP) für Cisco Unified Communications Manager (CUCM) beschrieben.

Voraussetzungen

Anforderungen

Es gibt keine spezifischen Anforderungen für dieses Dokument.

Verwendete Komponenten

Dieses Dokument ist nicht auf bestimmte Software- und Hardware-Versionen beschränkt.

Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die möglichen Auswirkungen aller Befehle verstehen.

Zweck der Funktion

In diesem Dokument wird der Zweck von NTP mit CUCM, die Konfiguration von NTP, die zu erfassenden Daten für die Fehlerbehebung, eine Beispielanalyse der Daten und zugehörige Ressourcen für weitere Recherchen behandelt.

Der Zweck des NTP in Verbindung mit CUCM besteht darin, sicherzustellen, dass die Server über die richtige Zeit informiert sind. Die Zeit in den CUCM-Servern ist wichtig, da Voice Over Internet Protocol (VOIP) extrem empfindlich auf Zeitschwankungen reagiert. Der CUCM-Cluster muss eine Zeitsynchronisierung durchführen, die in der Nähe der anderen Server im Cluster bleibt. Dies ist auf die Anforderungen an die Datenbankreplikation zurückzuführen.

Zeit für die Fehlerbehebung ist wichtig, da die Protokolle die richtigen Zeitstempel enthalten müssen.

Konfigurieren

Beachten Sie, dass für den CUCM bestimmte NTP-Server erforderlich sind.

Der Windows NTP-Server wird für CUCM nicht unterstützt. Andere Typen, wie Linux NTP-Quellen, Cisco IOS® NTP-Quellen und Nexus OS NTP-Quellen, sind jedoch akzeptabel. Obwohl andere Cisco Lösungen Windows Server für die NTP-Lösung verwenden können, sind UC-Lösungen wie CallManager, Cisco Unity und Instant Messaging sowie Presence dazu nicht in der Lage und erfordern entweder eine Linux- oder eine Cisco IOS®-basierte NTP-Lösung. Dies liegt daran, dass Windows Time Services oft SNTP verwenden, mit dem Linux-Systeme nur schwer synchronisiert werden können.

Netzwerkdiagramm

Der CUCM-Publisher benötigt eine NTP-Quelle, die kein Mitglied des CUCM-Clusters ist. Daher synchronisiert der CUCM-Publisher seine Uhrzeit mit dem NTP-Server. Bei diesem Austausch ist der CUCM-Publisher ein NTP-Client.

Die CUCM-Teilnehmer synchronisieren ihre Uhrzeit mit dem CUCM-Publisher. In diesem Exchange ist der CUCM-Publisher ein NTP-Server, bei dem die CUCM-Subscriber NTP-Clients sind.

Achtung: Beachten Sie, dass die Cisco Instant Messaging & Presence (IM&P)-Server auch als Subscriber des CUCM-Clusters gelten und deshalb ebenfalls auf das CUCM-NTP angewiesen sind. Mit anderen Worten: Wenn das NTP auf dem IM&P-Server nicht synchronisiert ist, verursacht es Probleme im System mit der Datenbankreplikation und der Hochverfügbarkeit.

Installationsprozess

Wenn CUCM installiert ist, wird eine Aufforderung angezeigt, um festzustellen, ob der Server der erste Knoten im Cluster ist.

Wenn der Server nicht der erste Knoten im Cluster ist, geht der Installationsassistent über die NTP-Konfigurationsphase hinaus. Sie werden jedoch zur Eingabe der NTP-Server aufgefordert, wenn es sich um den ersten Knoten im Cluster handelt.

Nach der Installation verwenden Sie die OS Admin-Webseite

Verwenden Sie nach der Installation die Befehlszeilenschnittstelle.

Wie in den Bildern gezeigt, können Sie die Befehle finden, die zum Zugreifen auf und Ändern der NTP-Server innerhalb des CUCM-Servers verwendet werden.

- Der Befehl utils ntp server list zeigt die auf Ihrem System konfigurierten NTP-Server an.

- Der Befehl utils ntp server add ntp_address fügt dem System einen neuen NTP-Server hinzu.

Hinweis: Wenn Sie einen neuen NTP-Server hinzufügen möchten, testet der CUCM-Server die Erreichbarkeit, bevor er ihn hinzufügt. Wenn er fehlschlägt, wird der nächste Fehler angezeigt.

- Mit dem Befehl utils ntp server delete können Sie alle im System bereits konfigurierten NTPs löschen.

Fehlerbehebung

Zu erfassende Daten

Wenn Sie ein NTP-Problem beheben, müssen Sie diese Daten von dem oder den CUCM-Servern sammeln, bei denen das NTP-Problem aufgetreten ist:

- Die Ausgabe des Befehls utils diagnose test

- Die Ausgabe von utils ntp status

- Die vom Cisco Real-Time Monitor Tool (RTMT) erfassten NTP-Protokolle vom CUCM

Beispielanalyse

Zu diesem Zweck wurden beispielsweise die nächsten Informationen vom CUCM Publisher und vom NTP verwendet:

CUCM-Publisher

Version: 11.5(1) SU5

FQDN: cucm-115.home.lab

IP-Adresse beginnt mit 192.X.X.X

NTP

Von Google NTP Server

FQDN: time1.example.com.ntp

IP-Adresse beginnt mit 216.X.X.X

PCAP-Prüfung für CUCM - keine Datei

Beachten Sie die Portnummer 123. Dies ist der Port für NTP. In der Ausgabe des Befehls im Textfeld können Sie sehen, dass die NTP-Version 4 ist, wie unter "NTPv4" angegeben. Sie können sich auch den Publisher notieren, der als Client fungiert, wenn er seine Kommunikation mit "time1.example.com" herstellt; er fungiert jedoch als Server, wenn er die Kommunikation mit cucm-sub1, cucm-sub2 und cucm-sub3 herstellt.

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

PCAP-Bewertung für CUCM - mit Datei

Der Filter, der zur Fehlerbehebung des NTP-Problems in der Paketerfassung verwendet wird, lautet: udp.port == 123. Mit diesem Filter können Sie sehen, dass der CUCM-Publisher die Kommunikation mit dem Google NTP-Server eingerichtet hat und dass der CUCM-Publisher auch mit den CUCM-Abonnenten kommuniziert hat.

CLI-Ausgabeprüfung für CUCM

utils ntp status Ausgabe

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:

Lesen Sie die nächsten Informationen, wie es die vorherige Ausgabe im Detail erklärt.

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.

Utils diagnostiziert Testausgabe

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:

Wenn das NTP in der utils diagnose-Testausgabe fehlschlägt, sehen Sie etwas Ähnliches:

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

Bestätigen Sie, dass das NTP zum Zeitpunkt der Installation funktionierte. Führen Sie den folgenden Befehl aus:

Ausführen sql select pkid,name,dbinfo('utc_to_datetime', cdrtime) als CDRTIME von Gerät, auf dem cdrtime > getCurrTime()

Dieser Befehl vergleicht die aktuelle Zeit mit der cdrtime (beim Ändern der Tabelle). Wenn Sie bei der Installation/beim Upgrade ein fehlerhaftes NTP verwendet und dann das NTP korrigiert haben, wird die Datenbank bei jeder Änderung nicht mehr synchronisiert. Dieses Problem tritt nicht auf, wenn Sie die typischen NTP-Befehle ausführen (z. B. utils ntp status), da Sie von der fehlerhaften NTP-Quelle auf eine gute umgestellt haben.

Es wäre gut, wenn Sie das fehlerhafte NTP in ein gutes verschieben würden. Eine Verschiebung zu einer guten NTP-Quelle würde jedoch nicht die Tabellen reparieren, die während der Installation/des Upgrades erstellt wurden.

Wenn dieser Befehl ausgeführt wird, wird folgende Ausgabe erwartet:

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

pkid name cdrtime

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

admin:

Wenn Sie eine ähnliche Ausgabe wie die nächste haben, ist dies ein Zeichen dafür, dass das für die Installation/das Upgrade verwendete NTP nicht verwendet wurde und Probleme verursacht hat, die sich auf die Datenbankreplikation auswirken:

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

Weitere Überlegungen

1) Wenn Sie die ESXi-Hosts ohne Berücksichtigung der VM-Hardware aktualisieren, können NTP-Probleme auftreten.

2) Stellen Sie sicher, dass die ESXi-Version mit der Virtualisierungsmatrix konform ist.

3) Stellen Sie sicher, dass die ESXi-Version und die Hardwareversion kompatibel sind.

Zugehörige Informationen

- Technischer Support und Dokumentation - Cisco Systems

- Cisco Collaboration System 10.x Solution Reference Network Designs (SRND)

- Ändern der NTP-Quelle in CUCM von CLI und anderen hilfreichen Informationen

- NTP-Fehlerbehebung in Cisco Unified Communications Manager

- Network Time Protocol: Best Practices - Whitepaper

- Paketerfassung auf CUCM-Appliance-Modell