NTP won't synch to remote time source.

[Trevor Phillips]

OpenVMS 7.3-1, TCPIP V5.3 ECO 2, NTPD 4.1.0.
Trying to get this node to synch with a W2003 Server over NTP.
tcpip$ntp.conf file configured with:

server ntp-clock version 3

(ntp-clock is defined in hosts database and can be pinged etc - have tried raw ip address in conf file)

I can force a reset of the local VMS clock using ntpdate to the w2k3 server, but NTP will not set the time (it has drifted out by 10 secs since the last ntpdate).

ntpdc - peer command shows the remote server name, and the correct details in terms of time differences etc.

ntpq - associations command shows remote clock as reachable, but advises that the condition is "reject"

ntptrace - returns:
LOCALHOST: Stratum 16
0.0.0.0: *not synchronised*

Forced full logging for NTP, logs say time is being rejected but not why! Analysed network traffic and NTP requests are being received and returned by server.

DTSS is not running and NTP is enabled in TCPIP services. Have tried disabling auth in conf file as well.

I am sure its something small I have missed in the config, but I can't seem to spot it.
Any ideas as to why NTP will not synch?

[Bojan Nemec]

Trevor,

On my system (VMS 7.3-2 TCPIP V5.4 - ECO 2, NTP 4.1.047) works fine. The only two (not commented) lines in TCPIP$NTP.CONF are:

server x.x.x.x
driftfile SYS$SPECIFIC:[TCPIP$NTP]TCPIP$NTP.DRIFT

In my case the ntp server is a linux machine. Maybe you have to set something on the w2k3 server. Try to bypass the w2k3 server and go directly to the external ntp server. Also note that the first Synchronizing time can be very long.

Bojan

[Ian Miller.]

I have a vague memory that the ntp server on Windows does not do proper ntp but some slightly incompatabile subsub - I think its suppposed to be SNTP.

[Garry Fruth]

