From: Neil Moore (neil@droopy.com)
Date: Mon Nov 03 2008 - 19:29:26 ARST
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