From: Matthew Poole (matthew.poole@blueyonder.co.uk)
Date: Sun Apr 27 2003 - 07:39:01 GMT-3
Could anybody advise on this mail??
Thanks.
----- Original Message -----
From: "Matthew Poole" <matthew.poole@blueyonder.co.uk>
To: "Daniel Cisco Group Study" <danielcgs@imc.net.au>
Sent: Saturday, April 26, 2003 12:30 PM
Subject: Re: NTP Clarification
> Hi Daniel,
> Sorry I haven't really being following this thread.
>
> But spent quite a lot of time on this a while ago. I think you could
> minimise R2 even further by taking NTP authenticate off - the reason being
> the master isn't doing any authentication, the client is - and with ntp
ass
> det you will still see the authenticated.
>
> You also mentioned you had to wait a few minutes, I don't know why Cisco
> haven't included a command to give NTP a kick - I normally remove the
server
> statement and reinstall it.
>
> However, what do Cisco want to see? Every document on CCO has all 4
> commands on both the master and client, the master is a mirror image of
the
> client (except the server statement), Brian Mcghan posted on this subject
a
> few months ago, he included all the commands - and unless I have him
> completely wrong he knows what he's doing.
>
> If I get asked this question when I sit my lab, I think I will
> be putting all the commands on, even though I have proved as have you that
> they aren't needed!
>
> Any thoughts?
>
> Mat.
> ----- 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 11: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