From: Brian McGahan (brian@cyscoexpert.com)
Date: Fri Jun 27 2003 - 18:07:51 GMT-3
Jim,
Yes, the router will prefer the lowest stratum connection that
it can reach by default. In the following example, R1 & R6 are both
masters with stratums 6 and 9 respectively:
R1#sh run | in ntp
ntp master 6
R1#sh ntp status
Clock is synchronized, stratum 6, reference is 127.127.7.1
R6#sh run | in ntp
ntp clock-period 17179528
ntp master 9
R6#sh ntp status
Clock is synchronized, stratum 9, reference is 127.127.7.1
Now they point ntp server statements at each other:
R1#sh run | in ntp
ntp master 6
ntp server 16.0.0.6
R1#sh ntp status
Clock is synchronized, stratum 6, reference is 127.127.7.1
R6#sh run | in ntp
ntp clock-period 17179528
ntp master 9
ntp server 16.0.0.1
R6#sh ntp status
Clock is synchronized, stratum 7, reference is 16.0.0.1
R6 now reduces it stratum to 7 (R1's stratum of 6 + 1 hop away),
and the reference is 16.0.0.1.
There is a caveat with the NTP specification that a client can
only update its clock a certain amount of time per clock period. Here's
an excerpt from RFC 1305, "Network Time Protocol Version 3"
<quote>
The update procedure is initiated upon receipt of a message and at other
times. It processes the offset data from each peer and selects the best
one using the algorithms of Section 4. This may involve many
observations of a few peers or a few observations of many peers,
depending on the accuracies required.
</quote>
This means that the device is going to pick the most reliable
source (lowest stratum in our case) to synchronize with.
<quote>
The local-clock process operates upon the offset data produced by the
update procedure and adjusts the phase and frequency of the local clock
using the mechanisms described in Section 5. This may result in either a
step-change or a gradual phase adjustment of the local clock to reduce
the offset to zero. The local clock provides a stable source of time
information to other users of the system and for subsequent reference by
NTP itself.
</quote>
The key phrase here is "This may result in either a
step-change or a gradual phase adjustment of the local clock to reduce
the offset to zero." What this means is that depending on how far off
your local clock is, you're either going to completely replace your
clock with what the peer is advertising (step change) or move the clock
closer and closer to the correct time (gradual phase adjustment).
The reason that synchronization is happening immediately after
you reload is because the 2500's don't have a hardware clock. This
means that when they reload, the clock is reset to the default (00:00:00
UTC Mon Mar 1 1993). Since both devices now have clocks that are
relatively close to each other, the gradual phase adjustment and
synchronization process will happen very quickly.
On the other hand, if your local clock is very different than
the clock source, it may take a long time for this gradual adjustment to
happen, hence a long time until synchronization.
To solve this problem, make sure that you configure the correct
time (in UTC) on all devices *BEFORE* starting your NTP config. This
will ensure that the change in offset during synchronization is minimal,
hence a short time to synchronize.
HTH
Brian McGahan, CCIE #8593
Director of Design and Implementation
brian@cyscoexpert.com
CyscoExpert Corporation
Internetwork Consulting & Training
Toll Free: 866.CyscoXP
Fax: 847.674.2625
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
Of
> ccie2be
> Sent: Friday, June 27, 2003 2:49 PM
> To: Group Study; Brian McGahan
> Subject: Re: NTP hedaches
>
> Hi Brian,
>
> Thanks for your responses to posts. They were helpful in reinforcing
the
> concepts in my mind.
>
> One of things that's been driving me nuts is when NTP isn't working
when I
> know the config is correct. I think I found the root cause of the
> problem.
> If there had been a config error, fixing the config error doesn't fix
the
> problem. Why? I don't know but after a reboot the problems seem to
clear
> up.
>
> Maybe you could help me (and the rest of the group study community)
> understand some additional ntp config issues.
>
> Specifically, in your example 3, in R2 config, the key# is entered in
3
> different commands which seems very redundant. Is it required in all
the
> commands? Would authen failed, for example, if the config didn't have
the
> key # in the ntp server x.x.x.x command?
>
> Also, if 2 routers are config as NTP Masters, the 1st say, stratum 8
and
> the
> 2nd stratum 10, and other ntp clients are peering with both masters,
> shouldn't the other routers sync with the master with the lower
stratum
> even
> if they had already sync'ed with the master with the higher stratum?
>
> Lastly, at what point (ie, how long should I wait) should I conclude
> there's
> a problem when 2 2500 routers which are both NTP masters but with
> different
> stratum levels don't sync up properly?
>
> rtr1
> ntp master 6
> ntp server 12.0.0.2
>
> rtr2
> ntp master 9
> ntp server 12.0.0.1
>
> In the above config, shouldn't rtr2 sync up with rtr1 since it has the
> lower
> stratum? How long should it take?
>
> Thanks so much for your help, Jim
>
>
> ----- Original Message -----
> From: "Brian McGahan" <brian@cyscoexpert.com>
> To: "'ccie2be'" <ccie2be@nyc.rr.com>; "'Group Study'"
> <ccielab@groupstudy.com>
> Sent: Friday, June 27, 2003 2:23 PM
> Subject: RE: NTP hedaches
>
>
> > Jim,
> >
> > Here's a previous post of mine that should help:
> >
> > http://www.groupstudy.com/archives/ccielab/200212/msg00120.html
> >
> > A common misconception about NTP is the way authentication is
> > implemented; however, it makes perfect sense if you think about it
> > logically.
> >
> > What is the purpose of using NTP authentication? The most
> > obvious answer is that authentication is used to prevent someone
from
> > tampering with the timestamps on the logs generated by devices. To
> > implement an attack on NTP, a hacker would make their rogue host
appear
> > to be a valid NTP server. NTP authentication is therefore used to
> > authenticate the time *source*, not the client.
> >
> > Take the following scenario:
> >
> > R1--12.0.0.0/8--R2
> >
> > R1 and R2 share the segment 12.0.0.0/8. R1 is the NTP master, and
R2 is
> > the client. To get a better understanding of how NTP authentication
> > works, try the following possible configurations and see which of
them
> > work and which of them do not.
> >
> > *Note: NTP should not take longer than 15 or 20 seconds to initially
> > synchronize. If your routers do not synchronize within this period,
> > remove any 'ntp server' or 'ntp peer' statements and replace them.
If
> > synchronization still does not occur, there is a configuration
problem.
> >
> > Case 1: No authentication
> >
> > R1#sh run | in ntp
> > ntp master 1
> >
> > R2#sh run | in ntp
> > ntp clock-period 17179865
> > ntp server 12.0.0.1
> > R2#sh ntp stat
> > Clock is synchronized, stratum 2, reference is 12.0.0.1
> > <snip>
> > R2#show ntp associations detail
> > 12.0.0.1 configured, our_master, sane, valid, stratum 1
> >
> >
> > Case 2: Authentication on server, no authentication on client
> >
> > R1#sh run | in ntp
> > ntp authentication-key 1 md5 121A0C041104 7
> > ntp authenticate
> > ntp master 1
> >
> > R2#sh run | in ntp
> > ntp clock-period 17179863
> > ntp server 12.0.0.1
> > R2#sh ntp stat
> > Clock is synchronized, stratum 2, reference is 12.0.0.1
> > <snip>
> > R2#sh ntp assoc detail
> > 12.0.0.1 configured, our_master, sane, valid, stratum 1
> >
> > Case 3: No authentication on server, authentication on client
> >
> > R1#sh run | in ntp
> > ntp master 1
> > R1#
> >
> > R2#sh run | in ntp
> > ntp authentication-key 1 md5 08701E1F28492647465A5D547E 7
> > ntp authenticate
> > ntp trusted-key 1
> > ntp clock-period 17179863
> > ntp server 12.0.0.1 key 1
> > R2#sh ntp stat
> > Clock is unsynchronized, stratum 16, no reference clock
> > <snip>
> > R2#sh ntp assoc detail
> > 12.0.0.1 configured, insane, invalid, unsynced, stratum 16
> >
> >
> > Case 4: Authentication on server and client
> >
> > R1#sh run | in ntp
> > ntp authentication-key 1 md5 0822455D0A16 7
> > ntp authenticate
> > ntp master 1
> > R1#
> >
> > R2#sh run | in ntp
> > ntp authentication-key 1 md5 060506324F41 7
> > ntp authenticate
> > ntp trusted-key 1
> > ntp clock-period 17179865
> > ntp server 12.0.0.1 key 1
> > R2#sh ntp stat
> > Clock is synchronized, stratum 2, reference is 12.0.0.1
> > <snip>
> > R2#sh ntp assoc detail
> > 12.0.0.1 configured, authenticated, our_master, sane, valid, stratum
1
> >
> >
> > As shown by the above configuration, NTP authentication is used
> > to authenticate the NTP source, not any associated clients.
> >
> > HTH
> >
> > Brian McGahan, CCIE #8593
> > Director of Design and Implementation
> > brian@cyscoexpert.com
> >
> > CyscoExpert Corporation
> > Internetwork Consulting & Training
> > Toll Free: 866.CyscoXP
> > Fax: 847.674.2625
> >
> >
> > > -----Original Message-----
> > > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On
Behalf
> > Of
> > > ccie2be
> > > Sent: Friday, June 27, 2003 11:52 AM
> > > To: Group Study
> > > Subject: NTP hedaches
> > >
> > > Hi all,
> > >
> > > I've been having problems getting NTP to work as expected.
> > >
> > > I have 3 2500's, rtr A, rtrB, and rtrC connected to each other via
a
> > > common
> > > ethernet segment.
> > >
> > > rtrA-----------------rtrB
> > > |
> > > |
> > > rtrC
> > >
> > >
> > > rtrA config:
> > > ntp master 6
> > >
> > > rtrB config:
> > > ntp master 10
> > > ntp server 10.0.1.1 (rtrA's lo0 addr)
> > >
> > > rtrC config:
> > > ntp peer 10.0.1.1
> > > ntp peer 10.0.2.2 (rtrB's lo0 addr)
> > >
> > > Problems and issues:
> > > Before rtrC was configured, rtrB sync'ed with rtrA as expected,
but
> > now
> > > rtrA
> > > won't sync with itself and rtrC is syncing with rtrB. Shouldn't
rtrC
> > sync
> > > with rtrA since it has a lower stratum?
> > >
> > > Why doesn't rtrA sync with itself? Show ntp asso det shows
"insane,
> > > invalid,
> > > etc.
> > >
> > > rtrA and rtrB had sync'ed up properly before I configured
> > authentication
> > > but
> > > then it stopped working correctly so I removed the authentication
and
> > now
> > > it
> > > won't work. Any ideas as to what's going on?
> > >
> > > When doing authentication, is the following necessary?
> > >
> > > ntp client:
> > > ntp server a.b.c.d key # ( Is this needed when the
command,
> > ntp
> > > trusted key #, is used?)
> > > ntp trusted key # ( Is this needed if the key#
> > option is
> > > used in the above command?)
> > > ntp authentication-key # md5 <password>
> > > ntp authenticate
> > >
> > >
> > > According to Doyle, volume II, the command, ntp trusted key #
isn't
> > needed
> > > on
> > > the ntp master, but when I removed it from the master, ntp
stopped
> > > working?
> > > Doyle isn't wrong on this point is he?
> > >
> > > Thanks for any insight you can provide, Jim
> > >
> > >
> > >
> >
This archive was generated by hypermail 2.1.4 : Fri Jul 04 2003 - 11:11:12 GMT-3