Contents
Introduction
This document describes a problem that is encountered when the Cisco Identity Services Engine (ISE) and other Linux-based servers fail to synchronize with a Network Time Protocol (NTP) server that is installed on a Microsoft Windows Server. A solution to this problem is also provided.
Prerequisites
Requirements
Cisco recommends that you have knowledge of these topics:
- Cisco ISE CLI configuration
- Basic knowledge about NTP
Components Used
The information in this document is based on these software and hardware versions:
- Microsoft Windows Server Version 2012
- Cisco ISE software Versions 1.3 and later
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.
Problem
After you configure the ISE CLI in order to use the Microsoft Windows Server as NTP, it does not synchronize. The Microsoft Windows Server 2012 default domain controller configuration is used (default NTP configuration). The ISE reports that the local source is still used:
ise14/admin# show ntp
Configured NTP Servers:
10.62.145.72
synchronised to local net at stratum 11
time correct to within 11 ms
polling server every 1024 s
remote refid st t when poll reach delay offset jitter
==============================================================================
*127.127.1.0 .LOCL. 10 l 9 64 377 0.000 0.000 0.000
10.62.145.72 .LOCL. 1 u 226 1024 377 0.896 -3.998 4.130
* Current time source, + Candidate , x False ticker
Warning: Output results may conflict during periods of changing synchronization.
All of the parameters (reachability, delay, offset, and jitter) appear to be correct, and there is no way to troubleshoot the issue from the CLI (NTP synchronization failure). For confirmation of the issue, you must go to the root level and use the NTPQ tool in order to query ntpd daemon for more details:
[root@ise14]# ntpq ntpq> associations ind assID status conf reach auth condition last_event cnt =========================================================== 1 53519 9614 yes yes none sys.peer reachable 1 2 53520 9014 yes yes none reject reachable 1
As shown, there are two associations presented. The 53520 association is marked as rejected. Here are some additional details for that association:
ntpq> mrv 53520 53520 assID=53520 status=9014 reach, conf, 1 event, event_reach, srcadr=10.62.145.72, srcport=123, dstadr=10.62.145.42, dstport=123, leap=00, stratum=1, precision=-6, rootdelay=0.000, rootdispersion=10032.150, refid=LOCL, reach=377, unreach=0, hmode=3, pmode=4, hpoll=10, ppoll=10, flash=400 peer_dist, keyid=0, ttl=0, offset=-32.465, delay=0.898, dispersion=30.345, jitter=4.519, reftime=d96b0358.fe7c815a Tue, Aug 4 2015 11:24:40.994, org=d96b08ed.829514cf Tue, Aug 4 2015 11:48:29.510, rec=d96b08ed.8b022d8d Tue, Aug 4 2015 11:48:29.543, xmt=d96b08ed.8ac74cca Tue, Aug 4 2015 11:48:29.542, filtdelay= 0.90 1.20 0.95 0.93 0.87 0.89 1.19 0.93, filtoffset= -32.47 -27.95 -26.50 -34.32 -27.74 -18.14 -22.54 -23.79, filtdisp= 15.63 30.97 46.32 61.68 77.05 92.44 107.82 115.48
It is possible to confirm that this is the previously configured NTP server (10.62.145.72) for which synchronization fails. Also, the root dispersion parameter is large (above 10,000 ms). Use this information in order to confirm this parameter from the Microsoft Windows Server:
C:\Users\Administrator> w32tm /query /status
Leap Indicator: 0(no warning)
Stratum: 1 (primary reference - syncd by radio clock)
Precision: -6 (15.625ms per tick)
Root Delay: 0.0000000s
Root Dispersion: 10.0000000s
ReferenceId: 0x4C4F434C (source name: "LOCL")
Last Successful Sync Time: 04/08/2015 11:15:32
Source: Local CMOS Clock
Poll Interval: 6 (64s)
The packet captures present the request that is sent from the ISE, with an acceptable root dispersion of one second:
Here is the response from the server, which has a root dispersion that is greater than ten seconds:
As a result, this is not accepted, which causes the ISE to drop the request and continue with the local time source.
Root dispersion is a number that indicates the maximum error relative to the primary reference source at the root of the synchronization subnet. It is increased by every NTP server. By default, the Microsoft server sets the value to ten seconds only when its own local time source is used (in order to indicate that it is not a reliable source of time). When the Microsoft NTP server is configured with an external NTP, this value is derived from the server and the problem does not exist.
Solution
As per the Microsoft documentation, it is possible to configure the LocalRootDispersion value in the registry. Complete these steps in order to configure the registry value:
- Stop the NTP service from PowerShell (optionally, enter the net stop w32time command):
PS C:\Users\Administrator> Stop-Service w32time
- Set the registry value to 0:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config\LocalClockDispersion
- Restart the service (optionally, enter the net start w32time command):
PS C:\Users\Administrator> Start-Service w32time
- Verify that the new value (0) is reported:
C:\Users\Administrator> w32tm /query /status Leap Indicator: 0(no warning) Stratum: 1 (primary reference - syncd by radio clock) Precision: -6 (15.625ms per tick) Root Delay: 0.0000000s Root Dispersion: 0.0000000s ReferenceId: 0x4C4F434C (source name: "LOCL") Last Successful Sync Time: 04/08/2015 11:15:32 Source: Local CMOS Clock Poll Interval: 6 (64s)
The ISE NTPQ tool should now report a low (48 ms) value:
ntpq> mrv 53520 53520 assID=8400 status=9614 reach, conf, sel_sys.peer, 1 event, event_reach, srcadr=10.62.145.72, srcport=123, dstadr=10.62.145.42, dstport=123, leap=00, stratum=1, precision=-6, rootdelay=0.000, rootdispersion=48.431, refid=LOCL, reach=377, unreach=0, hmode=3, pmode=4, hpoll=7, ppoll=7, flash=00 ok, keyid=0, ttl=0, offset=8.206, delay=0.514, dispersion=21.595, jitter=3.456, reftime=d96b0c49.2c834d26 Tue, Aug 4 2015 12:02:49.173, org=d96b175c.d472ead9 Tue, Aug 4 2015 12:50:04.829, rec=d96b175c.d2bf9803 Tue, Aug 4 2015 12:50:04.823, xmt=d96b175c.d284b95f Tue, Aug 4 2015 12:50:04.822, filtdelay= 0.90 0.86 0.51 0.87 0.80 0.82 0.85 0.88, filtoffset= 7.09 5.23 8.21 6.78 2.73 8.43 1.93 9.67, filtdisp= 15.63 17.56 19.48 21.39 23.32 25.24 27.18 29.08
This enables the synchronization to occur as expected:
ntpq> associations ind assID status conf reach auth condition last_event cnt =========================================================== 1 53519 9014 yes yes none reject reachable 1 2 53520 9614 yes yes none sys.peer reachable 1
You can also verify this information from the CLI:
ise14/admin# show ntp Configured NTP Servers: 10.62.145.72 synchronised to NTP server (10.62.145.72) at stratum 2 time correct to within 80 ms polling server every 128 s remote refid st t when poll reach delay offset jitter ============================================================================== 127.127.1.0 .LOCL. 10 l 15 64 377 0.000 0.000 0.000 *10.62.145.72 .LOCL. 1 u 26 128 377 0.514 8.206 3.456 * Current time source, + Candidate , x False ticker Warning: Output results may conflict during periods of changing synchronization.
Additional Issues
Some of the older Microsoft Windows Server versions might have different default NTP settings. Cisco recommends that you verify whether these settings are correct and acceptable by the ISE. Verify these registry settings:
- Change the Enabled flag value to 1 in order to enable the NTP server:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders \NTPServer\Enabled
- Set the Type registry entry to NTP in order to change the server type:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Parameters\Type
- Set the Announce Flags registry entry to 5 in order to indicate a reliable time source:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config \AnnounceFlags
VMware Issues
The NTP synchronization issues might be caused by VMware bug ID 2075424 (ESXi host does not synchronize time with NTP server).
The issue is resolved in these patches:
- VMware ESXi 5.5 Update 1
- VMware ESXi 5.1 Patch 4
- VMware ESXi 5.0 Patch 8
Related Information
转载至https://www.cisco.com/c/en/us/support/docs/security/identity-services-engine/119371-technote-ise-00.html
中文版：
排除故障ISE和Ntp server同步失败Microsoft Windows的
简介
本文描述遇到的问题，当思科身份服务引擎(ISE)时和其他基于linux的服务器发生故障同步用在MS Windows服务器安装的网络时间协议(NTP)服务器。也提供对此问题的一解决方案。
先决条件
要求
Cisco 建议您了解以下主题：
- 思科ISE CLI配置
- 关于NTP的基础知识
使用的组件
本文档中的信息基于以下软件和硬件版本：
- MS Windows服务器版本2012
- Cisco ISE软件版本1.3及以后
本文档中的信息都是基于特定实验室环境中的设备编写的。本文档中使用的所有设备最初均采用原始（默认）配置。如果您使用的是真实网络，请确保您已经了解所有命令的潜在影响。
问题
在您配置ISE CLI为了使用MS Windows服务器作为NTP后，不同步。使用MS Windows服务器2012默认域控制器配置(默认NTP配置)。ISE报道仍然使用本地来源：
ise14/admin# show ntp
Configured NTP Servers:
10.62.145.72
synchronised to local net at stratum 11
time correct to within 11 ms
polling server every 1024 s
remote refid st t when poll reach delay offset jitter
==============================================================================
*127.127.1.0 .LOCL. 10 l 9 64 377 0.000 0.000 0.000
10.62.145.72 .LOCL. 1 u 226 1024 377 0.896 -3.998 4.130
* Current time source, + Candidate , x False ticker
Warning: Output results may conflict during periods of changing synchronization.
所有参数(可接通性、延迟、偏移量和抖动)看上去正确和没有办法排除故障从CLI (NTP同步失败)的问题。欲了解更详细的信息对于问题的确认，您必须去根级别和使用NTPQ工具为了查询ntpd守护程序：
[root@ise14]# ntpq ntpq> associations ind assID status conf reach auth condition last_event cnt =========================================================== 1 53519 9614 yes yes none sys.peer reachable 1 2 53520 9014 yes yes none reject reachable 1
如显示，有两个关联被提交。53520关联被标记作为已拒绝。这是该关联的一些其他详细信息：
ntpq> mrv 53520 53520 assID=53520 status=9014 reach, conf, 1 event, event_reach, srcadr=10.62.145.72, srcport=123, dstadr=10.62.145.42, dstport=123, leap=00, stratum=1, precision=-6, rootdelay=0.000, rootdispersion=10032.150, refid=LOCL, reach=377, unreach=0, hmode=3, pmode=4, hpoll=10, ppoll=10, flash=400 peer_dist, keyid=0, ttl=0, offset=-32.465, delay=0.898, dispersion=30.345, jitter=4.519, reftime=d96b0358.fe7c815a Tue, Aug 4 2015 11:24:40.994, org=d96b08ed.829514cf Tue, Aug 4 2015 11:48:29.510, rec=d96b08ed.8b022d8d Tue, Aug 4 2015 11:48:29.543, xmt=d96b08ed.8ac74cca Tue, Aug 4 2015 11:48:29.542, filtdelay= 0.90 1.20 0.95 0.93 0.87 0.89 1.19 0.93, filtoffset= -32.47 -27.95 -26.50 -34.32 -27.74 -18.14 -22.54 -23.79, filtdisp= 15.63 30.97 46.32 61.68 77.05 92.44 107.82 115.48
确认是可能的这是(10.62.145.72)同步失效的以前已配置的Ntp server。并且，根散射参数大(在10,000毫秒上)。请使用此信息为了确认从MS Windows服务器的此参数：
C:\Users\Administrator> w32tm /query /status
Leap Indicator: 0(no warning)
Stratum: 1 (primary reference - syncd by radio clock)
Precision: -6 (15.625ms per tick)
Root Delay: 0.0000000s
Root Dispersion: 10.0000000s
ReferenceId: 0x4C4F434C (source name: "LOCL")
Last Successful Sync Time: 04/08/2015 11:15:32
Source: Local CMOS Clock
Poll Interval: 6 (64s)
数据包捕获提交从ISE发送的请求，与一秒钟可接受根散射：
这是从服务器的答复，有根散射比十秒极大：
结果，这没有接受，造成ISE下降请求和继续本地时间来源。
根散射是指示最大错误相对主要参考源在同步子网的根的编号。它由每Ntp server增加。默认情况下， Microsoft服务器集合对十秒的值，只有当使用时其自己的本地时间来源(为了表明它不是时间可靠的来源)。当Microsoft Ntp server配置与外部NTP时，此值从服务器得到，并且问题不存在。
解决方案
根据Microsoft文档，配置在注册的LocalRootDispersion值是可能的。完成这些步骤为了配置注册表值：
- 从PowerShell终止NTP服务(或者，请输入net stop w32time命令) ：
PS C:\Users\Administrator> Stop-Service w32time
- 设置注册表值对0 ：
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config\LocalClockDispersion
- 重新启动服务(或者，请输入net start w32time命令) ：
PS C:\Users\Administrator> Start-Service w32time
- 验证新的值(0)报告：
C:\Users\Administrator> w32tm /query /status Leap Indicator: 0(no warning) Stratum: 1 (primary reference - syncd by radio clock) Precision: -6 (15.625ms per tick) Root Delay: 0.0000000s Root Dispersion: 0.0000000s ReferenceId: 0x4C4F434C (source name: "LOCL") Last Successful Sync Time: 04/08/2015 11:15:32 Source: Local CMOS Clock Poll Interval: 6 (64s)
ISE NTPQ工具应该当前报告低值(48毫秒) ：
ntpq> mrv 53520 53520 assID=8400 status=9614 reach, conf, sel_sys.peer, 1 event, event_reach, srcadr=10.62.145.72, srcport=123, dstadr=10.62.145.42, dstport=123, leap=00, stratum=1, precision=-6, rootdelay=0.000, rootdispersion=48.431, refid=LOCL, reach=377, unreach=0, hmode=3, pmode=4, hpoll=7, ppoll=7, flash=00 ok, keyid=0, ttl=0, offset=8.206, delay=0.514, dispersion=21.595, jitter=3.456, reftime=d96b0c49.2c834d26 Tue, Aug 4 2015 12:02:49.173, org=d96b175c.d472ead9 Tue, Aug 4 2015 12:50:04.829, rec=d96b175c.d2bf9803 Tue, Aug 4 2015 12:50:04.823, xmt=d96b175c.d284b95f Tue, Aug 4 2015 12:50:04.822, filtdelay= 0.90 0.86 0.51 0.87 0.80 0.82 0.85 0.88, filtoffset= 7.09 5.23 8.21 6.78 2.73 8.43 1.93 9.67, filtdisp= 15.63 17.56 19.48 21.39 23.32 25.24 27.18 29.08
这使同步发生正如所料：
ntpq> associations ind assID status conf reach auth condition last_event cnt =========================================================== 1 53519 9014 yes yes none reject reachable 1 2 53520 9614 yes yes none sys.peer reachable 1
您能也验证从CLI的此信息：
ise14/admin# show ntp Configured NTP Servers: 10.62.145.72 synchronised to NTP server (10.62.145.72) at stratum 2 time correct to within 80 ms polling server every 128 s remote refid st t when poll reach delay offset jitter ============================================================================== 127.127.1.0 .LOCL. 10 l 15 64 377 0.000 0.000 0.000 *10.62.145.72 .LOCL. 1 u 26 128 377 0.514 8.206 3.456 * Current time source, + Candidate , x False ticker Warning: Output results may conflict during periods of changing synchronization.
另外的问题
某些更旧的MS Windows服务器版本也许有不同的默认NTP设置。思科建议您验证这些设置是否由ISE是正确和可接受。验证这些注册表设置：
- 更改Enabled标志位值对1为了启用Ntp server ：
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders \NTPServer\Enabled
- 设置类型注册表条目为NTP为了更改服务器类型：
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Parameters\Type
- 设置宣布标志注册表条目对5为了指示一可靠时间源：
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config \AnnounceFlags
VMware问题
NTP同步问题也许由VMware Bug ID导致2075424 (ESXi主机与Ntp server不同步时间)。
问题在这些补丁程序被解决：
- VMware ESXi 5.5更新1
- VMware ESXi 5.1 Patch4
- VMware ESXi 5.0补丁程序8