排除Unified Communications Manager上的NTP故障

簡介

本文檔介紹如何對思科統一通訊(UC)產品上的網路時間協定(NTP)問題進行故障排除。

必要條件

需求

本文件沒有特定需求。

採用元件

本文件所述內容不限於特定軟體和硬體版本。

本文中的資訊是根據特定實驗室環境內的裝置所建立。文中使用到的所有裝置皆從已清除（預設）的組態來啟動。如果您的網路運作中，請確保您瞭解任何指令可能造成的影響。

背景資訊

Cisco Unified Communications Manager (CUCM)要求配置NTP以確保：

• CUCM節點上的時間同步。
• 在任何對時間敏感的配置更改（如證書重新生成）之前，時間是正確的。
• 資料庫復寫會在叢集中的所有節點上同步。

UC產品中的NTP輪詢機制

CUCM使用NTP監視器以保持時間與NTP伺服器同步。NTP監視器定期輪詢已配置的外部NTP伺服器，如果時間偏移超過三秒，則重新啟動NTP。

NTP守護程式定期更正時間，但以毫秒為單位進行更正。重新啟動NTP涉及運行NTP單次嘗試以執行總時間更正，然後重新啟動NTP守護程式以繼續進行常規微校正。

NTP Watchdog在VMware上每分鐘輪詢一次NTP，在物理電腦上每隔30分鐘輪詢一次。VMware的輪詢間隔較短，因為虛擬機器(VM)中的時鐘比物理電腦上的時鐘更不穩定，而且VMware功能（如VMotion和儲存遷移）會對時間產生負面影響。

必須始終配置在VMware上運行的主節點，以便與在物理電腦上運行的外部NTP伺服器同步，以補償VM中較高的時間漂移或延遲。輔助節點始終自動配置為引用主節點NTP伺服器，以確保集群內的所有節點及時關閉。

NTP Watchdog會跟蹤其重新啟動NTP後台程式以進行因VMWare VMotions和儲存遷移而導致的總體時間更正的速率。如果此速率超過每小時10次重新啟動，則NTP監視器將推遲進一步重新啟動，直到所需的重新啟動速率降低到每小時10次以下。VMotions和儲存遷移的總速率不能超過每小時10次，因為此速率被認為過高。

由於此NTP監視程式實施，因此您不遵循輪詢間隔（在實用的ntp狀態中可見）。嗅探器捕獲顯示每60秒有8個NTP輪詢（示例）。這主要是因為NTP實現使用NTP監視程式，以及ntpdate如何在UC實現中輪詢NTP伺服器。

確定使用的NTP版本

注意：CUCM發佈伺服器配置有外部NTP伺服器，增加到集群的使用者將與發佈伺服器同步。

注意：CUCM版本9.x及更高版本要求將NTPv4伺服器配置為首選NTP伺服器。

運行嗅探器捕獲，以辨識配置的NTP伺服器使用的NTP版本：

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傳送NTPv4資料包，作為響應，您收到NTPv3資料包。雖然NTPv4與NTPv3向後相容，但CUCM對NTP的實施有所不同，這會導致不同步的NTP：

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

為了解決此問題，Cisco建議您使用基於Linux的外部NTP伺服器或Cisco IOS^®或Cisco IOS® XE NTP伺服器，並確保配置了NTPv4。

以下是NTP狀態輸出中NTP術語的說明：

• refid列指示遠端時間源。LOCAL(0)是本地硬體時鐘。.INIT.表示初始化尚未成功。
  
  
• st列是遠端NTP伺服器的層。16是無效的層級值，表示此伺服器不視為時間提供者。層級可能因各種原因而無效。其中最常見的是，時間提供程式未同步、配置的源不存在或ntp伺服器未運行。
  
  
• t列指示伺服器型別（l：local；u：單播；m：組播或b：廣播）。
  
  
• when列指示在多少秒之前查詢了遠端裝置。
  
  
• 輪詢列以秒為單位表示輪詢間隔。例如，64表示每64秒輪詢一次遠端裝置。NTP使用的最短間隔為每64秒，最長為1,024秒。NTP源的分級時間越長，間隔越長。（UC實施未遵循此處定義的間隔。）
  
  
• reach列以八進位制表示可達性測試趨勢，其中每一位數字在轉換為二進位制時表示特定輪詢是成功（二進位制1）還是失敗（二進位制0）。例如，1表示到目前為止只進行了一次輪詢，並且成功了。3 （=二進位制11）表示最後兩個輪詢成功。7 （=二進位111）表示最後三個輪詢成功。17 ( = binary 1 111)表示最後四個輪詢成功。15 （=二進位1 101）表示最後兩個輪詢成功。之前的輪詢未成功，而之前的輪詢未成功。
  
  
• 延遲、偏移和抖動列是往返延遲、色散和抖動（以毫秒為單位）。

診斷CUCM中的NTP相關問題

要診斷與NTP相關的問題，請完成以下步驟：

1. 確保CUCM可以與埠123上的NTP伺服器通訊。
   
   
2. 獲取utils ntp status的輸出。
   
   
   • 發佈伺服器上的層級可以小於4，以獲得最佳效能。
   • 如果配置了多個NTP伺服器，請確保至少可以訪問一台伺服器；您可以看到作為CUCM參考的NTP伺服器的(*)符號。
   
   
   
3. 檢視系統日誌警報並採取相應的操作。系統日誌警報的可能原因包括：
   
   
   • 無法訪問外部NTP伺服器。
   • NTP層數高於可接受的限制。
   • 發佈伺服器已關閉，因此訂閱伺服器NTP未同步。
   • 如果顯示ntpdate -q相關的警示，則可能是您已啟用Kiss of Death (KoD)功能的NTP版本4.2.6+。(根據設計，任何客戶端傳送的突發和突發資料包之間的最小間隔為兩個，這不會違反此限制。違反此限制的其他實作所傳送的封包可能會被捨棄，而且會在啟用時傳回KoD封包)。將該版本用作UC產品的NTP伺服器時，建議停用此功能。
   
   
   
4. 使用此診斷模組以驗證是否配置了NTP伺服器。
   • 實用工具診斷模組ntp_reachability
   • 實用工具診斷模組ntp_clock_drift
   • utils診斷模組ntp_stratum
   
   
   
5. 輸入utils ntp restart以重新啟動NTP客戶端/伺服器。每當需要立即執行總時間更正，或者外部伺服器仍然可以訪問並且運行正常，但同步失敗時，此命令就非常有用。請使用utils ntp status命令來確定外部NTP伺服器的運行狀態。

CUCM上NTP關聯的常見已知問題

思科漏洞ID CSCue18813：透過CLI控制的NTP配置tos maxdist引數

解決方案：可以提出Cisco技術支援中心案例，以便在ntp.conf檔案中手動增加tos maxdist引數。

思科漏洞ID CSCuq70611： NTP層數測試無法使用單個NTP伺服器進行正確驗證

固定版本：10.5(2.10000.005)

思科漏洞ID CSCui85967：由於缺少NTP參考，CUCM從6.1.5升級到9.1.2失敗

解決方案：升級文檔已更新，NTP配置列為升級前任務之一。

思科漏洞ID CSCtw46611：NTP同步失敗，因為capture.txt的檔案系統標籤不正確

固定版本：8.6(2.24900.017)

思科漏洞ID CSCur94973：M1遷移期間VMHost與VM例項之間的時間同步問題

解決方案：使用此解決方法停用虛擬機器與ESXi主機的NTP同步。另一種解決方法是將ESXi伺服器和CUCM發佈伺服器配置為指向同一NTP伺服器。