NTP - time server 'rejected'

[Becks]

Help! My NTP setup won't synchronise. I'm running Tru64 5.1b and I'm trying to synchronise to a Cisco router.

I've stripped down the NTP setup so that my server is only synchronising with 1 time server (I know this is bad practice but it simplifies the problem). My source time server is usually synchronised (indicated by a * when running ntpq -p remotely; though I've occassionaly seen a # meaning exceeds maximum distance).

My ntp.conf contains details of the 1 server and the path of the drift file (which contains 0)

Please find the ntpq -p output below. The telltale indicator for my server is always ' '! Implying it fails the sanity checks. However the other values indicate ntp polling is taking place.

# ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
4 u 38 64 377 7.098 187.693 101.990

Running the ntpq 'as' command shows that the server is being 'rejected':
ntpq> as
ind assID status conf reach auth condition last_event cnt
===========================================================
1 42572 9014 yes yes none reject reachable 1

However if you look at the full details it IS passing all of the sanity checks (indicated by flash = 00). The filtoffset value is changing by 104ms each poll(it will loop through negative values too).

ntpq> rv 42572
status=9014 reach, conf, 1 event, event_reach,
srcadr=, srcport=123, dstadr=, dstport=123,
leap=00, stratum=4, precision=-18, rootdelay=62.927,
rootdispersion=1779.449, refid=, reach=377, unreach=0,
hmode=3, pmode=4, hpoll=6, ppoll=6, flash=00 ok, keyid=0, offset=82.449,
delay=7.046, dispersion=1.422, jitter=105.244,
reftime=c7b6444f.8166dc36 Mon, Mar 6 2006 15:17:03.505,
org=c7b64457.31b5201f Mon, Mar 6 2006 15:17:11.194,
rec=c7b64457.1d80a17b Mon, Mar 6 2006 15:17:11.115,
xmt=c7b64457.1a172abe Mon, Mar 6 2006 15:17:11.101,
filtdelay= 7.05 7.10 7.10 7.03 7.88 7.01 7.85 7.10,
filtoffset= 82.45 187.69 289.68 395.03 499.45 602.47 705.11 806.38,
filtdisp= 0.49 1.47 2.41 3.39 4.35 5.31 6.25 7.20

* Why will it not accept this time server as a valid synchronisation source? (Or how can I make it accept this time server as a valid synchronisation source)

* What is filtoffset? What do these step changes represent (are they bad)?

Due to corporate restrictions I am unable to try synching to any of the available internet NTP servers. My hunch is that my NTP source is 'not good enough' but I'd like to know why.

Any help, hints or document references would be greatly appreciated.
Thanks,
Becks

[Steven E. Protter]

Shalom Becks,

I suggest you manually adjust your clock to a time closer to actual time for you time zone.

ntp will refuse to synch if the time is too far off, due to its methodology, which is to slow or speed the clock and adjust gradually.

Also, some Microsoft time servers don't comply with Unix standards and can't synch Unix machines.

SEP

[Becks]

I have been running ntpdate before starting the daemon. Other forums suggested that maybe I needed some patience but I let it run over the last weekend and it hadn't synchronised by Monday.

I'm trying to synchronise to a Cisco router, not a Windows server - am I likely to encounter similar problems? :-(

NB The Cisco router is using an Alpha server as its time server. Though I guess this doesn't prove that a Cisco router can 'serve' time to an Alpha. Unfortunately, I can't access this Alpha Server directly.

[James A. Donovan]

A quick google search (NTP filtoffset)turned up this:

http://www.eecis.udel.edu/~mills/ntp/html/debug.html

.
.
.

The three lines identified as filtdelay, filtoffset and filtdisp reveal the roundtrip delay, clock offset and dispersion for each of the last eight measurement rounds, all in milliseconds. Note that the dispersion, which is an estimate of the error, increases as the age of the sample increases. From these data, it is usually possible to determine the incidence of severe packet loss, network congestion, and unstable local clock oscillators. There are no hard and fast rules here, since every case is unique;

