[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