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