Prev: Etherchannel - which mode should I use?
Next: Sell your Routers and Switches for free on our Forum
From: Rob on 3 Dec 2009 04:15
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: Uli Link on 3 Dec 2009 04:38
Rob schrieb:
> 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.

Updated IOS to 12.4(20)T or newer?

--
ULi
From: Rob on 3 Dec 2009 04:42
Uli Link <ul.mcamafia(a)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?
From: Uli Link on 3 Dec 2009 07:54
Rob schrieb:
> Uli Link <ul.mcamafia(a)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.

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
From: Rob on 3 Dec 2009 08:16
Uli Link <ul.mcamafia(a)usenet.cnntp.org> wrote:
> Rob schrieb:
>> Uli Link <ul.mcamafia(a)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.
 |  Next  |  Last
Pages: 1 2 3
Prev: Etherchannel - which mode should I use?
Next: Sell your Routers and Switches for free on our Forum