[nsp] ios ntp

Tue Aug 5 15:21:16 EDT 2003

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.
> > 
> > 
> > 
> 