From: Fabrice Bobes (study@6colabs.com)
Date: Fri Apr 25 2003 - 18:28:39 GMT-3
Ray,
Using authentication or not doesn't have an incidence on
synchronization.
The authentication is here to protect the NTP client against a rogue NTP
server and it's up to the client to use or not the authentication.
The command "show ntp associations detail" tells you what's going on:
Without authentication:
136.10.4.4 configured, our_master, sane, valid, stratum 1
With authentication:
136.10.4.4 configured, authenticated, our_master, sane, valid, stratum 1
HTH,
Fabrice #8609
http://www.6colabs.com
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Lewis, Ray
Sent: Friday, April 25, 2003 10:04 AM
To: 'Group Study'
Subject: RE: NTP Clarification
I also tried this with a 3rd router, where the server was synched to a
master(but was not a configured master itself).
Same result, always synchronized.
-----Original Message-----
From: Lewis, Ray [mailto:rlewis@bofasecurities.com]
Sent: Friday, April 25, 2003 11:12 AM
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