[nsp] ios ntp

Christopher McCrory chrismcc at pricegrabber.com
Mon Aug 4 19:24:05 EDT 2003


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