[158110] in North American Network Operators' Group

home help back first fref pref prev next nref lref last post

Re: NTP Issues Today

daemon@ATHENA.MIT.EDU (Blake Dunlap)
Tue Nov 20 20:05:52 2012

In-Reply-To: <CAFANWtWzKaApPHP6=TyA50ScO_fgCJ=V59ty=keBeb0fugQoiA@mail.gmail.com>
From: Blake Dunlap <ikiris@gmail.com>
Date: Tue, 20 Nov 2012 19:03:02 -0600
To: Darius Jahandarie <djahandarie@gmail.com>
Cc: "nanog@nanog.org" <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org

That's what happens when you just follow vendor recommendations blindly. If
you do follow that on vm's (which can actually be a good practice), make
sure they pull from your own time infrastructure, and not just the world at
large, and that those servers behave in a sane fashion with regard to time
jumps.


On Tue, Nov 20, 2012 at 6:56 PM, Darius Jahandarie <djahandarie@gmail.com>wrote:

> On Tue, Nov 20, 2012 at 7:49 PM, Jimmy Hess <mysidia@gmail.com> wrote:
> > Are you sure that you are actually using NTP to set your clock?
> > For you to sync with 2000,  you should have had multiple confused
> > peers from multiple time sources;  possibly a false radio signal....
> >
> > NTP by default has a panic threshold of 1000 seconds.
> >
> > This  _should_   have caused NTP to execute a panic shutdown,
> > instead of setting the clock back  30 million seconds.
>
> For VMWare at least, their official recommendation[1] for NTP is to
>
> tinker panic 0
>
> for suspend/resume reasons. I've seen it default in some places.
>
> [1]
> http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1006427
>
> --
> Darius Jahandarie
>
>

home help back first fref pref prev next nref lref last post