NTP problem on Catalyst 6509

Mar 06, 2006 3 Replies
H

Hi



Would appreciate some pointers....



I've set this box to get NTP from a server 10.15.200.22.



The problem is that although its synchronised, the time shown in the pasted output below ( 14:27:39.599 ) is actually slow by



2523.4011204 seconds or 42 minutes ie the clock offset value - as I took the paste below at 15:11 pm


15:11pm - 14:27 pm = give or take 42 minutes.



Thanks for any help


C6509-6#sh ntp stat Clock is synchronized, stratum 3, reference is 10.15.200.22 nominal freq is 250.0000 Hz, actual freq is 250.0004 Hz, precision is



2**24 reference time is C7B6C55B.99634F1F (14:27:39.599 GMT Mon Mar 6 2006) clock offset is 2523401.1204 msec, root delay is 0.58 msec root dispersion is 4431827.36 msec, peer dispersion is 1908425.95 msec C6509-6#show clock
14:29:47.370 GMT Mon Mar 6 2006 C6509-6#

address ref clock st when poll reach delay offset disp ~10.128.1.11 127.127.7.1 8 3 256 377 1.1 -0.13 0.1



*~10.15.200.22 192.43.244.18 2 59 64 2 0.6 252341
15875. * master (synced), # master (unsynced), + selected, - candidate, ~ configured C6509-6#
Vote
Twitter Facebook LinkedIn
M

Is the 6509 running native IOS or CATOS ?

If the NTP time source is accurate, then try set the clock and the hardware calendar on the 6500

for IOS use the "clock set" and "calendar set" commands to set the current time

then configure the 6509 to have NTP update its calendar

clock calendar-valid

ntp update-calendar

Vote
Twitter Facebook LinkedIn
M

Is the 6509 running native IOS or CATOS ?

If the NTP time source is accurate, then try set the clock and the hardware calendar on the 6500

for IOS use the "clock set" and "calendar set" commands to set the current time

then configure the 6509 to have NTP update its calendar

clock calendar-valid

ntp update-calendar

Vote
Twitter Facebook LinkedIn
T

If the clock-period is way off, it will take a very, very long time for the time to settle to correct time. It will run slow, than fast. I had this problem on a 7200 and the solution is remove all of the ntp server statements and the clock-period statement. Set the time on the switch to the correct time and then add the ntp server statements back. This should solve your problem. The problem comes about when you copy the clock-period statement from one router to another. As an FYI, never, ever, ever copy the clock-period statement from one system to another. The clock-period is set by ntp, to regulate the internal clock. This is the number of system "ticks" in one-second. ntp doesn't change the time of the switch, it adjusts the clock-period so that the system clock is synchronized with the ntp server.

Scott

Vote
Twitter Facebook LinkedIn

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required