From: folivore (folivore@hotmail.com)
Date: Sun Apr 27 2003 - 20:43:27 GMT-3
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" <danielcgs@imc.net.au>
To: "Lewis, Ray" <rlewis@bofasecurities.com>; "Group Study"
<ccielab@groupstudy.com>
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 <secret-password>
> ntp authenticate
> ntp trusted-key <#>
>
> rtrB
> ntp server 1.1.1.1 key <#>
> ntp authenticate-key <#> md5 <secret-password>
> 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" <scottl@sprinthosting.net>
> To: <ccielab@groupstudy.com>
> 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
> **********************************************************************
This archive was generated by hypermail 2.1.4 : Thu May 01 2003 - 13:36:08 GMT-3