Re: Leap second reminder

[Saku Ytti <saku+nanog () ytti fi>]

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

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.

This http://www.ntp.org/ntpfaq/NTP-s-config-adv.htm#AEN2950
just tells
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
sanitized.

> 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 
> xxx.xxx.xxx.xxx
> 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!
>
> Deepak
>
> 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,
> > refid=ntpx.xxx.xxx,
> > 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

-- 
  ++ytti