Interesting. ntp-2.gw.uiuc.edu is an old Cisco box running 12.0(27). I wasn't around for the leap second, so I don't have any information about what happened, and its log is completely silent. FWIW, its clock and NTP process appear fine now. It's synced off our GPS clock, which may be a part of the problem. ntp-2>show ntp sta Clock is synchronized, stratum 2, reference is 128.174.38.133 nominal freq is 250.0000 Hz, actual freq is 249.9982 Hz, precision is 2**19 reference time is C7642455.CAE491EF (16:14:45.792 CST Mon Jan 2 2006) clock offset is 0.0594 msec, root delay is 3.57 msec root dispersion is 6.30 msec, peer dispersion is 0.12 msec ntp-2>show ntp asso address ref clock st when poll reach delay offset disp +~130.126.24.24 128.174.38.133 2 192 1024 336 6.4 -0.15 4.0 +~192.5.41.40 .USNO. 1 477 1024 377 32.5 -2.24 1.5 *~128.174.38.133 .PPS. 1 442 1024 377 3.6 0.06 0.1 +~130.126.24.53 128.174.38.133 2 623 1024 377 8.5 1.20 3.1 * master (synced), # master (unsynced), + selected, - candidate, ~ configured /cvk On Dec 31, 2005, at 6:57p, Kevin Day wrote:
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.