From: OhioHondo (ohiohondo@columbus.rr.com)
Date: Tue Apr 29 2003 - 17:55:30 GMT-3
It seems the authenticate command is used by a device that is subservient to
the master clock, indicating that the subservient device must authenticate
the information that it RECEIVES. The master clock, by definition, does not
use data that it receives. Therefor it doesn't need to authenticate.
-----Original Message-----
From: kasturi cisco [mailto:kasturi_cisco@hotmail.com]
Sent: Tuesday, April 29, 2003 10:56 AM
To: ohiohondo@columbus.rr.com
Cc: danielcgs@imc.net.au; rlewis@bofasecurities.com;
ccielab@groupstudy.com
Subject: RE: NTP Clarification
Let us use the diagram below as example. So are u saying the
authentication should be only between router R2 (with NTP server x.x.x.x
pointing to NTP master) and router R3 ( with NTP server y.y.y.y pointing to
the R2).
I know in non-lab environment there may/will not be a router with NTP
master on it.
R1 <--------------- R2<--------R3
ntp master ntp server ntp server
So only R2-R3 are configured with authentication. Correct me if wrong.
Thanks,
Kasturi.
>From: "OhioHondo"
>To: "kasturi cisco" , , ,
>Subject: RE: NTP Clarification
>Date: Mon, 28 Apr 2003 14:27:55 -0400
>
>There is no need for the master to have the authenticate command. Since
it
>supplies the clock (and it is the original source) it does not
authenticate
>the source of its' clocking info. It is the source.
>
>-----Original Message-----
>From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
>kasturi cisco
>Sent: Monday, April 28, 2003 12:38 PM
>To: danielcgs@imc.net.au; rlewis@bofasecurities.com;
>ccielab@groupstudy.com
>Subject: RE: NTP Clarification
>
>
>Group,
>
>This is how i would have done it to be sure and couple of CCIE's whom i
>know say it has worked all the time for them too. Even "All in One study
>guide" shows it this way.
>
>On Master: ( 3 commands)
>ntp authentication-key 1 md5 cisco
>ntp authenticate
>ntp trusted-key 1
>ntp master
>
>On client end: (4 commands)
>ntp authentication-key 1 md5 cisco
>ntp authenticate
>ntp trusted-key 1
>ntp server x.x.x.x key 1
>
>Let me know, if its otherwise.
>
>Good Luck,[IMAGE]
>Kasturi.
>
> >From: "Daniel Cisco Group Study" >Reply-To: "Daniel Cisco Group Study"
> >To: "Lewis, Ray" , "Group Study" >Subject: RE: NTP Clarification >Date:
>Sat, 26 Apr 2003 20:25:52 +1000 > >Not sure what your configs look like
>but have a look at the following: > >R2: >ntp master > >R4: >ntp
>authentication-key 1 md5 cisco >ntp authenticate >ntp trusted-key 1 >ntp
>server 150.10.20.2 key 1 <---IP address of R2 > > >Result - NO SYNC >
> >R4#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**18 >reference time is 00000000.00000000 (10:00:00.000 AEST 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 >R4# >R4#sh ntp
>assoc det >150.10.20.2 configured, insane, invalid, unsynced, stratum 16
> >ref ID 0.0.0.0, time 00000000.00000000 (10:00:00.000 AEST Mon Jan 1
>1900) >our mode client, peer mode unspec, our poll intvl 64, peer poll
>intvl 64 >root delay 0.00 msec, root disp 0.00, reach 0, sync dist 0.000
> >delay 0.00 msec, offset 0.0000 msec, dispersion 16000.00 >precision
>2**5, version 3 >org time C254DC33.33DAE528 (20:21:39.202 AEST Sat Apr 26
>2003) >rcv time AF3BFF94.690BA280 (13:20:52.410 AEST Mon Mar 1 1993) >xmt
>time AF3BFF94.5910F2C4 (13:20:52.347 AEST Mon Mar 1 1993) >filtdelay =
>0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 >filtoffset = 0.00 0.00 0.00 0.00
>0.00 0.00 0.00 0.00 >filterror = 16000.0 16000.0 16000.0 16000.0 16000.0
>16000.0 16000.0 16000.0 > > >Now, > > >Result: SYNC! (after a few
>minuites) > >R4#sh ntp status >Clock is synchronized, stratum 9,
>reference is 150.10.20.2 >nominal freq is 250.0000 Hz, actual freq is
>250.0000 Hz, precision is 2**18 >reference time is C254DCF3.3D00C577
>(20:24:51.238 AEST Sat Apr 26 2003) >clock offset is 3.9515 msec, root
>delay is 69.34 msec >root dispersion is 15878.98 msec, peer dispersion is
>15875.02 msec >R4# >R4#sh ntp ass det >150.10.20.2 configured, ****
>authenticated *****, our_master, sane, valid, stratum 8 >ref ID
>127.127.7.1, time C254DCBB.40AEADAA (20:23:55.252 AEST Sat Apr 26 2003)
> >our mode client, peer mode server, our poll intvl 64, peer poll intvl
64
> >root delay 0.00 msec, root disp 0.03, reach 1, sync dist 15909.714
> >delay 69.34 msec, offset 3.9515 msec, dispersion 15875.02 >precision
>2**18, version 3 >org time C254DCF3.35238AF7 (20:24:51.207 AEST Sat Apr
>26 2003) >rcv time C254DCF3.3D00C577 (20:24:51.238 AEST Sat Apr 26 2003)
> >xmt time C254DCF3.2B065075 (20:24:51.168 AEST Sat Apr 26 2003)
> >filtdelay = 69.34 0.00 0.00 0.00 0.00 0.00 0.00 0.00 >filtoffset = 3.95
>0.00 0.00 0.00 0.00 0.00 0.00 0.00 >filterror = 0.02 16000.0 16000.0
>16000.0 16000.0 16000.0 16000.0 16000.0 > >The key detail is the work
>"authticated" shown above... > >Hope this helps > >Daniel > > > >
> >-----Original Message----- >From: Lewis, Ray
>[mailto:rlewis@bofasecurities.com] >Sent: Saturday, 26 April 2003 01:12
> >To: 'Group Study' >Subject: RE: NTP Clarification > > >ok, here's the
>situation: > >2 routers, R1 master, R2 client over ethernet > >Master
>Client Connection Synchronized >No authent No authent Peer yes >No
>authent No authent Server yes >No authent Authent Peer yes >Authent No
>authent Peer yes >No authent Authent Server yes >Authent No authent
>Server yes >Authent Authent Peer yes >Authent (key 5) Authent (key 4)
>Peer yes > >They always synchronize, no matter what I do with
>authentication. Each time >I try a different scenario, I remove the "ntp
>peer" or "ntp server" command >so there is no synch, then I put it back,
>and they synch. > >stumped > > >-----Original Message----- >From:
>OhioHondo [mailto:ohiohondo@columbus.rr.com] >Sent: Thursday, February
>27, 2003 5:34 PM >To: Scott M. Livingston; 'ccie2be'; 'Group Study'
> >Subject: RE: NTP Clarification > > >Note that only the receiving NTP
>process (the clock that is going to change) >needs to have the truste-key
>and authentication set. For instance, the >master clock is not going to
>use the data that it receives from the server >so it doesn't really have
>to authenticate or trust the source of the data. > >The Master clock
>appends the hash created with the data, the key and the md5 >secret to
>the end of its NTP data packet. If the server is set to >authenticate and
>if the received key is trusted, the server uses its' >authentication-key
>info and the data to recreate the hash. It matches the >calculated hash
>with the hash from the NTP packet received from the master. >If they are
>the same, the NTP process on the server uses the info in the NTP >packet.
> > >The same goes for NTP Broadcast Servers/Clients. The traffic flow
>should be >one way in this case. The Broadcast Server only needs to
>create the hash >that is appended to the NTP packet so it only needs the
>'ntp >authentication-key' command. The NTP Broadcast Client receives the
>NTP >packet. If ntp authentication is on the client and the received key
>is a >trusted key, then the Broadcast client calculates the hash. Again
>if the >calculated hash equals the received hash the data is used by the
>Clients NTP >process. > >Note -- If the Client is does not have 'ntp
>authenticate', it just uses the >data. It "trusts" all received data. >
> >-----Original Message----- >From: nobody@groupstudy.com
>[mailto:nobody@groupstudy.com]On Behalf Of >Scott M. Livingston >Sent:
>Thursday, February 27, 2003 3:33 PM >To: 'ccie2be'; 'Group Study'
> >Subject: RE: NTP Clarification > > >Very nice! Very nice indeed! Thank
>You! > >Scott > >-----Original Message----- >From: ccie2be
>[mailto:ccie2be@nyc.rr.com] >Sent: Thursday, February 27, 2003 2:16 PM
> >To: Group Study; Scott M. Livingston >Subject: Re: NTP Clarification >
> >Hey Scott, > >Here are a couple of additional things t keep in mind
>re:NTP > >1) Before NTP will work, the router must have it's clock set. >
> >2) On a LAN, u can config the NTP master to broadcast NTP pkts w/
> >interface >command: ntp broadcast and have routers recieve these pkts
w/
>interface >command: ntp broadcast client > >3) NTP pkts can (or should)
>be authenticated with keys > >rtrA-------------------------rtrB >NTP
>master----------------NTP server >1.1.1.1 > > >rtr A config: >ntp master
> >ntp authentication-key <#> md5 >ntp authenticate >ntp trusted-key <#> >
> >rtrB >ntp server 1.1.1.1 key <#> >ntp authenticate-key <#> md5 >ntp
>authenticate >ntp trusted-key <#> > >Notice that except for the 1st line,
>the 3 other commands are the same. >And, try to remember that the ntp
>server x.x.x.x command points to the >address of the server which in this
>case is the master source. ( I >often >forget so I figure if I tell you,
>maybe, with any luck, I'll remember >that >myself.) > >Hope this is
>useful. > >Jim >----- Original Message ----- >From: "Scott M. Livingston"
> >To: >Sent: Thursday, February 27, 2003 11:50 AM >Subject: RE: NTP
>Clarification > > > > Option #2 I meant that if R1 is configured as such
>it will be able to > > receive time not give it to 5.5.5.1. Sorry about
>that. > > > > Scott > > > > -----Original Message----- > > From:
>nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf >Of > >
>Scott.M.Livingston@mail.sprint.com > > Sent: Thursday, February 27, 2003
>9:09 AM > > To: ccielab@groupstudy.com > > Subject: NTP Clarification > >
> > > I need to get in the lab tonight and nail this down I have only
> >touched > > on it. Please correct me if I am wrong. This is what I
>understand. > > > > A router configured as such: > > > > R1 > > ! > >
>ntp peer 5.5.5.1 <-- Means that R1 can give and receive time from > >
>5.5.5.1. > > ! > > ######### > > > > A router configured as such: > > > >
>R1 > > ! > > ntp server 5.5.5.1 <-- Means that R1 can give, but not
>receive time >from > > > > 5.5.5.1 > > ! > > > > ########## > > > > A
>router configured as such: > > > > R1 > > ! > > ntp master <-- Any router
>setup with a peer or server statement > > pointing to this R1 can get
>time from it. > > ! > > > > ########### > >
> >_____________________________________________________________________
> >IMPORTANT NOTICES: > This message is intended only for the addressee.
>Please notify the >sender by e-mail if you are not the intended
>recipient. If you are not the >intended recipient, you may not copy,
>disclose, or distribute this message >or its contents to any other person
>and any such actions may be unlawful. > > Banc of America Securities
>LLC("BAS") does not accept time >sensitive, action-oriented messages or
>transaction orders, including orders >to purchase or sell securities, via
>e-mail. > > BAS reserves the right to monitor and review the content of
>all >messages sent to or from this e-mail address. Messages sent to or
>from this >e-mail address may be stored on the BAS e-mail system. > >
> >**********************************************************************
> >This email and any files transmitted with it are confidential and
> >intended solely for the use of the individual or entity to whom they
> >are addressed. If you have received this email in error please notify
> >the system manager. >This footnote also confirms that this email
message
>has been swept by >MIMEsweeper for the presence of computer viruses.
> >www.mimesweeper.com
> >**********************************************************************
>
>------------------------------------------------------------------------
>
>Tried Feng Shui yet? Learn the yin & yan. Make it work for you!
>
>
----------------------------------------------------------------------------
-- Hot new gizmos. Check 'em out. Right now!
This archive was generated by hypermail 2.1.4 : Thu May 01 2003 - 13:36:09 GMT-3