排除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)中的时钟比物理机中的时钟稳定性低，而且VMotion和Storage Migration等VMware功能会对时间产生负面影响。

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

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

由于此NTP Watchdog实施，您不会遵循轮询间隔，这在实用程序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:unicast;m:multicast，或b:broadcast）。
  
  
• 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服务器。
   • 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参数。

Cisco Bug ID CSCuq70611:NTP Stratum测试无法通过单个NTP服务器正确验证

固定版本：10.5(2.10000.005)

Cisco Bug ID CSCui85967：由于NTP参考丢失，CUCM从6.1.5到9.1.2的升级失败

解决方案：升级文档已更新，NTP配置作为升级前任务中的一项列出。

Cisco Bug ID CSCtw46611：由于capture.txt的文件系统标记不正确，NTP同步失败

固定版本：8.6(2.24900.017)

思科漏洞ID CSCur94973：在M1迁移期间，VMHost与VM实例之间的时间同步问题

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