From: kasturi cisco (kasturi_cisco@hotmail.com)
Date: Mon Apr 28 2003 - 14:10:19 GMT-3
Guys in addition to the reply i sent earlier..here is a good link which
will be useful.
http://www.oreilly.com/catalog/hardcisco/chapter/ch10.html
Good Luck,[IMAGE]
Kasturi.
>From: "folivore" >Reply-To: "folivore" >To: "Daniel Cisco Group Study" ,
"Lewis, Ray" , "Group Study" >Subject: Re: NTP Clarification >Date: Sun,
27 Apr 2003 18:43:27 -0500 > >I think you only need two lines on the
server >ntp master >ntp authentication-key 1 md5 cisco >As long as the
key number is the same, clients can sync to it. > >----- Original Message
----- >From: "Daniel Cisco Group Study" >To: "Lewis, Ray" ; "Group Study"
> >Sent: Saturday, April 26, 2003 5:25 AM >Subject: RE: NTP Clarification
> > > > 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, > > > > Change R2: > >
ntp authentication-key 1 md5 cisco > > ntp authenticate > > ntp master >
> > > 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. > > > ! > > > > > > ########### > > > > > >
This archive was generated by hypermail 2.1.4 : Thu May 01 2003 - 13:36:08 GMT-3