Henrique M Holschuh wrote:
> 
> On Mon, 13 Dec 1999, Dan Hugo wrote:
> > $ntptrace tock.cs.unlv.edu
> > tock.CS.UNLV.EDU: stratum 2, offset 0.853196, synch distance 0.04726
> > usno.pa-x.dec.com: stratum 1, offset 0.842812, synch distance 0.02371,
> > refid 'USNO'
> 
> Those offset lines are worrisome. NTP does not deal well with large offsets
> and delay (round-trip time) by design (it would be pointless, you can't sync
> over such a link), and will promptly exit if it gets worse than 1s. You're
> at 0.8s already, and that's way too high.
> 
> One thing you -must- do when you have such a bad sync is to run ntpdate in
> the same server-set you will run ntp against right before you start ntp.
> Debia potato gets this right, don't know about slink.

I do run ntpdate in /etc/init.d/xntp3

That is interesting about the round-trip time.  I will try to find some
servers closer.

But here is the interesting part:

Machines inside my masqueraded network can see tock just fine (I
determined this by pointing one machine inside at tock, rather than
pointing it at my xntpd+masquerade machine), which really points at
ipchains being bad...

> > I am not sure where to look now.  I believe that ipchains is configured
> > to allow ntp to communicate, but I could be wrong.  I am suspicious of
> > my ipchains config.
> 
> Don't kill tcp or udp packets from/to the ntp service port, nor delay them.
> When in doubt, try ntpq -p <host> to "ping" the servers.

Interesting.

I have tock as the first server listed in the masq machine's ntp.conf
file.  On the machine inside, I see from /var/log/xntpd

13 Dec 03:09:07 xntpd[26296]: synchronized to 131.216.18.4, stratum=3

But not such message in the log file on the outside machine.


BUT, running ntpq -p 131.216.18.4 on the outside machine:

     remote           refid      st t when poll reach   delay  
offset    disp
==============================================================================
.207.247.149.141 timekeeper.isi.  2 u  360 1024  366   208.04   22.500 
282.15
+castor.nevada.e clepsydra.dec.c  2 u   77  128  377    -0.35  
-1.698    2.49
-vegas.engineeri clock.isc.org    2 u  770 1024  356    65.86   90.993  
24.80
-shell2.astreet. clepsydra.dec.c  2 u   43  128  372    68.07   68.881  
21.59
x155.178.210.11  tgf_s1.ntp.tc.f  2 u   20   64  376   939.77  412.093  
32.00
xsulu.hfl.tc.faa 172.26.251.9     2 u   65   64  376   695.30  267.309  
76.61
.astreet.com     clepsydra.dec.c  2 u   11   64  277    56.00   92.711  
15.49
-fe01-r01-core.t 132.163.135.130  2 u  110  256  377   138.44   32.125  
16.57
xgw.decide2act.c clepsydra.dec.c  2 u  136   64  374   187.67  -1924.9 
885.97
-blackcomb.sfu.c tick.usno.navy.  2 u  194  512  377   121.61  -34.844  
34.35
-whistler.sfu.ca tick.usno.navy.  2 u   25  512  177   123.72  -29.541 
104.80
<ctrl-C>

and ntptrace 131.216.18.4
tock.CS.UNLV.EDU: stratum 2, offset 0.978212, synch distance 0.11465
haven.umd.edu: stratum 1, offset 0.976242, synch distance 0.01128, refid
'WWVB'


> Also, just to be sure... you did notice debian potato packages ntp V4 (don't
> know about slink), and used the proper "version 3" strings after the servers
> in /etc/ntp.conf for any debian potato machines, didn't you?

I am using xntp3 from slink... though I even tried ntpdate -o[1,2,3]
with no real difference on the outside machine.

Reply via email to