KB ID 0001038 Dtd 26/02/15
I’ve been posting domain time articles for a long time, and on more than one occasion I’ve really needed to take my Windows time from a Cisco Device and failed miserably. I’ve even used third party NTP software to solve this problem on my own test network.
On a client network, my colleague deployed ACS5 this week, I secured the ASA5585-X for AAA and it failed authentication. Logging revealed a clock skew error, so we manually set the time on the domain PDC. Within half an hour it was failing. The network topology prevented me syncing to a public NTP server from the domain PDC.
We did however have all the network devices syncing from a public time source, if only we could use one of those?
Step 1 Configure NTP on your Cisco Device.
Petes-Router#configure terminal Enter configuration commands, one per line. End with CNTL/Z. Petes-Router(config)#ntp server 188.8.131.52 prefer Petes-Router(config)#ntp server 184.108.40.206
NOTE: You need to force the Cisco device to advertise itself with a low stratum, typically the lower the stratum, the closer to atomic time you are supposed to be, (so we are actually forcing the device to lie, but if we don’t, Windows wont trust it!)
Petes-Router(config)#ntp master 5
It can take a while for NTP, (go and have a coffee), then check it’s synchronised, DO NOT proceed until the Cisco device has synchronised.
R1#show ntp status Clock is synchronized, stratum 5, reference is 127.127.1.1 nominal freq is 250.0000 Hz, actual freq is 250.0000 Hz, precision is 2**19 ntp uptime is 364600 (1/100 of seconds), resolution is 4000 reference time is D898D3A0.319A96D4 (23:05:04.193 GMT Wed Feb 25 2015) clock offset is 0.0000 msec, root delay is 0.00 msec root dispersion is 0.26 msec, peer dispersion is 0.23 msec loopfilter state is 'CTRL' (Normal Controlled Loop), drift is -0.000000000 s/s system poll interval is 16, last update was 3 sec ago.
Step 2 Configure Windows to use Cisco NTP Time
In the past I’ve said “Windows Does not use NTP, it uses Win32 Time” This is not strictly true, it does use NTP, but by default it uses ‘Symmetric Active Mode NTP’ and your Cisco Device expects its NTP requests to be submitted via ‘Client Mode NTP‘. (See MS KB 875424 for more info).
Note: By default Windows Domains take their time from the PDC emulator, carry this procedure out on that server!
w32tm /config /manualpeerlist:"220.127.116.11",0x8 /syncfromflags:MANUAL net stop "windows time" net start "windows time" w32tm /resync Note: If you want to specify TWO Cisco devices, use the following syntax w32tm /config /manualpeerlist:"18.104.22.168,22.214.171.124",0x8 /syncfromflags:MANUAL
Now in the Servers System log, you should see the following two events logged.
Event ID 37
Log Name: System Source: Microsoft-Windows-Time-Service Date: 25/02/2015 22:33:19 Event ID: 37 Task Category: None Level: Information Keywords: User: LOCAL SERVICE Computer: 2012-DC-CA.petenetlive.com Description: The time provider NtpClient is currently receiving valid time data from 126.96.36.199, 0x8 (ntp.m|0x8|0.0.0.0:123->188.8.131.52:123).
Event ID 35
Log Name: System Source: Microsoft-Windows-Time-Service Date: 25/02/2015 22:21:17 Event ID: 35 Task Category: None Level: Information Keywords: User: LOCAL SERVICE Computer: 2012-DC-CA.petenetlive.com Description: The time service is now synchronizing the system time with the time source 184.108.40.206, 0x8 (ntp.m|0x8|0.0.0.0:123->220.127.116.11:123).
Windows and Cisco NTP Problems and Errors
Event ID 47
Log Name: System Source: Microsoft-Windows-Time-Service Date: 25/02/2015 22:11:07 Event ID: 47 Task Category: None Level: Warning Keywords: User: LOCAL SERVICE Computer: 2012-DC-CA.petenetlive.com Description: Time Provider NtpClient: No valid response has been received from manually configured peer 18.104.22.168 after 8 attempts to contact it. This peer will be discarded as a time source and NtpClient will attempt to discover a new peer with this DNS name. The error was: The peer is unreachable.
On your Cisco Device you will see debug output like so, (it will repeat 8 times);
Petes-Router#debug ntp all NTP events debugging is on NTP core messages debugging is on NTP clock adjustments debugging is on NTP reference clocks debugging is on NTP packets debugging is on Petes-Router# 000031: Feb 25 22:07:45.831: NTP message received from 22.214.171.124 on interface 'GigabitEthernet0/0' (126.96.36.199). 000032: Feb 25 22:07:45.835: NTP Core(DEBUG): ntp_receive: message received 000033: Feb 25 22:07:45.835: NTP Core(DEBUG): ntp_receive: peer is 0x67A57898, next action is 1. Petes-Router# 000034: Feb 25 22:07:54.967: NTP message received from 188.8.131.52 on interface 'GigabitEthernet0/0' (184.108.40.206). 000035: Feb 25 22:07:54.967: NTP Core(DEBUG): ntp_receive: message received 000036: Feb 25 22:07:54.971: NTP Core(DEBUG): ntp_receive: peer is 0x67A57898, next action is 1. Petes-Router#
This is a pretty generic error, but in this case, one of the following situations can cause this;
3. The stratum of the Cisco NTP device is to high.
4. Windows is attempting to sync time using ‘Symmetric Active Mode NTP‘ See my comments above.