ntpq -peers may provide information (http://h71000.www7.hp.com/doc/73final/6526/6526pro_024.html#ntpq_sec); a "#", "x", "." indicate reasons for rejection.

Any clues in the TCPIP$NTP_RUN.LOG (sp?) file?

[Garry Fruth]

Sorry, mistake on the previous reply. The reference for the ntpq -peers command is http://h71000.www7.hp.com/doc/73final/6526/6526pro_024.html#heading_12.8.4.1

[Trevor Phillips]

Thanks for the responses so far.

An ntpq peers displays a blank (space) before the remote host name. Docs advise that this "indicates that the peer was discarded, because of high stratum or failed sanity checks"

I need to now investigate why this is. The w2k3 server has a radio (rugby) clock directly connected to it. The w2k3 server NTP software has set itself to stratum 1, which I would accept as being correct?

Rgds,
Trevor.

[Garry Fruth]

The -peers should also have indicated stratrum of the server under the column labeled "st". Is it 1, as you expected?

[Trevor Phillips]

Yes, the stratum is 1 as expected.

ntpq -peers displays

remote refid st
ntp-clock .LOCL. 1

I am trying to investigate what sanity checks would cause it to reject the time.

[Garry Fruth]

Does the offset from the peers command show over 900,000? I believe that represents 15 minutes which is beyond where NTP adjusts.

You could also try
ntpq> assoc
ntpq> readvar ### flash where ### is the associd of the ntp server.

[Trevor Phillips]

The Alpha is currently 10 seconds faster than the reference clock (which is well within the limit whereby NTP would shutdown).

readvar flash returns:

status=9014 reach, conf, 1 event, event_reach, flash=00 ok

[Shael Richmond]

I'm pretty sure it's a Windows problem. I had the same issue trying to synch from the company time server(windows). I called support and said nothing was wrong with UCX, it was a windows problem. I changed my ntp to point to the same server the windows server was pointed to and everything has been fine.

[Trevor Phillips]

Regarding it being a windows problem - I should have added earlier that we can get other platforms (a Novell and UNIX system) to obtain the time and successfully set their clocks from the w2k3 server via NTP.

We are a couple of TCPIP ECOs behind on the Alpha system, which I will try and get installed to rule them out.

[Robert_Boyd]

Have you verified that you have the TDF set up properly on the VMS system? If the TDF has not been configured using SYS$MANAGER:UTC$CONFIGURE_TDF or the equivalent procedure on your version of VMS, NTP won't synchronize.

On one system I had this problem. As soon as I properly configured the TDF, NTP started synchronizing within a few minutes.

[Trevor Phillips]

Thanks for the tips so far.

UTC$TIME_SETUP SHOW produced the following:
.
AUTO_DLIGHT_SAV is set to "0"

The Logical name SYS$TIMEZONE_RULE is not defined
The Logical name SYS$TIMEZONE_NAME is not defined
The Logical name SYS$TIMEZONE_DAYLIGHTSAVING is not defined

LOCAL TIME ZONE = GB_EIRE - STANDARD TIME
LOCAL TIME = 22-FEB-05
DIFFERENTIAL FACTOR 0.00
TIMEZONE RULE
.
.
I ran UTC$TIME_SETUP to reset the time zone settings and create the logicals (btw UTC$TIME_SETUP has several entries for GB-EIRE in the main menu - is this a feature?).

Anyway, I played about with setting the timezone and TDF. So far NTP will still not synch. I ran an ntpdate to bring the clock back into line (as it is an operational system and was now 15 secs fast) which worked as expected.

[Robert_Boyd]

From the VMS FAQ:

4.3 Managing Timezones, Timekeeping, UTC, and Daylight Savings?

You will want to use the command procedure:

* SYS$MANAGER:UTC$TIME_SETUP.COM

to configure the OpenVMS Timezone Differential Factor (TDF) on OpenVMS V6.0 and later. Select the BOTH option. This configures the OpenVMS TDF settings, though it may or may not configure the TDF and the timezone rules needed or used by other software packages. Please do NOT directly invoke the following command procedures:

* SYS$MANAGER:UTC$CONFIGURE_TDF.COM ! do not directly use
* SYS$MANAGER:UTC$TIMEZONE_SETUP.COM ! do not directly use

TCP/IP Services V5.0 and later use the OpenVMS TDF, UTC, and timezone support. Earlier versions use a TDF mechanism and timezone database that is internal to the TCP/IP Services package. Also on the earlier versions, the TDF must be manually configured within TCP/IP Services, in addition to the OpenVMS configuration of the TDF.

DECnet-Plus in V7.3 and later uses the OpenVMS TDF, UTC, and timezone support, and displays its timezone prompts using UTC$TIME_SETUP.COM. Earlier versions use a TDF TDF mechanism, timezone database, and automatic switch-over that is internal to the DECnet-Plus package. Also on earlier versions, the TDF must be configured within the DECnet-Plus DECdtss package, in addition to the OpenVMS configuration of the TDF.

Application code using HP C (formerly Compaq C, formerly DEC C) will use the OpenVMS UTC and TDF mechanisms when the C code is compiled on OpenVMS V7.0 and later (and when the macro _VMS_V6_SOURCE is NOT defined). HP C does NOT use the OpenVMS UTC and TDF mechanisms when the C code is compiled on OpenVMS releases prior to V7.0, or when the preprocessor declaration _VMS_V6_SOURCE is declared.

DCE DTS TDF details TDB.

[Trevor Phillips]

Yes, I had read through this after your first post Robert. Unless I am really missing the obvious here everything is set as it should be.

The time is being rejected due to sanity checks - but I am struggling to find out why. I have configured NTP to produce full logs (as to the default basic logs) after making the timezone changes, and will review the results today (and post any interesting points from them).

Any other advice always welcome!
Thanks, Trevor.

[Garry Fruth]

Check out section 2.2 of the following:
http://www.eecis.udel.edu/%7emills/database/status/arpa/arpa95c.pdf

Search for the word Sanity in the following:
http://www.lo0.com/ntp/ntpq.htm
This one explains the flash variable.

Could you attach the full output of the pstatus command?

Also, it would be interesting to see
mc tcpip$ntpq
host w2k3
peers

[Trevor Phillips]

Output to pstatus attached (ip addresses commented out).


I am reviewing the documents referenced - thanks!.

[Garry Fruth]

I don't know why it is not reflected in the flash variable. But it looks like root dispersion is well above 1 second, causing test 8 to fail.

[Trevor Phillips]

Apologies for the delay in replying (was off). Still chasing why dispersion is out so much. Have attached logs from ntp (ntp logging set to maximum). Am reviewing at the moment.

[Trevor Phillips]

On another installation we noticed that the latest patches were installed for NTP, which seems to correct the issue. Many thanks for all that contributed with advise.