From: Daniel Cisco Group Study (danielcgs@imc.net.au)
Date: Sat Apr 26 2003 - 07:25:52 GMT-3
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.
> !
>
> ###########
This archive was generated by hypermail 2.1.4 : Thu May 01 2003 - 13:36:07 GMT-3