From: Hobbs (deadheadblues@gmail.com)
Date: Sun Nov 02 2008 - 23:00:42 ARST
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