Re: New IPv6 Address Block Allocated to the RIPE NCC
Jeroen Massar wrote: Filiz Yilmaz wrote: The RIPE NCC received the IPv6 address range 2A01:::/16 from the IANA in December 2005. !Finally! IANA is passing /16's directly to the RIR's! That is a good thing to see happening. Congrats (Or did somebody request a /17 ? :) Cheered to early, it's just a big block again: inet6num: 2a01:c000::/19 netname:FR-TELECOM-20051230 descr: France Telecom But it could mean that the wine lovers will get a broad availability of IPv6!!! Greets, Jeroen signature.asc Description: OpenPGP digital signature
Leap second reminder
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.99 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
Re: Leap second reminder
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.99 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: [EMAIL PROTECTED] 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
Re: Leap second reminder
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. 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. (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.99 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: [EMAIL PROTECTED] 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
Re: Leap second reminder - Check your NTP
Last NTP spam: I'm by no means an NTP expert, if anyone else is, please pipe up. About 30 minutes before the leap second should have occurred, several of our systems reported xntpd[13742]: time reset 0.958385 s, which was really strange. They moved the wrong direction, and they did it early. Shortly after, those systems lost ntp association and began drifting. About 10 minutes after midnight all have regained sync. I wasn't checking things that early to see why, it's possible some of our NTP sources started disagreeing on what the correct time was, and would also match what other people have reported off-list, going back as far as 18 hours before midnight. Several public NTP sources are now indicating a leap second alarm (setting the leap bits to 11), which will cause most NTP clients to rule them out as a source. ntp-2.gw.uiuc.edu is an example: 130.126.24.44: Server dropped: Leap not in sync server 130.126.24.44, port 123 stratum 2, precision -19, leap 11, trust 000 refid [128.174.38.133], delay 0.03357, dispersion 0.00049 According to ntpdate, its clock seems to have stopped about 5 minutes before midnight, and hasn't yet recovered. Other NTP servers haven't cleared their today is a leap second day bit, which they should have by now. Some NTP implementations rule out servers that don't agree with what their master server thinks the leap second bits should be. My reading of the NTP spec says that at 00:00:00 the leap bits should have been returned to zero. Attempting to sync from one of these servers will produce a Next leap second occurs at 00:00:00.000 UTC Sun Jan 01 2006 message, but that should be harmless as long as they correct themselves a while before midnight. Still others have their clocks off by a significant amount(10+ minutes) and think they're still in sync, but since I started typing this email, they all have corrected themselves. While I can't say anything broke on our network as a result of the leap second, a good percentage of our gear lost NTP sync or had some kind of NTP problem around midnight UTC. You may want to check your NTP status at some point, in case something drifted quite a way off and won't step itself back now because the difference is too great. -- Kevin
Re: Leap second reminder - Check your NTP
Kevin Day wrote: Last NTP spam: I'm by no means an NTP expert, if anyone else is, please pipe up. About 30 minutes before the leap second should have occurred, several of our systems reported xntpd[13742]: time reset 0.958385 s, which was really strange. They moved the wrong direction, and they did it early. Shortly after, those systems lost ntp association and began drifting. About 10 minutes after midnight all have regained sync. I wasn't checking things that early to see why, it's possible some of our NTP sources started disagreeing on what the correct time was, and would also match what other people have reported off-list, going back as far as 18 hours before midnight. Several public NTP sources are now indicating a leap second alarm (setting the leap bits to 11), which will cause most NTP clients to rule them out as a source. ntp-2.gw.uiuc.edu is an example: 130.126.24.44: Server dropped: Leap not in sync server 130.126.24.44, port 123 stratum 2, precision -19, leap 11, trust 000 refid [128.174.38.133], delay 0.03357, dispersion 0.00049 According to ntpdate, its clock seems to have stopped about 5 minutes before midnight, and hasn't yet recovered. Other NTP servers haven't cleared their today is a leap second day bit, which they should have by now. Some NTP implementations rule out servers that don't agree with what their master server thinks the leap second bits should be. My reading of the NTP spec says that at 00:00:00 the leap bits should have been returned to zero. Attempting to sync from one of these servers will produce a Next leap second occurs at 00:00:00.000 UTC Sun Jan 01 2006 message, but that should be harmless as long as they correct themselves a while before midnight. Still others have their clocks off by a significant amount(10+ minutes) and think they're still in sync, but since I started typing this email, they all have corrected themselves. While I can't say anything broke on our network as a result of the leap second, a good percentage of our gear lost NTP sync or had some kind of NTP problem around midnight UTC. You may want to check your NTP status at some point, in case something drifted quite a way off and won't step itself back now because the difference is too great. -- Kevin There is at least one stratum-1 server here on the West coast that my NTP says is now off by 1 second. Several stratum-2 are synced to it and are now off also. So checking servers might be a good idea Roy Engehausen
Re: Leap second reminder - Check your NTP
On Sat, Dec 31, 2005 at 05:06:59PM -0800, Roy wrote: Kevin Day wrote: Last NTP spam: I'm by no means an NTP expert, if anyone else is, please pipe up. About 30 minutes before the leap second should have occurred, several of our systems reported xntpd[13742]: time reset 0.958385 s, which was really strange. They moved the wrong direction, and they did it early. Shortly after, those systems lost ntp association and began drifting. About 10 minutes after midnight all have regained sync. I wasn't checking things that early to see why, it's possible some of our NTP sources started disagreeing on what the correct time was, and would also match what other people have reported off-list, going back as far as 18 hours before midnight. Several public NTP sources are now indicating a leap second alarm (setting the leap bits to 11), which will cause most NTP clients to rule them out as a source. ntp-2.gw.uiuc.edu is an example: 130.126.24.44: Server dropped: Leap not in sync server 130.126.24.44, port 123 stratum 2, precision -19, leap 11, trust 000 refid [128.174.38.133], delay 0.03357, dispersion 0.00049 According to ntpdate, its clock seems to have stopped about 5 minutes before midnight, and hasn't yet recovered. Other NTP servers haven't cleared their today is a leap second day bit, which they should have by now. Some NTP implementations rule out servers that don't agree with what their master server thinks the leap second bits should be. My reading of the NTP spec says that at 00:00:00 the leap bits should have been returned to zero. Attempting to sync from one of these servers will produce a Next leap second occurs at 00:00:00.000 UTC Sun Jan 01 2006 message, but that should be harmless as long as they correct themselves a while before midnight. Still others have their clocks off by a significant amount(10+ minutes) and think they're still in sync, but since I started typing this email, they all have corrected themselves. While I can't say anything broke on our network as a result of the leap second, a good percentage of our gear lost NTP sync or had some kind of NTP problem around midnight UTC. You may want to check your NTP status at some point, in case something drifted quite a way off and won't step itself back now because the difference is too great. -- Kevin There is at least one stratum-1 server here on the West coast that my NTP says is now off by 1 second. Several stratum-2 are synced to it and are now off also. So checking servers might be a good idea Are they a GPS sync (or do you know?) The GPS system doesn't really handle the leap second situation the same as others, there is a little blurb here that talks about it: http://gpsinformation.net/main/gpstime.htm I know that I saw my GPS output the following: @051231235958 @051231235959 @06010100 @06010100 @06010101 @06010102 @06010103 Which is mostly correct, it should have really read 5960 instead. I saw my el-cheapo clocks drift by a second at midnight utc. I suggest changing your clock sources to something more reliable if you're seeing folks that are not diligent stratum-1 sources. I suggest this as a source: http://www.stupi.se/Time/ I'm kinda curious what CDMA network clocks said around this time or if they just drifted, i'm sure someone here put their cmda phone in debug and watched it. - jared -- Jared Mauch | pgp key available via finger from [EMAIL PROTECTED] clue++; | http://puck.nether.net/~jared/ My statements are only mine.
Re: Leap second reminder - Check your NTP
Peter Lothberg's Post-Soviet-Era cesium clock. :-) Yes! Cheers! - ferg -- Jared Mauch [EMAIL PROTECTED] wrote: [snip] I suggest changing your clock sources to something more reliable if you're seeing folks that are not diligent stratum-1 sources. I suggest this as a source: http://www.stupi.se/Time/ [snip] -- Fergie, a.k.a. Paul Ferguson Engineering Architecture for the Internet [EMAIL PROTECTED] or [EMAIL PROTECTED] ferg's tech blog: http://fergdawg.blogspot.com/
Re: Leap second reminder - Check your NTP
Once upon a time, Kevin Day [EMAIL PROTECTED] said: While I can't say anything broke on our network as a result of the leap second, a good percentage of our gear lost NTP sync or had some kind of NTP problem around midnight UTC. You may want to check your NTP status at some point, in case something drifted quite a way off and won't step itself back now because the difference is too great. I watched my Tru64 5.1B and Linux 2.2-2.6 servers (NTP wasn't running on my Solaris 9 server accidentally) and Juniper and Cisco gear, and they all stayed in sync. The Linux systems logged: Dec 31 17:59:59 kosh kernel: Clock: inserting leap second 23:59:60 UTC 17:59:59 lasted 2 seconds in local time (since the normal time zone data doesn't pass through leap seconds). I saw the following from JUNOS: Dec 31 18:00:00 hsvrouter /kernel: microuptime() went backwards (8144133.847075 - 8144132.881330) Tru64 and Cisco didn't log anything. -- Chris Adams [EMAIL PROTECTED] Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
Re: live chat with other nanog'ers
On Fri, 30 Dec 2005, Christian Kuhtz wrote: This must be the holiday lull... Is this thread a glue pot yet? The surest sign that a thread has run its full course and is now descending into true wankerhood.. is when I post to it. Happy New Year, kids. - billn
Re: Leap second reminder - Check your NTP
--On December 31, 2005 6:57:45 PM -0600 Kevin Day [EMAIL PROTECTED] wrote: While I can't say anything broke on our network as a result of the leap second, a good percentage of our gear lost NTP sync or had some kind of NTP problem around midnight UTC. You may want to check your NTP status at some point, in case something drifted quite a way off and won't step itself back now because the difference is too great. We've Nagios monitoring a majority of our NTP devices. Around the appropriate time I got a pretty big flurry of ntp sync warnings, took about half an hour for everything to get in sync. Everything looks normal as of right now (has been for a while). I hadn't thought to turn off the alarms even though I was aware of the leap. That resulted in a lot of notifications going out to our on-call people.
