[nsp] ios ntp

Tomas Daniska tomas at tronet.com
Tue Aug 5 15:19:23 EDT 2003


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



More information about the cisco-nsp mailing list