GroupStudy.com GroupStudy.com - A virtual community of network engineers
 Home  BookStore  StudyNotes  Links  Archives  StudyRooms  HelpWanted  Discounts  Login
RE: NTP - Why NTP not synchronized, yet the router gets correct clock? posted 11/03/2008
[Chronological Index] [Thread Index] [Top] [Date Prev][Date Next] [Thread Prev][Thread Next]


Hi Neil,

Thanks for your sugestion. No, actually I have not thought of that. I
will give it a try next time. Usually I verify the IP connectivity to
the Server (Loopback or physical), before verifying NTP.

For now, I think I will go with Scott V approach (also Scott Morris once
recommended the same): Put the config on, do verification for 1-2
minutes, if it does not get synched, move on and come back later (if
time permits).

Cheers,

-----Original Message-----
From: nobody@xxxxxxxxxxxxxx [mailto:nobody@xxxxxxxxxxxxxx] On Behalf Of
Neil Moore
Sent: Tuesday, 4 November 2008 8:29 AM
To: Hobbs
Cc: Scott M Vermillion; Huan Pham; CCIE Lab
Subject: Re: NTP - Why NTP not synchronized, yet the router gets correct
clock?

Huan,
Have you tried to change the source of the NTP server to another
interface?

Hobbs wrote:
> oh yeah. dont get me wrong. this is a test and you have get your 
> points :) I just used to have hard time with NTP and buckled down now 
> i feel pretty confident and can get it to work 99% of the time. In 
> fact, whenever i get an ntp task on a lab, im usually thinking "3 easy

> points"... :)
> 
> On Mon, Nov 3, 2008 at 10:14 AM, Scott M Vermillion < 
> scott_ccie_list@xxxxxxxxx> wrote:
> 
>> Hey Hobbs,
>>
>> I guess my main point was that you don't want to stress over matters 
>> that are outside of your immediate influence - *especially* in the 
>> lab (and I'm specifically thinking backbone routers and their
configuration here).
>> Serious time can be lost chasing your tail.  If you've properly 
>> configured NTP per your understanding of the task and the 
>> documentation, move on (IMHO).  Obviously you'd come back to it 
>> later, time permitting.  Never forget that the lab is a test of more
than just technical prowess, right?
>> It's mainly about that, but not exclusively.  Again, IMHO.
>>
>> I'm a WAN guy with a background in SATCOM, T-Carrier, and SONET 
>> (etc).  I have a pretty solid grasp of network timing and
synchronization issues.
>> This whole "Stratum 5" (and above) thing is a little humorous to me.
>> Granted, the reasons for "synchronizing clocks" in an IP network are 
>> quite different than the reasons for doing so in the WAN domain.  And

>> I actually do understand the "logic" behind these nonexistent stratum

>> levels.  I just wish they could have found a better/less misleading 
>> syntax, personally speaking.  But I guess there's rarely any value to

>> being a purist, so it's not as though I'm losing any sleep over the 
>> matter.  ;-)
>>
>> Regards,
>>
>> Scott
>>
>>
>> -----Original Message-----
>> From: nobody@xxxxxxxxxxxxxx [mailto:nobody@xxxxxxxxxxxxxx] On Behalf 
>> Of Hobbs
>> Sent: Sunday, November 02, 2008 6:01 PM
>> To: Scott M Vermillion
>> Cc: Huan Pham; CCIE Lab
>> Subject: Re: NTP - Why NTP not synchronized, yet the router gets 
>> correct clock?
>>
>> I don't think checking the clock is proper way to view if routers are

>> synced. You have to view the show ntp commands. On my online racks, 
>> the clock are always the current date and time. They have hardware 
>> clocks right?
>> The only way to be sure if they are synced is if show ntp 
>> assoc/status shows they are. If the times are the same, it doesn't 
>> mean they have synced, or that one router got it from another.
>>
>> And if the task says they should be synced, then I would bet they are

>> going to verify that with "show ntp stat/assoc" not "show run"...
>>
>> I give NTP a hard time but believe it or not, it is a simple protocol

>> to use. You just have to be patient because sync/unsyncing can take a

>> few packets and minutes. Its better to learn it than to chalk it up 
>> to being inherently buggy. If there's something that doesn't seem 
>> right, ask the group :)
>>
>>
>> On Sat, Nov 1, 2008 at 6:35 PM, Scott M Vermillion < 
>> scott_ccie_list@xxxxxxxxx> wrote:
>>
>>> 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@xxxxxxxxxxxxxx [mailto:nobody@xxxxxxxxxxxxxx] 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@xxxxxxxxx>
>>> wrote:
>>>
>>> From: Scott M Vermillion <scott_ccie_list@xxxxxxxxx>
>>> Subject: RE: NTP - Why NTP not synchronized, yet the router gets 
>>> correct clock?
>>> To: "'Huan Pham'" <pnhuan@xxxxxxxxx>, "'CCIE Lab'" <
>> ccielab@xxxxxxxxxxxxxx
>>> 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@xxxxxxxxxxxxxx [mailto:nobody@xxxxxxxxxxxxxx] 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
>>>
>>> ____________________________________________________________________
>>> ___ Subscription information may be found at:
>>> http://www.groupstudy.com/list/CCIELab.html
>>>
>>>
>>> Blogs and organic groups at http://www.ccie.net
>>>
>>> ____________________________________________________________________
>>> ___ Subscription information may be found at:
>>> http://www.groupstudy.com/list/CCIELab.html
>>>
>>>
>>> Blogs and organic groups at http://www.ccie.net
>>>
>>> ____________________________________________________________________
>>> ___ Subscription information may be found at:
>>> http://www.groupstudy.com/list/CCIELab.html
>>
>> Blogs and organic groups at http://www.ccie.net
>>
>> _____________________________________________________________________
>> __ Subscription information may be found at:
>> http://www.groupstudy.com/list/CCIELab.html
> 
> 
> Blogs and organic groups at http://www.ccie.net
> 
> ______________________________________________________________________
> _ Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html


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

_______________________________________________________________________
Subscription information may be found at: 
http://www.groupstudy.com/list/CCIELab.html