From: kasturi cisco (kasturi_cisco@hotmail.com)
Date: Tue Apr 29 2003 - 11:55:40 GMT-3
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