ntp clock-period not being configured

katerina.dardoufa · ‎08-05-2010

My company has recently upgraded to IOS c2801-adventerprisek9-mz.124-24.T3.bin. All routers routers are configured with two ntp servers. Routers with the above IOS need a great amount of time (even up to a day or more if not triggered manaully - reapply appropriate commands) to synchronize their clocks after a reboot occurs, whereas all other routers need only minutes.
In a cisco site I found the following:
Note: The ntp clock-period command is added automatically to jump-start the NTP frequency compensation when the box is rebooted. (Do not configure this command manually.) This is essentially a representation of the frequency of the crystal used as the local timebase, and may take several days to calculate otherwise. Use the write mem command after a week or so to save a good value.

None of the latest IOS routers have this command. Is there anyway to overcome this problem? Anything else I need to do, so that the ntp clock-period appears?
Is it a bug in the IOS?

Any help will be highly appreciate!

Phillip Remaker · ‎08-05-2010

The clock-period command is added automatically by the system; there is no need (or sense) to enter it as a human. (note the message "Do not configure this command manually") Once the system has a stable sense of what that number is, it will be placed in the config and saved at the next write to NVRAM.

What IOS did you upgrade from? Which of your routers reach the correct time faster? Are they the same hardware as the ones that take a long time?

If you have a high stratum level set, the NTP clients will take a long time to sync as they need to hammer out any delay variations in the network to achieve a time worthy of the configured stratum. That said, if it was working quickly before, something my be wrong.

If you don't have a battery backed clock, the large gap between the default system time and the actual time will contribute to the amount of time it takes to reach a sync as well.

24 hours seems completely unreaasonable unless there is some other contributing factor like a defective system clock or crazy variations in delay on the network. One of the weirdest NTP problems I ever had was a router that had a bad crystal and was running overlocked by a few percent. Since the internal time-of-day clock is referenced to the CPU clock, NTP couldn't sync up, deciding that it's own internal clock was "insane."

katerina.dardoufa · ‎08-12-2010

All of our routers are 2801 and we updated from c2801-adventerprisek9-mz.124-8d.bin. 2801 still running the previous IOS have no problem with ntp. The stratum is 3 as can be seen below:

DRAMA-117#sh ntp status
Clock is synchronized, stratum 3, reference is 10.130.201.3
nominal freq is 250.0000 Hz, actual freq is 250.0303 Hz, precision is 2**24
reference time is D00E49C3.E6336A05 (13:21:55.899 EET2 Thu Aug 12 2010)
clock offset is -0.0091 msec, root delay is 0.12 msec
root dispersion is 0.03 msec, peer dispersion is 0.00 msec
loopfilter state is 'CTRL' (Normal Controlled Loop), drift is -0.000121217 s/s
system poll interval is 256, last update was 235 sec ago.

DRAMA-117#sh ntp associations detail
10.130.201.3 configured, our_master, sane, valid, stratum 2
ref ID 130.149.17.8 , time D00E43F9.88A8AEB9 (12:57:13.533 EET2 Thu Aug 12 2010)
our mode client, peer mode server, our poll intvl 256, peer poll intvl 256
root delay 64.01 msec, root disp 3.75, reach 377, sync dist 251.71
delay 57.40 msec, offset -7.7497 msec, dispersion 10.57
precision 2**18, version 3
org time D00E46C1.F4BF890E (13:09:05.956 EET2 Thu Aug 12 2010)
rec time D00E46C1.FE4C936C (13:09:05.993 EET2 Thu Aug 12 2010)
xmt time D00E46C1.EF8B2B7F (13:09:05.935 EET2 Thu Aug 12 2010)
filtdelay =    57.61   57.41   57.49   63.20   57.40 558.27   57.79   57.75
filtoffset =   -8.49   -8.19   -8.22   -5.71   -7.74 -257.12   -7.05   -6.63
filterror =     0.00    3.84    7.71   11.58   15.40   19.24   23.08   25.02
minpoll = 6, maxpoll = 10

10.150.201.3 configured, sane, valid, stratum 8
ref ID 127.127.7.1   , time D00E4677.C7524725 (13:07:51.778 EET2 Thu Aug 12 2010)
our mode client, peer mode server, our poll intvl 256, peer poll intvl 256
root delay 0.00 msec, root disp 0.03, reach 377, sync dist 49.44
delay 58.08 msec, offset -1.3896 msec, dispersion 11.85
precision 2**18, version 3
org time D00E468D.F7F2022B (13:08:13.968 EET2 Thu Aug 12 2010)
rec time D00E468E.001D219F (13:08:14.000 EET2 Thu Aug 12 2010)
xmt time D00E468D.F129392E (13:08:13.942 EET2 Thu Aug 12 2010)
filtdelay =    58.38   58.60 116.27   58.23   58.08   63.46   58.41   58.18
filtoffset =   -2.71   -2.55 -15.87   -1.75   -1.38   -3.59   -0.65   -0.70
filterror =     0.00    3.85    7.70   11.56   15.43   19.30   23.16   25.09
minpoll = 6, maxpoll = 10

