[nsp] ios ntp

Tue Aug 5 11:38:14 EDT 2003

Hello...

On Tue, 2003-08-05 at 05:19, Tomas Daniska wrote:
> 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...
> 

Ouch!  I see the problem.  I would recommend NOT using the router as the
main ntp server.  Re-delegate the ntp server task to a local PC that
will keep it's time after a reboot.  Maybe a local mail/web/file server
or a close upstream server.  main office if remote office.  or ISP's ntp
server, etc. 

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