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和Storage Migration）對時間有負面影響。

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

NTP Watchdog跟蹤其重新啟動NTP守護進程的速率，以更正因VMWare VMotions和儲存遷移而引起的總時間。如果此速率超過每小時10次重新啟動，NTP Watchdog將推遲進一步的重新啟動，直到所需的重新啟動速率下降到每小時10次以下。VMotions和儲存遷移的總速率不能超過每小時10次，因為此速率被認為過高。

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

確定使用的NTP版本

注意:CUCM Publisher配置了外部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向後相容，但NTP的CUCM實施有所不同，這會導致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

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

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

• refid列指示遠端時間源。LOCAL(0)是本地硬體時鐘。.INIT.表示初始化尚未成功。
  
  
• st列是遠端NTP伺服器的層。16是無效的層值，這意味著此伺服器不被視為時間提供程式。層可能因各種原因而無效。其中最常見的是time provider not synchronized、configured source exist或ntp server not running。
  
  
• t列指示伺服器型別（l:local;u:unicast;m:multicast或b:broadcast）。
  
  
• when列表示查詢遠端資料庫的秒數。
  
  
• 輪詢列以秒為單位指示輪詢間隔。例如，64表示遠端裝置每64秒輪詢一次。NTP使用的最短間隔是每64秒，最長是1,024秒。一段時間內NTP源的評級越高，間隔越長。（UC實施未遵循此處定義的間隔。）
  
  
• reach列以八進位制表示可達性測試的趨勢，其中每個數字在轉換為二進位制時表示特定輪詢是成功（二進位制1）還是失敗（二進位制0）。例如，1表示迄今為止只進行過一次投票，並且投票是成功的。3（=二進位制11）表示最後兩次輪詢成功。7(= binary 111)表示最後三個輪詢成功。17（=二進位制1 111）表示最後四個輪詢成功。15(= binary 1 101)表示最後兩個輪詢成功。之前的輪詢未成功，而之前的輪詢未成功。
  
  
• 延遲、偏移和抖動列是往返延遲、色散和抖動（以毫秒為單位）。

診斷CUCM中的NTP相關問題

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

1. 確保CUCM可以與埠123上的NTP伺服器通訊。
   
   
2. 獲取實用程式ntp status的輸出。
   
   
   • 發佈器上的層級可以小於4，以獲得最佳效能。
   • 如果配置了多個NTP伺服器，請確保至少可以訪問一台伺服器；您可以看到與CUCM用作參考的NTP伺服器對應的(*)符號。
   
   
   
3. 檢視系統日誌警報並採取相應措施。系統日誌警報的可能原因包括：
   
   
   • 無法訪問外部NTP伺服器。
   • NTP層數高於可接受的限制。
   • 發佈伺服器已關閉，因此訂閱伺服器NTP不同步。
   • 如果看到與ntpdate -q相關的警報，則可能是您已啟用Kiss of Death(KoD)功能的NTP版本4.2.6+。(根據設計，任何客戶端傳送的突發包和突發包之間的最小間隔為2，這不會違反此約束。違反此約束的其他實現傳送的資料包可能被丟棄，如果啟用，則返回KoD資料包)。將該版本用作UC產品的NTP伺服器時，建議禁用此功能。
   
   
   
4. 使用此診斷模組驗證是否配置了NTP伺服器。
   • utils診斷模組ntp_reachability
   • utils診斷模組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：從6.1.5到9.1.2的CUCM跳轉升級失敗，因為缺少NTP引用

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

思科錯誤ID CSCtw46611：由於capture.txt的檔案系統標籤不正確，NTP同步失敗

固定版本：8.6(2.24900.017)

思科錯誤ID CSCur94973：在M1遷移期間，VMHost與VM例項之間的時間同步問題

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