排除Unified Communications Manager上的NTP故障

简介

本文档介绍如何对思科统一通信(UC)产品上的网络时间协议(NTP)问题进行故障排除。

先决条件

要求

本文档没有任何特定的要求。

使用的组件

本文档不限于特定的软件和硬件版本。

本文档中的信息都是基于特定实验室环境中的设备编写的。本文档中使用的所有设备最初均采用原始（默认）配置。如果您的网络处于活动状态，请确保您了解所有命令的潜在影响。

背景信息

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

• CUCM节点上的时间已同步。
• 在任何对时间敏感的配置更改（例如证书重新生成）之前，时间是正确的。
• 在群集中的所有节点上同步数据库复制。

统一通信产品中的NTP轮询机制

CUCM使用NTP监视器以使时间与NTP服务器保持同步。NTP监视器定期轮询已配置的外部NTP服务器，如果时间偏移超过三秒，则重新启动NTP。

NTP守护程序定期更正时间，但以毫秒为单位进行更正。重新启动NTP涉及运行NTP单次快照以执行总时间更正，然后重新启动NTP守护程序以继续进行常规微更正。

NTP Watchdog在VMware上每分钟轮询NTP一次，在物理计算机上每30分钟轮询一次。VMware的轮询间隔更短，因为虚拟机(VM)中的时钟比物理计算机上的时钟更不稳定，而且VMotion和Storage Migration等VMware功能会对时间产生负面影响。

必须始终配置在VMware上运行的主节点，以便与在物理计算机上运行的外部NTP服务器同步，以补偿VM中较高的时间漂移或延迟。辅助节点始终自动配置为参考主节点NTP服务器，以确保集群中的所有节点及时关闭。

NTP Watchdog会跟踪其重新启动NTP守护程序的速率，以便执行由于VMWare VMotions和存储迁移而导致的粗略时间更正。如果此速率超过每小时10次重新启动，则NTP监视器将推迟进一步重新启动，直到所需的重新启动速率降至每小时10次以下。VMotions和存储迁移的总速率不能超过每小时10次，因为此速率被视为过高。

由于此NTP监视器实施，您不必遵循轮询间隔，可在utils 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

为了解决此问题，思科建议您使用基于Linux的外部NTP服务器或Cisco IOS^®或Cisco IOS® XE NTP服务器，并确保配置了NTPv4。

以下是NTP状态输出中NTP术语的说明：

• Refid列指示远程时间源。LOCAL(0)是本地硬件时钟。.INIT.表示初始化尚未成功。
  
  
• st列是远程NTP服务器的层。16是无效的层值，这意味着此服务器不被视为时间提供程序。层级可能因各种原因无效。其中最常见的是时间提供程序未同步、配置的源不存在或ntp服务器未运行。
  
  
• t列指示服务器类型（l：本地；u：单播；m：组播或b：广播）。
  
  
• when列指示查询远程数据库的秒数。
  
  
• 轮询列以秒为单位表示轮询间隔。例如，64表示远程设备每64秒轮询一次。NTP使用的最短间隔为每64秒，最长间隔为1,024秒。随着时间的推移，NTP源的评级越高，间隔越长。（统一通信实施未遵循此处定义的间隔。）
  
  
• reach列以八进制表示可达性测试的趋势，其中每个数字在转换为二进制时表示特定轮询是成功（二进制1）还是失败（二进制0）。例如，1表示到目前为止只进行了一次轮询，并且轮询成功。3 （=二进制11）表示最后两个轮询成功。7 （=二进制111）表示最后三个轮询成功。17 （=二进制1 111）表示最后四个轮询成功。15 （=二进制1 101）表示最后两个轮询成功。之前的轮询未成功，而之前的轮询未成功。
  
  
• delay、offset和jitter列是往返延迟、色散和抖动（以毫秒为单位）。

诊断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
   • 实用工具诊断模块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实例之间的时间同步问题

解决方法：使用此解决方法禁用VM与ESXi主机的NTP同步。另一种解决方法是将ESXi服务器和CUCM Publisher配置为指向同一NTP服务器。