ntp won't lock

Rob schrieb:

Updated IOS to 12.4(20)T or newer?

No. IOS is 12.4(15)T9 (sorry I forgot to include that in the posting)

Does it have a bug here?

Not one I'm aware of in the ntp corner.

You can restore the ntp clock-period value from startup-config or known-good backup of startup-config only if it is from the very same hardware. If you don't have a well settled ntp clock-period value for this box, delete it from running config and allow the box a few days for converging before saving the config.

The 870 hardware does not have a hardware clock and the like to drift under heavy load or maybe a saturated upstream.

Ok. Maybe I'll update it, but it will then probly not solve it.

The problem was already apparent when there was no clock-period in the config yet. It has existed from the initial setup of this router. On other routers in our network this doesn't happen but none of them is an 877. Another 876 works OK.

It happens all the time, loaded network or not. CPU usage on the box is between 5 and 10 %. What is so strange is that it quickly wanders away (or at least appear to do this in "sh ntp as") when it is synchronized, yet it remains well on-time once it has lost lock. It is always around 250 ms off the correct time.

I'm confused...

Thanks for your attention.

A router is generally a poor choice of server unless there is no other. A router has other work to do and cannot always spare the time to keep a good clock. Its clock is generally good enough for timestamping its logs but that's all.

This is a bit different topic. What I want to debug now is a router that is incapable of maintaining sync to an external NTP server (which isn't a router but the NTP server of the ISP the router is connected to)

That router is not used as an NTP server for other systems.

In fact I would like to use (another) router as the company NTP server, because we are in the process of putting all servers under VMware and thus a server isn't a suitable NTP server either. But again, that is a different topic, not what I want to solve in this thread.

Rob,

Due to a recent hardware revision in the 85x/87x routers, you'll need to upgrade IOS to get [S]NTP to work right.

Not affected Affected devices Part Revision Part Revision C878 74-3500-05 C0 74-3500-05 D0 C871 74-3498-05 C0 74-3498-05 D0 C851 74-3488-05 C0 74-3488-05 D0 C877 74-3501-05 C1 74-3501-06 A0 C857 74-3502-05 C1 74-3502-06 A0 C876 74-3499-05 B1 74-3499-05 C0 C877M 74-4674-04 A0 74-4674-04 B0

Fixed via CSCta86311 in 15.0(1)M 12.4(24)T2 12.4(22)T3 12.4(20)T4 12.4(15)T10.

Hth,

Aaron

Thanks for the information!

I will try to get the updated IOS and install it.

Rob

That suggests the clock frequency is out by more than 500ppm.

I have upgraded the IOS and the issue is indeed resolved. Thanks again.

~ > Due to a recent hardware revision in the 85x/87x routers, you'll ~ > need to upgrade IOS to get [S]NTP to work right. ~ ~ I have upgraded the IOS and the issue is indeed resolved. Thanks again.

Great, thanks for the confirmation.

Aaron

Rob, what version of IOS did you move to? I upgraded my 871W to 12.4. (24)T2 and I still have the NTP problem on this router.

This is a version in the same train that came with the router originally. Unfortunately it does not contain recent ADSL firmware so I separately downloaded and installed that (adsl_alc_20190_4.0.018.bin). This fixes problems I had with the ADSL line.

~ On Dec 4 2009, 10:39 am, Aaron Leonard wrote: ~ > ~ > Due to a recent hardware revision in the 85x/87x routers, you'll ~ > ~ > need to upgrade IOS to get [S]NTP to work right. ~ > ~ ~ > ~ I have upgraded the IOS and the issue is indeed resolved.  Thanks again. ~ >

~ > Great, thanks for the confirmation. ~ >

~ > Aaron ~ ~ Rob, what version of IOS did you move to? I upgraded my 871W to 12.4. ~ (24)T2 and I still have the NTP problem on this router.

There are really two aspects here:

1. The hardware change to the 85x/87x routers. This triggered clocking problems (regardless of IOS train), which were remedied in software by CSCta86311 in 15.0(1)M 12.4(24)T2 12.4(22)T3 12.4(20)T4 12.4(15)T10.

(Since you have 12.4(24)T2, I guess this doesn't apply to you.)

1. The replacement in IOS of NTPv3 by NTPv4. This happened in 12.4(20)T.

Our NTPv4 code at present is quite a bit more finicky than NTPv3. (See for example CSCsy39514 [NTP: Clock synchronization lost after a while], which is marked U at present, but which I doubt has vanished.)

If it's an option for you, you could configure SNTP rather than NTP - SNTP is quite un-finicky.