Inhalt

Einführung

Hintergrundinformationen

NTP-Polling-Mechanismus in UC-Produkten

Verwendete NTP-Version identifizieren

Diagnose von NTP-bezogenen Problemen in CUCM

Häufige bekannte Probleme mit der NTP-Zuordnung auf dem CUCM

Einführung

In diesem Dokument wird beschrieben, wie Sie NTP-Probleme (Network Time Protocol) bei Produkten von Cisco Unified Communications Manager (CUCM) und Cisco Unified Communications (UC) beheben können.

Hintergrundinformationen

CUCM erfordert die Konfiguration von NTP, um Folgendes sicherzustellen:

- Die Uhrzeit auf den CUCM-Knoten wird synchronisiert.

- Die Zeit ist richtig, bevor zeitkritische Konfigurationsänderungen wie die Erneuerung von Zertifikaten vorgenommen werden.

- Die Datenbankreplikation wird auf allen Knoten im Cluster synchronisiert.

NTP-Polling-Mechanismus in UC-Produkten

CUCM verwendet den NTP-Überwachungs-Tool, um die Zeit mit dem NTP-Server zu synchronisieren. Der NTP-Watchdog fragt regelmäßig konfigurierte externe NTP-Server ab und startet NTP neu, wenn die Zeit um mehr als drei Sekunden verrechnet wird.

Der NTP-Daemon korrigiert regelmäßig die Zeit, jedoch im Millisekundenbereich. Bei einem Neustart von NTP wird ein NTP-One-shot ausgeführt, um eine Bruttozeitkorrektur auszuführen, und der NTP-Daemon wird erneut gestartet, um regelmäßige Mikrokorrekturen vorzunehmen.

NTP-Watchdog fragt NTP einmal pro Minute auf VMware und einmal alle 30 Minuten auf physischen Computern. Das Abfrageintervall ist für VMware kürzer, da die Uhr in virtuellen Systemen (VMs) weniger stabil ist als auf physischen Systemen. VMware-Funktionen wie VMotion, Storage Migration wirken sich negativ auf die Zeit aus.

Ein Primärknoten, der auf VMware ausgeführt wird, muss immer konfiguriert werden, um mit externen NTP-Servern zu synchronisieren, die auf physischen Systemen ausgeführt werden, um den höheren Zeitaufwand oder die höhere Verzögerung in einer VM auszugleichen. Sekundäre Knoten werden immer automatisch so konfiguriert, dass sie auf den NTP-Server des primären Knotens verweisen, um sicherzustellen, dass alle Knoten innerhalb des Clusters zeitlich nah sind.

NTP-Watchdog überwacht die Geschwindigkeit, mit der der NTP-Daemon neu gestartet wird, um Bruttozeitkorrekturen aufgrund von VMware VMotions und Storage Migrations vorzunehmen. Wenn diese Rate 10 Neustarts pro Stunde überschreitet, verschiebt NTP-Watchdog weitere Neustarts, bis die erforderliche Anzahl an Neustarts unter 10 pro Stunde fällt. Die kombinierte Rate von VMotions- und Storage-Migrationen sollte 10 pro Stunde nicht überschreiten, da diese Rate als zu hoch angesehen wird.

Aufgrund dieser NTP-Watchdog-Implementierung folgen Sie nicht dem Polling-Intervall, das im utils ntp-Status angezeigt wird. Eine Sniffer-Erfassung hat alle 60 Sekunden 8 NTP-Abfragen (Beispiel) aufgedeckt. Dies liegt in erster Linie daran, dass die NTP-Implementierung NTP-Watchdog verwendet und wie ntpdate den NTP-Server in der UC-Implementierung abfragt.

Verwendete NTP-Version identifizieren

Hinweis: Der CUCM Publisher ist mit einem externen NTP-Server konfiguriert, und der zum Cluster hinzugefügte Subscriber synchronisiert sich mit dem Publisher.

Hinweis: Für CUCM-Versionen 9.x und höher muss der NTPv4-Server als bevorzugter NTP-Server konfiguriert werden.

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

CUCM sendet ein NTPv4-Paket, und als Antwort erhalten Sie ein NTPv3-Paket. Obwohl NTPv4 abwärtskompatibel zu NTPv3 ist, variiert die CUCM-Implementierung von NTP, was zu nicht synchronisiertem 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 dieses Problem zu beheben, empfiehlt Cisco die Verwendung eines Linux-basierten externen NTP-Servers oder eines Cisco IOS® oder IOS XE-basierten NTP-Servers und die Konfiguration von NTPv4.

Im Folgenden wird die NTP-Terminologie in der NTP-Statusausgabe beschrieben:

- Die Spalte Refid gibt die Zeitquelle der Fernbedienung an. LOCAL(0) ist die lokale Hardware-Uhr. .INIT. bedeutet, dass die Initialisierung noch nicht erfolgreich war.

- Die erste Spalte ist die Schicht des Remote-NTP-Servers. 16 ist ein ungültiger Stratum-Wert, der bedeutet, dass dieser Server nicht als Zeitanbieter angesehen wird. Die Schicht kann aus verschiedenen Gründen ungültig sein, wobei die gängigste davon ist, dass der "Zeitanbieter nicht synchronisiert", die "konfigurierte Quelle nicht vorhanden" oder der "NTP-Server nicht ausgeführt" sind.

