Einleitung
In diesem Dokument wird die Fehlerbehebung bei NTP-Problemen (Network Time Protocol) mit Cisco Unified Communications-Produkten (UC) 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 kennen.
Hintergrundinformationen
Für Cisco Unified Communications Manager (CUCM) muss NTP konfiguriert sein, um Folgendes sicherzustellen:
- Die Uhrzeit auf den CUCM-Knoten wird synchronisiert.
- Die Zeit ist vor jeder zeitkritischen Konfigurationsänderung (z. B. der Zertifikaterneuerung) richtig.
- Die Datenbankreplikation wird auf allen Knoten im Cluster synchronisiert.
NTP-Polling-Mechanismus in UC-Produkten
Der CUCM verwendet den NTP-Watchdog, um die Zeitsynchronisierung mit dem NTP-Server vorzunehmen. Der NTP-Watchdog fragt regelmäßig die konfigurierten externen NTP-Server ab und startet das NTP neu, wenn die Zeit um mehr als drei Sekunden versetzt ist.
Der NTP-Daemon korrigiert regelmäßig die Zeit, allerdings im Millisekundenbereich. Bei einem Neustart von NTP müssen Sie einen NTP One-Shot ausführen, um eine Bruttozeitkorrektur durchzuführen, und anschließend den NTP-Daemon neu starten, um die regelmäßigen Mikrokorrekturen fortzusetzen.
NTP Watchdog fragt NTP einmal pro Minute auf VMware und einmal alle 30 Minuten auf physischen Systemen ab. Das Abfrageintervall ist für VMware kürzer, da die Uhr in virtuellen Maschinen (VMs) weniger stabil ist als auf physischen Maschinen, und VMware-Funktionen wie VMotion und Storage-Migration wirken sich negativ auf die Zeit aus.
Ein primärer Knoten, der auf VMware ausgeführt wird, muss immer konfiguriert werden, damit er mit externen NTP-Servern synchronisiert werden kann, die auf einem oder mehreren physischen Systemen ausgeführt werden, um die höhere zeitliche Abweichung oder Verzögerung in einem virtuellen System auszugleichen. Sekundäre Knoten werden automatisch so konfiguriert, dass sie auf den NTP-Server des primären Knotens verweisen, um sicherzustellen, dass sich alle Knoten innerhalb des Clusters zeitlich nah beieinander befinden.
NTP Watchdog überwacht die Rate, mit der der NTP-Daemon neu gestartet wird, um Bruttozeitkorrekturen aufgrund von VMotions und Storage-Migrationen von VMWare zu erhalten. Wenn diese Rate 10 Neustarts pro Stunde überschreitet, verschiebt NTP Watchdog weitere Neustarts, bis die erforderliche Rate von Neustarts unter 10 Neustarts pro Stunde fällt. Die kombinierte Rate von VMotions- und Storage-Migrationen darf 10 pro Stunde nicht überschreiten, da diese Rate als übermäßig angesehen wird.
Aufgrund dieser NTP-Watchdog-Implementierung befolgen Sie das Abfrageintervall nicht, das unter utils ntp status angezeigt wird. Eine Sniffer-Erfassung hat 8 NTP-Abfragen (Stichproben) alle 60 Sekunden ergeben. Dies liegt vor allem daran, dass die NTP-Implementierung den NTP-Watchdog verwendet und dass ntpdate den NTP-Server in der UC-Implementierung abfragt.
Identifizieren der verwendeten NTP-Version
Hinweis: Der CUCM-Publisher ist mit einem externen NTP-Server konfiguriert, und der dem Cluster hinzugefügte Subscriber wird mit dem Publisher synchronisiert.
Hinweis: CUCM Version 9.x und höher erfordert, dass der NTPv4-Server als bevorzugter NTP-Server konfiguriert wird.
Führen Sie eine Sniffer-Erfassung aus, um die vom konfigurierten NTP-Server verwendete NTP-Version zu identifizieren:
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
Der CUCM sendet ein NTPv4-Paket, und als Antwort erhalten Sie ein NTPv3-Paket. Obwohl NTPv4 mit NTPv3 abwärtskompatibel ist, ist die CUCM-Implementierung von NTP unterschiedlich, was zu einem nicht synchronisierten NTP führt:
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
Um das Problem zu beheben, empfiehlt Cisco die Verwendung eines Linux-basierten externen NTP-Servers oder eines Cisco IOS®- oder Cisco IOS® XE NTP-Servers, und stellen Sie sicher, dass NTPv4 konfiguriert ist.
Nachfolgend finden Sie eine Beschreibung der NTP-Terminologie in der Ausgabe des NTP-Status:
- Die Spalte refid gibt die Zeitquelle der Fernbedienung an. LOCAL(0) ist die lokale Hardwareuhr. .INIT. bedeutet, dass die Initialisierung noch nicht erfolgreich war.
- Die erste Spalte zeigt die Schicht des Remote-NTP-Servers an. 16 ist ein ungültiger Stratum-Wert, d. h., dieser Server gilt nicht als Zeitanbieter. Die Schicht kann aus verschiedenen Gründen ungültig sein. Die häufigste ist, dass der Zeitanbieter nicht synchronisiert wurde, die konfigurierte Quelle nicht existiert oder der NTP-Server nicht ausgeführt wird.
- Die Spalte t gibt den Servertyp an (l: lokal; u: Unicast; m: Multicast oder b: Broadcast).
- Die Spalte "Wann" gibt an, wie viele Sekunden die Remote-Abfrage zurückliegt.
- Die Abfragespalte gibt das Abfrageintervall in Sekunden an. Beispielsweise bedeutet 64, dass die Fernbedienung alle 64 Sekunden abgefragt wird. Das kürzeste vom NTP verwendete Intervall beträgt 64 Sekunden, das längste 1.024 Sekunden. Je besser eine NTP-Quelle im Zeitverlauf bewertet wird, desto länger ist das Intervall. (Für die UC-Implementierung gilt das hier festgelegte Intervall nicht.)
- Die Spalte "Reichweite" gibt den Trend der Erreichbarkeitstests im Oktal an, wobei jede Ziffer bei der Konvertierung 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 vorherige Umfrage war nicht erfolgreich, und die vorherige Umfrage war erfolgreich.
- Die Spalten für Verzögerung, Offset und Jitter stellen die Round-Trip-Verzögerung, die Dispersion und den Jitter in Millisekunden dar.
Diagnose von NTP-bezogenen Problemen in CUCM
Gehen Sie wie folgt vor, um NTP-bezogene Probleme zu diagnostizieren:
- Stellen Sie sicher, dass der CUCM mit dem NTP-Server an Port 123 kommunizieren kann.
- Rufen Sie die Ausgabe von utils ntp status ab.
- Die Stratum-Ebene kann im Publisher kleiner als 4 sein, um optimale Leistung zu erzielen.
- Wenn mehrere NTP-Server konfiguriert sind, stellen Sie sicher, dass mindestens ein Server erreichbar ist. Sie sehen das Symbol (*) für den NTP-Server, der als Referenz vom CUCM verwendet wird.
- Überprüfen Sie den Syslog-Alarm, und führen Sie die entsprechenden Maßnahmen aus. Mögliche Ursachen für Syslog-Alarme sind:
- Der externe NTP-Server ist nicht erreichbar.
- Die NTP-Schicht liegt über dem zulässigen Grenzwert.
- Der Publisher ist ausgefallen, sodass das Subscriber-NTP nicht synchronisiert ist.
- Wenn Warnmeldungen im Zusammenhang mit ntpdate -q angezeigt werden, ist es möglich, dass Sie NTP Version 4.2.6 oder höher mit aktivierter KoD-Funktion (Kiss of Death) installiert haben. (Das minimale Intervall zwischen Burst- und Burst-Paketen, die von einem Client gesendet werden, beträgt zwei und verstößt daher nicht gegen diese Einschränkung. Pakete, die von anderen Implementierungen gesendet werden, die diese Einschränkung verletzen, können verworfen werden, und ein KoD-Paket kann zurückgegeben werden, wenn dies aktiviert ist). Es wird empfohlen, diese Funktion zu deaktivieren, wenn Sie diese Version als NTP-Server für ein UC-Produkt verwenden.
- Verwenden Sie dieses Diagnosemodul, um zu überprüfen, ob der NTP-Server konfiguriert ist.
- utils diagnosemodul ntp_reachability
- utils diagnosemodul ntp_clock_drift
- utils diagnosemodul ntp_stratum
- Geben Sie utils ntp restart ein, um den NTP-Client/Server neu zu starten. Dieser Befehl ist immer dann nützlich, wenn eine Bruttozeitkorrektur sofort erfolgen muss oder wenn externe Server weiterhin erreichbar und betriebsbereit sind, aber die Synchronisierung fehlschlägt. Verwenden Sie den Befehl utils ntp status, um den Betriebsstatus externer NTP-Server zu bestimmen.
Häufige bekannte Probleme mit der NTP-Zuordnung in CUCM
Cisco Bug-ID: CSCue18813: NTP-Konfiguration mit über CLI gesteuertem Maxdist-Parameter
Lösung: Sie können ein Cisco Technical Assistance Center-Ticket erstellen, um den tos maxdist-Parameter manuell in die Datei "ntp.conf" hinzuzufügen.
Cisco Bug-ID CSCuq70611: NTP-Stratum-Test wird bei einem einzelnen NTP-Server nicht ordnungsgemäß validiert
Feste Version: 10.5(2.10000.005)
Cisco Bug-ID CSCui85967: CUCM-Sprung-Upgrade von 6.1.5 auf 9.1.2 schlägt fehl, weil NTP-Referenz fehlt
Lösung: Die Dokumentation für das Jump-Upgrade wurde aktualisiert, und die NTP-Konfiguration wird als eine der Aufgaben vor dem Upgrade aufgeführt.
Cisco Bug-ID CSCtw46611: NTP-Synchronisierung aufgrund falscher Dateisystembeschriftung von capture.txt fehlgeschlagen
Feste Version: 8.6(2.24900.017)
Cisco Bug-ID CSCur94973: Zeitsynchronisierungsproblem zwischen VMHost- und VM-Instanz während M1-Migration
Auflösung: Deaktivieren Sie die NTP-Synchronisierung des virtuellen Systems mit dem ESXi-Host mithilfe dieser Problemumgehung. Eine alternative Problemumgehung besteht darin, den ESXi-Server und den CUCM Publisher so zu konfigurieren, dass sie auf denselben NTP-Server verweisen.
Feedback