#28 Cisco - why it doesn't work?

[Matthias Schwarz]

Here's what recently transpired after I posted a question
in Cisco's networking professionals forum. In a nutshell,
I am very happy with NetTime within my Windows
environment but cisco devices won't synch because of
the following reason:

NTP gets time but won't update - status/debug shows
ref clock 0.0.0.0

Oct 15, 2002, 10:08am PST
My NTP config on a 4908G-L3 switch router looks like
this:
ntp source Port-channel1
ntp update-calendar
ntp server 10.1.2.35 prefer
ntp server 10.1.2.1

Here is the current situation:

NM-Core#sh ntp asso
address ref clock st when poll reach delay offset disp
~10.1.2.35 0.0.0.0 15 336 1024 377 1.7 160991 0.6
~10.1.2.1 0.0.0.0 15 305 1024 377 1.6 160948 1.8
* master (synced), # master (unsynced), + selected, -
candidate, ~ configured

NM-Core#sh ntp stat
Clock is unsynchronized, stratum 16, no reference
clock
nominal freq is 250.0000 Hz, actual freq is 250.0000 Hz,
precision is 2**24
reference time is 00000000.00000000 (16:00:00.000
PST Wed Dec 31 1899)
clock offset is 0.0000 msec, root delay is 0.00 msec
root dispersion is 0.00 msec, peer dispersion is 0.00
msec

Here's the packet debugging output:
.Oct 15 17:01:45.274: NTP: xmit packet to 10.1.2.35:
.Oct 15 17:01:45.274: leap 3, mode 3, version 3,
stratum 0, ppoll 1024
.Oct 15 17:01:45.274: rtdel 0000 (0.000), rtdsp 10001
(1000.015), refid 00000000 (0.0.0.0)
.Oct 15 17:01:45.274: ref 00000000.00000000
(16:00:00.000 PST Wed Dec 31 1899)
.Oct 15 17:01:45.274: org C156C919.42D0E513
(10:04:25.260 PDT Tue Oct 15 2002)
.Oct 15 17:01:45.274: rec C156C878.46CE4270
(10:01:44.276 PDT Tue Oct 15 2002)
.Oct 15 17:01:45.274: xmt C156C879.466846A4
(10:01:45.275 PDT Tue Oct 15 2002)
.Oct 15 17:01:45.274: NTP: rcv packet from 10.1.2.35:
.Oct 15 17:01:45.274: leap 0, mode 4, version 3,
stratum 15, ppoll 1024
.Oct 15 17:01:45.274: rtdel 0000 (0.000), rtdsp 0000
(0.000), refid 00000000 (0.0.0.0)
.Oct 15 17:01:45.274: ref C156C908.3AE1476A
(10:04:08.229 PDT Tue Oct 15 2002)
.Oct 15 17:01:45.274: org C156C879.466846A4
(10:01:45.275 PDT Tue Oct 15 2002)
.Oct 15 17:01:45.274: rec C156C91A.42D0E513
(10:04:26.260 PDT Tue Oct 15 2002)
.Oct 15 17:01:45.274: xmt C156C91A.42D0E513
(10:04:26.260 PDT Tue Oct 15 2002)
.Oct 15 17:01:45.274: inp C156C879.46D23BFB
(10:01:45.276 PDT Tue Oct 15 2002)

This happens 16 times in a row - you can see that the
switch transmits to the correct IP address, receives the
corrected time (about 3 minutes off) but then doesn't
update it's own clock, probably because "reference
clock 0.0.0.0" I assume. My NTP servers are Windows
2000 machines running NetTime 2.0b6 synchronized to
5 outside stratum 1 sources. any ideas why the switch
refuses to update itself or how to get the "reference
clock 0.0.0.0" changed? Thanks!

****************************************************
and here's the response:

Oct 16, 2002, 6:51pm PST
The problem is not in your router config. The NetTime
software is not providing the correct ntp info to the
routers. If you look at the output of your 'sho ntp assoc'
command, you will see that they are outputting time
with a stratum of 15. That puts your router at stratum
16, which is unsynchronized. If the NT servers are
syncing to stratum 1 servers, they should be at stratum
2, and your routers would be stratum 3.

Also, check the time on both your router and the
servers. That reference time year of 1899 is highly
suspect as well.

Unless the NetTime software can be configured to
output stratum 2 signals, it won't work. The port 37 unix
time standard is not supported as an ntp source. The
native Windows w32time will not act as a server, so
don't use it either.

I've had excellent experience with the real xntpd
daemon port for NT servers. You can get the latest NT
versions at: http://www.five-ten-sg.com/ Look for
the 'NTP 4.1.71' link bottom left.

*****************************************************
Please copy any responses to this post to
mschwarz@ci.milpitas.ca.gov thanks! -Matthias.

[Graham Mainwaring]

Logged In: YES
user_id=66240

This behavior is by design. NetTime does not implement NTP,
only SNTP. Per the standard, SNTP clients are not supposed
to act as servers. By claiming Stratum 2, NetTime would be
misrepresenting the quality of the clock source it is capable
of providing. Using stratum 15 allows SNTP clients to sync to
a NetTime server, but does not allow a NetTime server to
participate in a mesh of NTP servers. I am with the Cisco
guy - the real xntpd port is definitely the way to go, it is a far
better quality server than NetTime is or will ever be.

If you really, really want to do this with NetTime, I suggest
that you download the source, Delphi Open Edition (which is
a free download), and recompile it with the hard-coded
stratum set to a different value - perhaps 12 would be a good
choice.

-Graham

[Matthias Schwarz]

Logged In: YES
user_id=631319

Hi Graham -

Thanks for the follow-up; I am still learning the basics of (S)
NTP here. It makes much more sense now. Thanks for a
great product in the Windows world - very easy to use and
99% perfect for everyday use... and for that 1% Cisco I will
have to get into xntpd.

Cheers,
Matthias.

[Mark Griffiths]

Graham has a good explanation of why NetTime works this way in the comment below.

I'll refer similar tracker items to this one.