Prev: Etherchannel - which mode should I use?
Next: Sell your Routers and Switches for free on our Forum
From: Richard B. Gilbert on 3 Dec 2009 08:42
Rob wrote:
> 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.

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.
From: Rob on 3 Dec 2009 10:04
Richard B. Gilbert <rgilbert88(a)comcast.net> wrote:
> 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.
From: Aaron Leonard on 3 Dec 2009 15:28
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

---

~ 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.

From: Rob on 3 Dec 2009 16:13
Aaron Leonard <Aaron(a)Cisco.COM> wrote:
> 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
From: David Woolley on 3 Dec 2009 16:43
Rob wrote:

> 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.

>
First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: Etherchannel - which mode should I use?
Next: Sell your Routers and Switches for free on our Forum