--- however, if one or more of the rounds show large values or change radically from one round to another, the network is probably congested or lossy. ---

[Becks]

Thanks for the link - I'd recommend the debug section at the bottom. I'm currently reading about the intersection algorithm (the last check on this list)... though I'm not sure how relevant this is on my 1 ntp server system! NB I'm getting ' ' when running ntpq -pe which implies I'm failing sanity checks, so I'm not getting as far as the intersection algorithm.

My ntp server (cisco router) is directly connected to my alpha server. I'm not losing packets there. However the ntp server (router) has a bad connection to its ntp server (though it just about maintaining it's *)

Running ntpq -p
the offset is looping round n the cisco router as follows
OFFSET
573.460 (jitter consistenty around 200; delay around 30)
678.159
888.096
993.450
1098.87
1203.27
1308.72
1413.83
-321.82
LOST CONNECTION TO NTP SERVER offset=1623.63
starts looping round again; jitter stabilises to 200; delay consistently 30

So the connection from my alpha to my ntp server (router) is good. But the connection from the ntp server (router) to it's stratum 2 server is dodgy - would this cause me to reject it as a time server?

Do I consider the jitter and offset values of an NTP server when considering if it's a valid time source? I thought it would be enought that it is time synchronised (as indicated by *)?

Thanks,
Beckie

[Bill Hassell]

NTP is a robust protocol so momentary (hours) loss of sync or connectivity is not goinjg to cause jumps in the time. The downstream clients just freewheel until the server appears to be stable. If there is a time drift, it will be slowly adjusted once the server is stable (assuming you are running xntpd and not just jumping the clock with ntpdate.

In your case, the Alpha to Cisco connection is clean but the Cisco to NTP source is questionable. But more important, no NTP server should have one server. A minimim of 3 to 5 servers should be used in the Cisco box. That way, all the sources can be evaluated and a stable sync will be obtained.

[Armin Kunaschik]

It looks like your cisco router has authentication enabled.
The "reject" is listed in the "auth" column...

remove any ntp authentication statements from your cisco configuration and try again.

If you rely on authentication (or the cisco router is not accessable) you need to put the ntp keys on your UNIX system and adjust the ntp configuration accordingly.

My 2 cents,
Armin

[Becks]

Authorisation is not an issue. If you 'Enable Authorisation' this allows you to respond to encoded requests as well as any other requests. I'm receiving replies from the server - if I had failed authorisation it wouldn't even reply. Thanks anyway; every penny helps!

I found something interesting in:
www.lnf.infn.it/computing/unix/ntp/debug.htm
Debug 8,
While the algorithm can tolerate a relatively large frequency error (over 350 parts per million or 30 seconds per day), various configuration errors (and in some cases kernel bugs) can exceed this tolerance, leading to erratic behavior. This can result in frequent loss of synchronization, together with wildly swinging offsets. ... If the error increases by more than 22 milliseconds per 64-second poll interval, the intrinsic frequency must be reduced by some means.

This was written by the same bloke who wrote the protocol.

I was seeing 104 milliseconds per 64-second poll!! So that symptom is identified but no resolution.


I also found out more details of the NTP configuration for my router and above. This was not in line with NTP guidelines either. Consequently errors were increasing down the NTP path.

So in summary: NTP works because you have a selection of time servers. It can make intelligent decisions about which are the best tickers. Please note that when it makes it's decisions it uses the distance to the root, the root dispersion as well as the delay, offset and jitter values for the peer, time intersections and a whole lot else!

I can only assume that a number of these parameters fell out side error bounds specified in the algorithm; unfortunately I haven't found any definitive documentation to confirm this.

Due to corporate restrictions it looks like I'm going to have to revert to a dial up service.
An alternative solution is to set up ntpdate as a cron job but I don't trust my source enough to do that!!

Thanks for all your help.