From: Scott M Vermillion (scott_ccie_list@it-ag.com)
Date: Mon Nov 03 2008 - 15:14:49 ARST
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
This archive was generated by hypermail 2.1.4 : Mon Dec 01 2008 - 08:18:28 ARST