This router has been up and running for 4 weeks but ntp clock-period has not yet apperead!!!! Could it be an IOS bug?

Phillip Remaker · ‎08-12-2010

A suggestion I have seen work for other people:

Issue the command

"no ntp clock-period"

And then save the configuration ("copy run start"). You shouldn't need to do that,but see if it makes a difference.

Also, do you know if these are NTP V3 or V4 peers? Are you using the ntp server or ntp peer commands? The config shows you using NTP version 3. Version 4 no longer uses the clock-period command.

You may need to take this one up with TAC.

Leo Laohoo · ‎08-05-2010

I know when a configuration shown to me is copy-n-pasted by someone because NTP clock-period is in it. NTP clock-period is like a "vice-president": IT's there but has no real use. He he he ...

Leo Laohoo · ‎08-12-2010

This router has been up and running for 4 weeks but ntp clock-period has not yet apperead

Don't worry about the "ntp clock-period". It will not affect the operation of your appliance or the NTP.

Wait a second ...

You are running 12.4(24)T3 right? I've got routers running on 12.4(24)T1 (shame on me!) and here's what happened ...

Router(config)#no ntp clock
%NTP: This configuration command is depreciated.
Router

Phillip Remaker · ‎08-13-2010

Oh, great. Of course, they mean the command is deprecated, not deprciated. (bug submitted: CSCth27054)

So based on that note went and I did some digging. Turns out that as part of the NTPv4 feature addition, the ntp clock-period command was removed.

Why?

The ntp clock-period command was always a concern for developers, since the config file should ideally consist only of user-entered commands. However, back when NTP was first implemented in IOS, the NVRAM was the only possible place to store clock-period information across reboots. In order to ensure quick synchronizations after reboots, the NTP code added as a machine-entered config file entry, even though this was not the ideal solution. Informational bug CSCec87418 was filed on this anomalous implementation, and was "Closed" when the NTP team committed to address the concern in the NTPv4 feature. Since modern IOS implementations now have private NVRAM space called "persistent storage" to hold locally significant data across reboots, clock drift data no longer gets stored in the visible configuration.

The deprecation of the ntp clock-period command is noted in

http://www.cisco.com/en/US/partner/docs/ios/netmgmt/command/reference/nm_10.html#wp1112288

The equivalent new command in NTPV4 to clear the stored drift is "ntp clear drift"

http://www.cisco.com/en/US/docs/ios/ipv6/configuration/guide/ip6-ntpv4_ps6441_TSD_Products_Configuration_Guide_Chapter.html

(Don't let the IPV6 in the title confuse you - a lot of the aspects of this document also apply to IPV4)

Even though the docs indicate that this deprecation happened in 15.0 and later, the commands were actually added in later12.2(x)T releases (I'd have to big to research exactly which one, but that does not matter here). A quick test to see if you have NTPV4: any router which has the "ntp clear drift" command available in exec mode will not have the ntp clock-period command available in configuration mode.

None of this really addresses the REAL problem, which is the fact that sync takes so long.

Do you only have one NTP peer?

Try the command "ntp clear drift" and see if that improves post-reboot sync time.

Message was edited by: Phillip Remaker: Fixed command to "ntp clear drift"; fixed typos.

Leo Laohoo · ‎08-15-2010

Thanks for the information. Mighty useful.

By the way, the command is "ntp clear drift".

katerina.dardoufa · ‎08-16-2010

Wow! Thank you so much for the information

I have configured two ntp servers and I have reverted to ntp version 3, because the "ntp associations details" on the master servers show:

Sw-MK-C6509-R-IS-MHX-A1#sh ntp associations de
127.127.7.1 configured, insane, invalid, stratum 7
precision 2**18, version 3

129.132.98.11 configured, insane, invalid, unsynced, stratum 16
precision 2**5, version 3

193.93.167.241 configured, selected, sane, valid, stratum 2
precision 2**20, version 3

130.149.17.8 configured, our_master, sane, valid, stratum 1
precision 2**27, version 3

193.218.254.1 configured, insane, invalid, stratum 16
precision 2**18, version 3

I thought that maybe ntp version 4 was causing the slow synch, so I changed all routers with the new IOS to run ntp version 3. That didn't help much, so now I am going to issue the "ntp clear drift" command, reload and see what happens.

katerina.dardoufa · ‎08-30-2010

Dear all,

thank you for your input It seems though that the problem was something very simple. All I did was configure ntp source lo0 and the problem disappeared. The debugging showed that after a reboot the ISDN backup first came up, before the actual serial did. So the first ntp messages were sent through the ISDN connection, but when the main line came up, the ntp source was the IP address of the BRI interface (which was now down). Sourcing ntp messaged from the loopback was all that needed to be done.

Thank you for sharing your insight

Richard Burts · ‎09-01-2010

Katerina

Thank you for posting back to the forum with what you have learned about your problem. This was a very interesting bit of troubleshooting. I am sure that many of us will enjoy (and perhaps learn something useful) reading your findings.

HTH

Rick

HTH

Rick