From: ccie2be (ccie2be@nyc.rr.com)
Date: Fri Jun 27 2003 - 16:48:35 GMT-3
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
> >
> >
> >
> _______________________________________________________________________
> > You are subscribed to the GroupStudy.com CCIE R&S Discussion Group.
> >
> > Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Fri Jul 04 2003 - 11:11:12 GMT-3