NTP not working?

Your offset is -36260, which means your clock is currently 36260 clock ticks to slow from sync. With a number this big, your router will take at very long time to get in sync. This number DOES NOT MEAN that the "ntp clock-period" is off by 36260!

To fix this, do a "no ntp clock-period", write the config and reboot. I'll bet you copied the config from one router to another and did not remove this from the config. Never apply a "ntp clock-period" statement from one router to the other. This value is used to adjust the internal clock and represents the number of "clock ticks" that make up one second. This number is different on EVERY router, and NTP adjusts this value to keep the real-time clock of the router in sync. For each NTP poll cycle the maximum that this value can change is 1. If the number is off by a signficant amount (more than a few hundred) it can take weeks, months or even years to get the clock in sync. By removing it, NTP will compute this value to something that is pretty close to its required value, and the real-time clock should sync in a couple hours.

Scott

I'm pretty certain that this is the router that I configured via SDM right out of the box. But I followed your suggestion anyway, and now i get:

router1#sh ntp assoc

address ref clock st when poll reach delay offset disp ~192.168.2.2 192.168.70.2 2 128 1024 377 1.2 -16870

0.1 * master (synced), # master (unsynced), + selected, - candidate, ~ configured

router1#sh ntp assoc detail

192.168.2.2 configured, insane, invalid, stratum 2 ref ID 192.168.70.2, time C9BFA79A.C069D22B (09:51:38.751 PDT Thu Apr 5 2007) our mode client, peer mode server, our poll intvl 1024, peer poll intvl 1024 root delay 171.86 msec, root disp 11044.57, reach 377, sync dist 11131.180 delay 1.19 msec, offset -16870.0905 msec, dispersion 0.09 precision 2**6, version 3 org time C9BFAA2E.CC720352 (10:02:38.798 PDT Thu Apr 5 2007) rcv time C9BFAA3F.AB57B515 (10:02:55.669 PDT Thu Apr 5 2007) xmt time C9BFAA3F.AB08D244 (10:02:55.668 PDT Thu Apr 5 2007) filtdelay = 1.19 1.17 1.16 1.16 1.17 1.17 1.17 1.16 filtoffset = -16870. -16870. -16870. -16869. -16869. -16869. -16869.

-16869. filterror = 0.02 0.03 0.05 0.06 0.08 0.09 0.11

0.12

router1#ping 192.168.2.2

Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.2.2, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms

router1#ping 192.168.70.2

Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.70.2, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 176/178/180 ms

Why is my working time server insane and invalid, yet strata 2 and not

16? And, FWIW, many other systems use 192.168.2.2 (a W2K3 AD server... gag, not my choice) as their time server, and they all work. Including hosts on the same subnet as this router.

192.168.70.2 is another W2K3 AD server in Paris which is reachable over a VPN.

Thanks for your help and insight! :-)

John,

In general, the Windows W32TIME NTP server is not compatible with the IOS NTP implementation.

CSCed13703 Externally found moderate defect: Junked (J) NTP will not sync, flags server as insane, invalid Release-note: An IOS system may be unable to synchronize to an NTP server despite being able to transmit to and receive packets from the server. This may be seen with a Windows system running the w32time service. 'show ntp associations detail" will show that the server is flagged as "insane, invalid". The "root dispersion" value will be seen as being in excess of 1000 ms, which will cause the IOS NTP implementation to reject the association. Workaround: instead of running the w32time service on the Windows system, use NTP 4.x - see

Your NTP server's root dispersion value is really large, over 11 seconds, so there's no way it should be used as a time source.

Regards,

Aaron

What the heck does that mean??? :-)

I'm not surprised at all about Windows Time Service being the issue. However, every other NTP server I try to use results in:

router1#sh ntp assoc

address ref clock st when poll reach delay offset disp ~10.3.3.18 0.0.0.0 16 3 64 0 0.0 0.00

16000. * master (synced), # master (unsynced), + selected, - candidate, ~ configured router1#sh ntp assoc det router1#sh ntp assoc detail 10.3.3.18 configured, insane, invalid, unsynced, stratum 16 ref ID 0.0.0.0, time 00000000.00000000 (16:00:00.000 PST Wed Dec 31 1899) our mode client, peer mode unspec, our poll intvl 64, peer poll intvl 64 root delay 0.00 msec, root disp 0.00, reach 0, sync dist 0.000 delay 0.00 msec, offset 0.0000 msec, dispersion 16000.00 precision 2**5, version 3 org time C9BFF7F5.53FB267C (15:34:29.328 PDT Thu Apr 5 2007) rcv time C9BFF800.AD499EAE (15:34:40.676 PDT Thu Apr 5 2007) xmt time C9BFF800.AD1896EC (15:34:40.676 PDT Thu Apr 5 2007) filtdelay = 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 filtoffset = 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 filterror = 16000.0 16000.0 16000.0 16000.0 16000.0 16000.0 16000.0 16000.0

Perfectly working NTP servers that I can use to sync other Linux machines. 10.3.3.18 is on the same subnet as router1 The Windows server at least looked like it might have sort of tried to work. Nothing else even comes close.

reach = 0 No packets were returned to the NTP process in the router. Look for access list problems. What ip address did NTP use when sending? /hjj

~ On Thu, 05 Apr 2007 12:27:36 -0700, Aaron Leonard wrote: ~ > John, ~ >

~ > In general, the Windows W32TIME NTP server is not compatible with the IOS ~ > NTP implementation. ~ >

~ > CSCed13703 ~ > Externally found moderate defect: Junked (J) ~ > NTP will not sync, flags server as insane, invalid ~ > ~ > Release-note: ~ > ~ > An IOS system may be unable to synchronize to an NTP server ~ > despite being able to transmit to and receive packets ~ > from the server. This may be seen with a Windows system ~ > running the w32time service. ~ > ~ > 'show ntp associations detail" will show that the server is ~ > flagged as "insane, invalid". The "root dispersion" value ~ > will be seen as being in excess of 1000 ms, which will cause ~ > the IOS NTP implementation to reject the association. ~ > ~ > Workaround: instead of running the w32time service on the ~ > Windows system, use NTP 4.x - see ~ >

>

~ > Your NTP server's root dispersion value is really large, over 11 seconds, ~ > so there's no way it should be used as a time source. ~ ~ What the heck does that mean??? :-)

It means that your NTP server is saying that its time is as much as 11 seconds off from the root (stratum 1) of its NTP tree. This is bad.

~ I'm not surprised at all about Windows Time Service being the issue. ~ However, every other NTP server I try to use results in:

[ as the other poster noted, the reach=0 means that you are getting no packets from these servers. ]

Good luck,

Aaron