- Die Spalte t gibt den Servertyp an (l: Lokal; u: Unicast; m: Multicast oder b: Broadcast).

- Die Spalte When gibt an, wie viele Sekunden vor dem Abruf der Remote-Sitzung vergangen sind.

- Die Spalte Polling gibt das Polling-Intervall in Sekunden an. Beispiel: "64" bedeutet, dass die Fernbedienung alle 64 Sekunden abgefragt wird. Das kürzeste Intervall, das NTP verwendet, beträgt alle 64 Sekunden, das längste 1.024 Sekunden. Je besser eine NTP-Quelle im Laufe der Zeit bewertet wird, desto länger dauert das Intervall. (Die UC-Implementierung entspricht nicht dem hier definierten Intervall.)

- Die Spalte "Reichweite" gibt den Trend zu Erreichbarkeitstests im Oktal an, wobei jede Ziffer beim Konvertieren in eine Binärdatei angibt, ob eine bestimmte Abfrage erfolgreich (Binärzahl 1) oder nicht erfolgreich (Binärzahl 0) war. Beispielsweise bedeutet "1", dass bisher nur eine Umfrage durchgeführt wurde und 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 dazugehörige Umfrage erfolglos war und die Umfrage davor erfolgreich war.

- Die Verzögerungsspalten, Offsetspalten und Jitter sind die Round-Trip-Verzögerung, Dispersion und Jitter in Millisekunden.

Diagnose von NTP-bezogenen Problemen in CUCM

Gehen Sie wie folgt vor, um NTP-bezogene Probleme zu diagnostizieren:

1. Stellen Sie sicher, dass CUCM mit dem NTP-Server an Port 123 kommunizieren kann.

2. Abrufen der Ausgabe des utils ntp-Status.

- Die Stratum-Ebene sollte für Herausgeber weniger als 4 betragen, um eine optimale Leistung zu gewährleisten.

- Wenn mehrere NTP-Server konfiguriert sind, stellen Sie sicher, dass mindestens der Server erreichbar ist. Sie sollten das (*)-Symbol für den NTP-Server sehen, der von CUCM als Referenz verwendet wird.

3. Überprüfen Sie den Syslog-Alarm, und ergreifen Sie die entsprechenden Maßnahmen. Mögliche Ursachen für Syslog-Alarme sind:

- Ein externer NTP-Server ist nicht erreichbar.

- Die NTP-Schicht ist höher als der zulässige Grenzwert.

- Der Publisher ist ausgefallen, sodass das Subscriber NTP nicht synchronisiert ist.

- Wenn ntpdate -q-bezogene Warnmeldungen angezeigt werden, ist es möglich, dass die NTP-Version 4.2.6+ mit aktivierter Kiss of Death (KoD)-Funktion aktiviert ist. (Das Mindestintervall zwischen Burst- und Burst-Paketen, die von einem Client gesendet werden, beträgt zwei, was nicht gegen diese Einschränkung verstößt. Pakete, die von anderen Implementierungen gesendet werden, die diese Einschränkung verletzen, werden verworfen und ein KoD-Paket wird zurückgegeben (falls aktiviert). Es wird empfohlen, diese Funktion zu deaktivieren, wenn Sie diese Version als NTP-Server für ein UC-Produkt verwenden.

4. Verwenden Sie dieses Diagnosemodul, um zu überprüfen, ob der NTP-Server konfiguriert ist.

- utils diagnose module ntp_reachability

- utils diagnose module ntp_clock_drift

- utils diagnose module ntp_stratum

5. Geben Sie utils ntp restart ein, um den NTP-Client/Server neu zu starten. Dieser Befehl ist nützlich, wenn eine Brutzeitkorrektur sofort durchgeführt werden muss oder wenn externe Server immer noch erreichbar und betriebsbereit sind, die Synchronisierung jedoch 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 auf dem CUCM

Cisco Bug-ID CSCue18813: Steuerung des NTP-Konfigurationsparameters "tos maxdist" über CLI

Auflösung: Der Fall Cisco Technical Assistance Center sollte ausgelöst werden, um den tos maxdist-Parameter in der Datei ntp.conf manuell hinzuzufügen.

Cisco Bug-ID CSCuq70611: Der NTP-Stratum-Test wird mit einem einzelnen NTP-Server nicht ordnungsgemäß validiert.

Feste Version: 2,10000,005

Cisco Bug-ID CSCui85967: CUCM-Sprungs-Upgrade von 6.1.5 auf 9.1.2 fehlschlägt aufgrund fehlender NTP-Referenz

Auflösung: Die Dokumentation für das Upgrade wurde aktualisiert, und die NTP-Konfiguration wird als eine der Aufgaben vor dem Upgrade aufgeführt.

Cisco Bug-ID CSCtw46611:  NTP-Synchronisierung fehlschlägt aufgrund falscher Kennzeichnung des Dateisystems capture.txt

Feste Version: 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 Lösung besteht darin, den ESXi-Server und den CUCM Publisher so zu konfigurieren, dass sie auf denselben NTP-Server zeigen.