North American Network Operators Group|
Date Prev | Date Next |
Date Index |
Thread Index |
Author Index |
Re: Leap second reminder
- From: Saku Ytti
- Date: Sun Jan 01 04:07:19 2006
On (2005-12-31 17:18 -0500), Deepak Jain wrote:
Linux seemed to survive happily too
[ytti@foo ~]% dmesg|tail -n1
Clock: inserting leap second 23:59:60 UTC
Curious though that not so many people who've I asked got these messages,
only explanation I can think of is that their NTP peers weren't telling
Without much NTP clues, could someone explain what steps NTP takes to
protect itself from attackers spoofing packets and forcing you to leap?
Probably sane implementation would restrict leaping to happen only
at 23:59:59, so you'd drift maximum of 1s/d? But crappy implementation
might allow you to leap every second.
Most users of NTP do not need authentication as the protocol contains
several filters against bad time.
So I guess it's pretty implementation spesific how the input is
> Cisco seems happy as well. (adding leap second, leap second occurs at), etc.
> >sh ntp status
> Clock is synchronized (adding leap second), stratum 2, reference is
> nominal freq is 250.0000 Hz, actual freq is 249.9975 Hz, precision is 2**18
> reference time is C7617E39.3A0B3D8C (17:01:29.226 EST Sat Dec 31 2005)
> clock offset is 0.5332 msec, root delay is 5.11 msec
> root dispersion is 7.72 msec, peer dispersion is 7.14 msec
> Leap second occurs at C7619A00.00000000 (19:00:00.000 EST Sat Dec 31 2005)
> Happy New Year!
> Gerry Boudreaux wrote:
> >On Dec 31, 2005, at 11:58 AM, Kevin Day wrote:
> >>Just a reminder, at midnight UTC there's a leap second added to most
> >>time systems.
> >>Some time systems will stop the clock at 23:59:59.999999 for 1
> >>second, some will display 23:59:60 for a second.
> >>Since the last leap second (1998), "leap second aware" time keeping
> >>systems(NTP, GPS, etc) have become much more prevalent, so it's much
> >>more likely this time that applications and NTP sync'ed devices will
> >>see a leap second happen(rather than have them manually corrected
> >>later, or not corrected at all). But, I'm not too sure how well
> >>everyone has tested applications and devices for how they handle the
> >>clock stopping for a second OR an "invalid" time of 23:59:60.
> >>If anyone sees anything die at 00:00:00UTC I'd be interested to know.
> >>-- Kevin
> >My Juniper seems to be aware:
> >xxx@juniper> show ntp status
> >status=4694 leap_add_sec, sync_ntp, 9 events, event_peer/strat_chg,
> >version="ntpd 4.1.0-a Thu Jul 14 23:46:40 GMT 2005 (1)",
> >processor="i386", system="JUNOS7.3R1.5", leap=01, stratum=3,
> >precision=-30, rootdelay=40.669, rootdispersion=49.522, peer=35302,
> >reftime=c7615c1c.65f78359 Sat, Dec 31 2005 13:35:56.398, poll=10,
> >clock=c7615d8e.d66d698f Sat, Dec 31 2005 13:42:06.837, state=4,
> >offset=-2.649, frequency=73.810, jitter=5.194, stability=0.024
> >note the leap=01 and leap_add_sec