RE: NTP - Why NTP not synchronized, yet the router gets correct

From: Scott M Vermillion (scott_ccie_list@it-ag.com)
Date: Sat Nov 01 2008 - 23:35:01 ARST


Hi Huan,

Apologize for the delayed response - I've been hammering away at GCOP
(Gutter Clean Out Protocol), LRP (Leaf Raking Protocol), and MMTSOOtFH
(Moving My Teenage Son Out Of the Freakin' House) lately.

Sorry that didn't pan out for you. Bottom line is that it seems unlikely
that Cisco would somehow penalize you in the lab for something not
synchronizing properly if you've issued the appropriate commands, per their
documentation. I have my c877 edge router synched to an NTP server on the
Internet and all is well. But in preparing for the R&S lab, I found NTP to
be a tad flakey. I didn't stress over it too much, reasoning that this
would likely be a case where they would look for the presence of certain
commands vs. results. Obviously I have no idea whether that's truly the
case or not, but I would think the proctors are quite well aware of just how
inconsistent this whole NTP affair can be.

My thoughts anyway.

Cheers,

Scott
  

-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of Huan
Pham
Sent: Friday, October 31, 2008 6:03 PM
To: 'CCIE Lab'; Scott M Vermillion
Subject: RE: NTP - Why NTP not synchronized, yet the router gets correct
clock?

Hi Scott,
 
Thanks for your suggestion. I tried it, but it gave different results each
time.
 
I am not sure setting the Stratum to 1 does help here, or just the action of
of removing and adding back the NTP peer that actually does help (in some
cases).
 
By default, if you set NTP master without specifying the Stratum, it is set
to
8. In the real lab context, we wont be able to set it freely (1 or 2 as you
suggested), but it has to be according to Lab requirement. For instance, if
the lab ask:
 
Set R2 to get NTP clock from BB1 and R1 but BB1 should be the preffered one
(if availble). In this case, you wont be able to change the Stratum on BB1,
so
if it is set to 8 by default, then on R1 (as another Master), you have to
set
the Stratum to 8 or higher. Otherwise, R2 will always synch to R1 (lower
stratum), even if you put the prefered keyword on the peering to BB1.
 
Cheers,
 
Huan

--- On Fri, 10/31/08, Scott M Vermillion <scott_ccie_list@it-ag.com> wrote:

From: Scott M Vermillion <scott_ccie_list@it-ag.com>
Subject: RE: NTP - Why NTP not synchronized, yet the router gets correct
clock?
To: "'Huan Pham'" <pnhuan@yahoo.com>, "'CCIE Lab'" <ccielab@groupstudy.com>
Date: Friday, October 31, 2008, 2:42 AM

Hi Huan,

I would suggest the following as a possibility:

-Remove the 'ntp server 150.1.6.6' command from R5

-Validate that the association is gone

-Change R6 to 'ntp server 1'

-Reapply the 'ntp server 150.1.6.6' command to R6

Then give it a short time and post back as to whether or not you see a
"sane" and "synchronized" status.

I have never tried setting the server to anything other than Stratum 1 or 2.
In reality, there is no such thing as Stratum 5 (or above), so I'm not sure
that it's valid for a server to be configured for that level. Cisco takes
a
lot of liberties with the whole stratum thing, so it's hard to say one way
or the other. The command reference is silent on the matter and certainly
you can enter anything from 1 to 15. But for lab prep purposes I always
just went with 1 or 2 (obviously a Cisco router can't truly be Stratum 1!).
I just tried setting a server to 5 and met with the same results that you
did. Then I converted it to 1, but the other router still showed as
"insane," even after it reflected the new configured stratum level of
its
server. Only after I removed the config from the client and reapplied it
did I (almost instantly) get a "sane" status.

Let us know...

Scott

-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of Huan
Pham
Sent: Thursday, October 30, 2008 6:44 AM
To: CCIE Lab
Subject: NTP - Why NTP not synchronized, yet the router gets correct clock?

Hi,

This should be a very simple question, but NTP always bugs me.

Scenario is simple. R6 is the NTP master, and R5 is client. It already takes
ages, but I could not get R5 clock synchronized (status = unsynchronized,
insane). Yet, R5 picks up the correct clock from R6, even after I reload the
router.

You may ask to manually set clock of the two routers close to each other,
so the synchronization will speed up. I've done that and it does not help.
Anyway, client already picks up the clock (from the Server), so no need to
manually set it. The question is what can I do to get R5 to show status =
synchronized, and "sane".

Any idea pls?

Rack1R6#sh run | in ntp
ntp source Loopback0
ntp master 5

Rack1R5#sh run | in ntp
ntp server 150.1.6.6

Rack1R5#sh ntp associations detail
150.1.6.6 configured, insane, invalid, stratum 5
ref ID 127.127.7.1, time CCB4C034.A6EF985D (23:22:28.652 UTC Thu Oct 30
2008)
our mode client, peer mode server, our poll intvl 1024, peer poll intvl 1024
root delay 0.00 msec, root disp 8354.68, reach 377, sync dist 8378.571
delay 47.67 msec, offset 154290.0900 msec, dispersion 0.06
precision 2**24, version 3
org time CCB4C049.1D3A1525 (23:22:49.114 UTC Thu Oct 30 2008)
rcv time CCB4BFAE.D9112EC7 (23:20:14.847 UTC Thu Oct 30 2008)
xmt time CCB4BFAE.CCD8B539 (23:20:14.800 UTC Thu Oct 30 2008)
filtdelay = 47.67 47.67 47.96 48.10 47.87 47.85 47.84 47.93
filtoffset = 154290. 154290. 154290. 154290. 154290. 154290. 154290. 154290.
filterror = 0.02 0.03 0.05 0.06 0.08 0.09 0.11 0.12

Rack1R5#sh ntp status
Clock is unsynchronized, stratum 16, no reference clock
nominal freq is 250.0000 Hz, actual freq is 250.0000 Hz, precision is 2**24
reference time is 00000000.00000000 (00:00:00.000 UTC Mon Jan 1 1900)
clock offset is 0.0000 msec, root delay is 0.00 msec
root dispersion is 0.00 msec, peer dispersion is 0.00 msec

(R5 after reload)

Rack1R5#sh clock
*23:25:13.371 UTC Thu Oct 30 2008

This is the same clock from R6.

Blogs and organic groups at http://www.ccie.net



This archive was generated by hypermail 2.1.4 : Mon Dec 01 2008 - 08:18:28 ARST