ntp won't lock
Rob
On a couple of locations we have Cisco routers and NTP works "ok"
on them (of course, better NTP software exists). But this one router
won't remain locked.
When I remove the NTP server and add it again, and then look with
"sh ntp as", it looks like it is synced but the offset is ever
increasing. After a couple of minutes, the server suddenly is indicated
as unreachable and the offset is smaller again. Sync seems lost but
the time is about right.
output of a couple of "sh ntp as" commands every 80 seconds or so:
address ref clock st when poll reach delay offset disp
*~194.109.22.18 193.67.79.202 2 11 64 377 20.8 49.29 141.1
*~194.109.22.18 193.67.79.202 2 16 64 377 20.5 1084.1 498.6
*~194.109.22.18 193.67.79.202 2 45 64 377 15.4 1877.6 453.2
*~194.109.22.18 193.67.79.202 2 1 64 377 22.2 2942.1 596.1
*~194.109.22.18 193.67.79.202 2 54 64 377 22.2 2942.1 596.1
*~194.109.22.18 193.67.79.202 2 62 64 377 22.2 2942.1 596.1
*~194.109.22.18 193.67.79.202 2 2 64 377 21.2 3207.2 553.8
~194.109.22.18 193.79.237.14 2 30 64 0 20.7 265.03 16000.
Other routers sync OK from this same server....
Config is like this:
ntp clock-period 17179870
ntp server 194.109.22.18 source Dialer10
What could be wrong here?
The clock-period has been inserted by the router itself, as normal.
Uli Link
Updated IOS to 12.4(20)T or newer?
--
ULi
Rob
> 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?
Uli Link
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.
--
ULi
Rob
> Rob schrieb:
>> Uli Link <ul.mc...@usenet.cnntp.org> wrote:
>>> 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.
Ok. Maybe I'll update it, but it will then probly not solve it.
> 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 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.
> The 870 hardware does not have a hardware clock and the like to drift
> under heavy load or maybe a saturated upstream.
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.
Richard B. Gilbert
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.
Rob
> 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.
Aaron Leonard
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
---
~ I have a strange problem with NTP in a Cisco 877.
~
~ On a couple of locations we have Cisco routers and NTP works "ok"
~ on them (of course, better NTP software exists). But this one router
~ won't remain locked.
~
~ When I remove the NTP server and add it again, and then look with
~ "sh ntp as", it looks like it is synced but the offset is ever
~ increasing. After a couple of minutes, the server suddenly is indicated
~ as unreachable and the offset is smaller again. Sync seems lost but
~ the time is about right.
~
~ output of a couple of "sh ntp as" commands every 80 seconds or so:
~
~ address ref clock st when poll reach delay offset disp
~ *~194.109.22.18 193.67.79.202 2 11 64 377 20.8 49.29 141.1
~ *~194.109.22.18 193.67.79.202 2 16 64 377 20.5 1084.1 498.6
~ *~194.109.22.18 193.67.79.202 2 45 64 377 15.4 1877.6 453.2
~ *~194.109.22.18 193.67.79.202 2 1 64 377 22.2 2942.1 596.1
~ *~194.109.22.18 193.67.79.202 2 54 64 377 22.2 2942.1 596.1
~ *~194.109.22.18 193.67.79.202 2 62 64 377 22.2 2942.1 596.1
~ *~194.109.22.18 193.67.79.202 2 2 64 377 21.2 3207.2 553.8
~ ~194.109.22.18 193.79.237.14 2 30 64 0 20.7 265.03 16000.
~
~ Other routers sync OK from this same server....
~
~ Config is like this:
~ ntp clock-period 17179870
~ ntp server 194.109.22.18 source Dialer10
~
~
~ What could be wrong here?
~ The clock-period has been inserted by the router itself, as normal.
Rob
> 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
David Woolley
> When I remove the NTP server and add it again, and then look with
> "sh ntp as", it looks like it is synced but the offset is ever
> increasing. After a couple of minutes, the server suddenly is indicated
> as unreachable and the offset is smaller again. Sync seems lost but
> the time is about right.
That suggests the clock frequency is out by more than 500ppm.
>
Rob
> 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.
I have upgraded the IOS and the issue is indeed resolved. Thanks again.
Aaron Leonard
~ > 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
Steve
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.
Rob
12.4(15)T11
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.
Aaron Leonard
~ On Dec 4 2009, 10:39�am, Aaron Leonard <Aa...@Cisco.COM> 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.)
2. 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.