From: kasturi cisco (kasturi_cisco@hotmail.com)
Date: Mon Apr 28 2003 - 13:38:10 GMT-3
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!
This archive was generated by hypermail 2.1.4 : Thu May 01 2003 - 13:36:08 GMT-3