From: Huan Pham (Huan.Pham@peopletelecom.com.au)
Date: Mon Nov 03 2008 - 19:50:02 ARST
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@groupstudy.com [mailto:nobody@groupstudy.com] 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@it-ag.com> 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@groupstudy.com [mailto:nobody@groupstudy.com] 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@it-ag.com> 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@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
>>>
>>> ____________________________________________________________________
>>> ___ 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
This archive was generated by hypermail 2.1.4 : Mon Dec 01 2008 - 08:18:28 ARST