[nsp] ios ntp

Marcus Keane mkeane at microsoft.com
Wed Aug 6 01:00:41 EDT 2003 

Actually forget the second one. It won't work as stated as you'll have a
loop. To make it work you'll need to make the ntpd box a client of the
upstream as well as a peer of the 3660, even if it has to go through the
3660 to get there. 
Marcus.

-----Original Message-----
From: Marcus Keane 
Sent: Tuesday, 5 August 2003 23:47
To: Tomas Daniska
Cc: cisco-nsp at puck.nether.net; Christopher McCrory
Subject: RE: [nsp] ios ntp

Tomas, what you could do is this: if you have two routers, have both act
as peers to each other and then both be clients of the upstream. Then if
either reboots, it will sync back up to the other regardless of whether
the upstream is available. If you don't have another router, you could
just configure one other ntpd boxes to be a peer of the 3660. This will
essentially serve the same purpose as normally the 3660 will be
preferred due to proximity to the upstream.
Hope this helps...
Marcus.

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Tomas Daniska
Sent: Tuesday, 5 August 2003 22:21
To: Tomas Daniska; Christopher McCrory; cisco-nsp at puck.nether.net
Subject: RE: [nsp] ios ntp



and well, yes, the point is that if i had two servers it should have
been a *very* rare occasion that both would provide bad time... i'm
going to look around for another one to back up

--

deejay 

> -----Original Message-----
> From: Tomas Daniska
> Sent: 5. augusta 2003 14:19
> To: 'Christopher McCrory'; 'cisco-nsp at puck.nether.net'
> Subject: RE: [nsp] ios ntp
> 
> 
> chris, marcus,
> 
> 
> i believe the scenario chris describes is ok in about all cases, but i

> had a bit other problem:
> 
> there is a 3660 sitting in the lan, sychronized to some public ntp and

> it gives clock to hosts and other boxes in the lan. once after a 
> reboot, the router did not get back in-sync and as it does not have a 
> calendar it started providing year
> 1993 as ntp time, and some hosts moved backwards to this date, which 
> induced many other problems...
> 
> i know this is rather a problem of the clients (they did not have a 
> sort of "ntp-guard" feature) and those should be fixed, i'd like to 
> prevent the cause (router serving invalid
> time) instead of the consequence (hosts going back) - i wouldn't like 
> to rely on host-based sanity checking since i had this experience
> 
> 
> thanks anyway
> 
> --
> 
> deejay
> 
> > -----Original Message-----
> > From: Christopher McCrory [mailto:chrismcc at pricegrabber.com]
> > Sent: 5. augusta 2003 3:24
> > To: cisco-nsp at puck.nether.net
> > Cc: Tomas Daniska
> > Subject: Re: [nsp] ios ntp
> > 
> > 
> > Hello...
> > 
> > 
> > On Mon, 2003-08-04 at 08:35, Tomas Daniska wrote:
> > > hi there,
> > > 
> > > 
> > > is anyone aware if it's possible to set ios built-in ntp
> > server to serve
> > > only if it is synchronized to a higher-stratum peer?
> > > 
> > 
> > the ntp protocol has some built-in methods of handling this.
> > 
> > easy answer:  use more than one ntp server
> > 
> > testing:
> > 
> > I tested this in my lab with a 2620 and access-lists:
> > 
> > start:
> > ntp access-group peer 98
> > ntp server 192.168.10.14 version 1 prefer
> > 
> > access-list 98 permit 192.168.10.14
> > access-list 98 permit 192.168.10.15
> >  
> > 
> > linux client (192.168.10.15):
> > ntpq> peers
> >      remote           refid      st t when poll reach   delay 
> >   offset
> > jitter
> > ==============================================================
> > ================
> > *c2620           ntp.server  4 u   29   64  374    1.641    0.138  
> > 0.174
> > 
> > 
> > change the access list to
> > access-list 98 permit 192.168.10.15
> > access-list 98 deny any
> > 
> > eventually you get this:
> > c2620.pg#sh ntp ass
> >  
> >       address         ref clock     st  when  poll reach  delay 
> > offset    disp
> >  ~192.168.10.14     ntp.server    3  1591    64    0     
> 1.9   -0.02 
> > 16000.
> >  * master (synced), # master (unsynced), + selected, - candidate, ~ 
> > configured
> > 
> > on the linux client:
> > 
> > 
> > ntpq> peers
> >      remote           refid      st t when poll reach   delay 
> >   offset
> > jitter
> > ==============================================================
> > ================
> >  c2620                ntp.server 16 u   58   64    0    
> 0.000    0.000
> > 4000.00
> > 
> > 
> > 
> > Notice that the stratum is now 16 , unreachable, now that it's 
> > master's master is unreachable.
> > 
> > 
> > With a better client config:
> > 
> > ntpq> peers
> >      remote           refid      st t when poll reach   delay 
> >   offset
> > jitter
> > ==============================================================
> > ================
> >  c2620          ntp.server     16 u   65   64    0    0.000   
> >  0.000   
> > 0.00
> >  ntp.server  tock.ucla.edu    2 u   10   64    1    4.305    3.846  
> > 0.008
> > 
> > 
> > the ntp protocol has a built in "drift" functionality ( as noted in 
> > Marcus Keane's).  This means the client notices how much the local 
> > clock differs from it's master over time.  When it can't connect to 
> > it's master is uses this info to "guesstimate" the correct time.
> > 
> > Hopefully someone will correct me if I got anything wrong,
> but that's
> > how I understand it.
> > 
> > bottom line:
> > just use two ntp servers.
> > two servers at your site that both talk to two others all other 
> > local clients use your two servers.
> > 
> > 
> > > 
> > > thanks
> > > 
> > > --
> > >  
> > > Tomas Daniska
> > > systems engineer
> > > Tronet Computer Networks
> > > Plynarenska 5, 829 75 Bratislava, Slovakia
> > > tel: +421 2 58224111, fax: +421 2 58224199
> > >  
> > > A transistor protected by a fast-acting fuse will protect
> > the fuse by
> > > blowing first.
> > > 
> > > 
> > > _______________________________________________
> > > cisco-nsp mailing list  cisco-nsp at puck.nether.net 
> > > http://puck.nether.net/mailman/listinfo/cisco-nsp
> > > archive at http://puck.nether.net/pipermail/cisco-nsp/
> > --
> > Christopher McCrory
> >  "The guy that keeps the servers running"
> >  
> > chrismcc at pricegrabber.com
> >  http://www.pricegrabber.com
> >  
> > Let's face it, there's no Hollow Earth, no robots, and no 'mute 
> > rays.' And even if there were, waxed paper is no defense.  I tried 
> > it.  Only tinfoil works.
> > 
> > 
> > 
> 

_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
http://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

More information about the cisco-nsp mailing list