Einleitung
In diesem Dokument wird die Fehlerbehebung bei der NTP-Synchronisierung (Network Time Protocol) für IM und Presence (IM&P) beschrieben.
Voraussetzungen
Bevor Sie dieses Dokument lesen, sollten Sie sich mit dem NTP und der IM&P-Befehlszeilenschnittstelle (CLI) vertraut machen.
Anforderungen
Für dieses Dokument bestehen keine spezifischen Hardware- oder Softwareanforderungen.
Verwendete Komponenten
Die Informationen in diesem Dokument basieren auf IM&P.
Hinweis: Viele dieser Informationen gelten auch für andere Unified Communications (UC)-Plattformen. Der Schwerpunkt dieses Dokuments liegt jedoch auf IM&P.
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.
NTP auf IM&P erklärt
Der Cisco Unified Communications Manager (CUCM) Publisher ist die NTP-Quelle für IM&P. IM&P verwendet den NTP-Watchdog, um die Zeit mit dem CUCM Publisher zu synchronisieren. Für IM&P-Plattformen, die sich auf einem virtuellen System befinden, fragt der NTP-Watchdog standardmäßig alle 64 Sekunden den CUCM-Publisher ab. Beträgt der NTP-Offset mehr als drei Sekunden, startet der NTP-Daemon neu.
Hinweis: Der NTP-Watchdog überwacht, wie oft der NTP-Daemon in der letzten Stunde neu gestartet wurde. Wenn innerhalb einer Stunde mehr als 10 Neustarts des NTP-Daemon erfolgen, werden weitere Neustarts für kurze Zeit verschoben.
Anforderungen für die NTP-Quelle
Cisco empfiehlt nachdrücklich die Verwendung eines Layer-1-, Layer-2- oder Layer-3-NTP-Servers als externe CUCM Publisher-NTP-Referenz. Jede NTP-Quelle für den CUCM-Publisher DARF NICHT höher als Schicht 4 sein.
Die für den CUCM Publisher-Knoten definierten externen NTP-Server MÜSSEN NTP v4 sein, um potenzielle Kompatibilitäts-, Genauigkeits- und Netzwerk-Jitter-Probleme zu vermeiden. NTP-Version 4 ist abwärtskompatibel mit Version 3. Bei den Versuchen, verschiedene NTP-Versionen zu verwenden, wurden jedoch viele Probleme beobachtet.
Warnung: Die Verwendung von Windows-Zeitdiensten als NTP-Server wird nicht unterstützt. Häufig verwenden die Windows-Zeitdienste das Simple Network Time Protocol (SNTP), und der CUCM kann nicht erfolgreich mit SNTP synchronisiert werden.
Hinweis: Alle NTP-Anforderungen sind im Cisco Collaboration System SRND aufgeführt.
NTP-Status - Ausgabebeschreibung
Um den aktuellen Status von NTP auf IM&P zu ermitteln, führen Sie den Befehl utils ntp status über die CLI des IM&P-Servers aus.
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
Dies sind Beschreibungen der Spalten, die in der Ausgabe des NTP-Status angezeigt werden.
- Die entfernte Spalte definiert den entfernten Peer, auf dem die Zeit synchronisiert wird. Wenn Sie LOCAL auswählen, wird die lokale Hardwareuhr verwendet.
- Die Spalte refid definiert die Zeitquelle des Remoteservers. Wenn die Einstellung auf .LOCL. gesetzt ist, wird auf die lokale Hardwareuhr auf dem Remote-Server verwiesen. Wenn die Option auf .INIT. gesetzt ist, war die Initialisierung noch nicht erfolgreich.
- Die erste Spalte gibt die Schicht des Remote-NTP-Peers an. Wenn sich der Wert 16 in der Stratum-Spalte befindet, verwendet das System die interne Uhr anstelle der externen NTP-Quelle. Ein System, das seine eigene Uhr verwendet, kann durch einen ungültigen Zeitanbieter verursacht werden.
- Die Spalte t gibt den verwendeten Übertragungstyp an: (l: lokal; u: Unicast; m: Multicast oder b: Broadcast).
- Die Spalte when gibt an, wie viele Sekunden seit dem letzten Polling des Remote-Peers vergangen sind.
- Die Abfragespalte gibt das Abfrageintervall in Sekunden an. Der Standard-Abfragewert für IM&P beträgt 64 Sekunden. Dieser Wert kann jedoch irgendwo zwischen 64 und 1.024 Sekunden festgelegt werden.
- Die Spalte reach gibt den Trend der Erreichbarkeitstests im Oktal an, wobei jede Ziffer beim Konvertieren in eine Binärzahl angibt, ob eine bestimmte Abfrage erfolgreich war (Binärzahl 1) oder nicht erfolgreich war (Binärzahl 0). Beispiel: "1" bedeutet, dass bisher nur eine Umfrage durchgeführt wurde und dass die Umfrage erfolgreich war. "3" (= binär 11) bedeutet, dass die letzten beiden Umfragen erfolgreich waren. "7" (= binär 111) bedeutet, dass die letzten drei Umfragen erfolgreich waren. "17" (= binär 1 111) bedeutet, dass die letzten vier Umfragen erfolgreich waren. "15" (= binär 1 101) bedeutet, dass die letzten beiden Umfragen erfolgreich waren, die Umfrage davor erfolglos war und die Umfrage davor erfolgreich war.
- In der Spalte Verzögerung wird die Round-Trip-Verzögerung zum Remote-Peer angezeigt. Dies wird durch die Messung der Zeit von der Anfrage bis zur Antwort bestimmt.
- Die Offset-Spalte gibt die geschätzte Abweichung zwischen der Uhr des lokalen Servers und der Uhr des Remote-Servers an.
- Die Jitter-Spalte gibt die Variabilität der Verzögerung zwischen den Abfrageanforderungen an. Ein hoher Jitter-Wert schränkt die Fähigkeit des Servers ein, NTP präzise zu synchronisieren.
NTP-Fehlerbehebung
NTP-CLI-Diagnose
Die in den Beispielen aufgeführten Befehle werden über die CLI von IM&P ausgeführt. Mithilfe dieser Befehle kann auf einfache Weise überprüft werden, ob der NTP-Peer den Cisco Standards entspricht.
Tipp: Alle drei dieser Diagnosemodule werden zusammen mit mehreren anderen Modulen ausgeführt, wenn der utils diagnose-TestBefehl wird verwendet
Das ntp_reachability-Diagnosemodul führt einen Ping-Test für alle konfigurierten NTP-Peers durch.
admin:utils diagnose module ntp_reachability
Log file: platform/log/diag2.log
Starting diagnostic test(s)
===========================
test - ntp_reachability : Passed
Diagnostics Completed
Das ntp_clock_drift-Diagnosemodul stellt sicher, dass der NTP-Peer-Drift-Offset 15000 Millisekunden nicht überschreitet.
admin:utils diagnose module ntp_clock_drift
Log file: platform/log/diag3.log
Starting diagnostic test(s)
===========================
test - ntp_clock_drift : Passed
Diagnostics Completed
Das Diagnosemodul ntp_stratum überprüft den NTP-Stratum-Wert auf dem IM&P. Dieser Test verläuft erfolgreich, wenn die NTP-Schicht auf dem CUCM-Publisher den Wert 5 oder weniger hat, da der CUCM-Publisher die externe NTP-Quelle für IM&P ist.
admin:utils diagnose module ntp_stratum
Log file: platform/log/diag4.log
Starting diagnostic test(s)
===========================
test - ntp_stratum : Passed
Diagnostics Completed
TIPP: Wenn das Modul ntp_stratum auf Ihrem System fehlschlägt, lesen Sie den Abschnitt Anforderungen für NTP-Quelle dieses Dokuments
NTP-Kommunikation und -Version überprüfen
NTP ist ein Client\Server-Protokoll, das über das User Datagram Protocol (UDP) an Port 123 kommuniziert. Um die NTP-Kommunikation und die NTP-Version zu überprüfen, müssen Sie eine Paketerfassung (pcap) auf dem IM&P-Server durchführen.
Tipp: Wenn Sie sehen, dass IM&P NTP-Anfragen in pcap sendet, es jedoch keine NTP-Antworten gibt und möglicherweise ein Netzwerkproblem die Ursache ist. Gleichzeitig eine pcap sammeln auf dem CUCM-Server und dem IM&P-Server, um zu bestätigen, dass die von IM&P gesendeten Anforderungen auf der CUCM-Seite empfangen wurden. Bestätigen Sie, dass CUCM auch auf die Anforderungen antwortet.
Die Paketerfassung zeigt eine NTP-Server-Antwort für jede NTP-Client-Anforderung an. Die NTP-Client\Server-Meldung zeigt die verwendete NTP-Version an. Überprüfen Sie, ob sowohl die Client-Anforderung als auch die Serverantwort NTPv4 verwenden.
Führen Sie den CLI-Befehl utils network capture port 123 aus, um eine Paketerfassung auf Port 123 zu erstellen. Dieser Befehl ist für IM&P oder CUCM identisch.
IM&P-CLI
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
CUCM Publisher-CLI
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
Feedback