[ntp:questions] .INIT. oddity

Tuc at T-B-O-H.NET ml at t-b-o-h.net
Sun Jul 13 17:14:08 UTC 2008


> 
> Tuc at T-B-O-H.NET wrote:
> >> Tuc at T-B-O-H.NET wrote:
> >>> Hi,
> >>>
> >>> 	Having an issue and its really perplexing. Its a bit of a read,
> >>> so maybe you'll want to go for a dinner break first...
> >>>
> >>> 	The story starts out with a FreeBSD 4.X system (Its my personal
> >>> server, I've been lazy to upgrade it, I know, I know, I know) running
> >>> 4.1.0-a . We'll call this BAD_SYSTEM. The /etc/ntp.conf is just :
> >>>
> >>> server GOOD_SERVER1
> >>> server GOOD_SERVER2
> >>> server 0.us.pool.ntp.org
> >>> server 1.us.pool.ntp.org
> >>> server 2.us.pool.ntp.org
> >>> server 0.ca.pool.ntp.org
> >>> server 0.mx.pool.ntp.org
> >>>
> >>> 	I have 2 local NTP servers, FreeBSD 5.5 systems (Not my fault
> >>> again, I'm required to run that version currently). Both of them are
> >>> running 4.2.0-a. We'll call them GOOD_SERVER1 and GOOD_SERVER2 .
> >>>
> >>> 	When the story started, I saw the following in an ntpq{peers} :
> >>>
> >>>      remote           refid      st t when poll reach   delay   offset  jitter
> >>> ==============================================================================
> >>>  GOOD_SERVER1    .INIT.          16 u    -   64    0    0.000    0.000   0.000
> >>>  GOOD_SERVER2    .INIT.          16 u    -   64    0    0.000    0.000   0.000
> >>> +ntp2.your.org   216.218.254.202  2 u  616 1024  377   22.438  -37.986   2.191
> >>> +clock.trit.net  192.12.19.20     2 u  562 1024  377   82.501  -29.933   0.219
> >>> +lashiir.sapros. 74.53.198.146    3 u  572 1024  377   44.344  -45.981   0.023
> >>> *raptor.tera-byt 64.236.96.53     2 u  565 1024  377   80.970  -32.695   3.159
> >>> -cronos.cenam.mx .GPS.            1 u  504 1024  377  236.263   31.443 130.461
> >>>
> >>> 	I wasn't sure why it wasn't syncing to servers 3 feet away from it,
> >>> on the same router (different subnet, but there is perfect connectivity between
> >>> the two {GOOD_SERVER1+2 are also DNS servers for the machine, SMARTHOSTS, etc)
> >>> so I pulled an "M$" and restarted ntp. No dice. I ran ntpdates to both of them
> >>> perfectly, no issues, etc. I even used a web page that ran against them and 
> >>> came back with sane looking info. tcpdumps seemed to show the request went out,
> >>> got to GOOD_SERVER1+2, went back, and got back to BAD_SYSTEM. 
> >>>
> >>> 	So I then tried the typical thing of upgrading BAD_SYSTEM to 
> >>> 4.2.4p4 at 1.1520-o . Same thing. 
> >>>
> >>> 	I then upgraded GOOD_SERVER2 to 4.2.4p4 at 1.1520-o . Same thing.
> >>>
> >>> 	harlan on IRC had me do "peer" instead of "server". 
> >>>
> >>> BEFORE GOOD_SERVER2 WAS UPGRADED:
> >>>
> >>> 	BAD_SYSTEM: .INIT.
> >>> 	GOOD_SERVER2: .DROP.
> >>>
> >>> AFTER GOOD_SERVER2 WAS UPGRADED:
> >>>
> >>> 	BAD_SYSTEM: .INIT.
> >>> 	GOOD_SERVER2: showed valid information
> >> I wouldn't recommend trying to use peer here. What's in the 
> >> good_server's ntp.conf file. Do you have any restrict options? Did you 
> >> put in the fully-qualified domain name (FQDN) of the good server in the 
> >> ntp.conf file? Does the name you have in the ntp.conf file resolve? Use 
> >> dig +search to check this. Are there any errors in the log?
> >>
> >> If all of this checks out start running tcpdump and make sure the 
> >> packets are going out and on the other side, coming in.
> >>
> > 
> > 	Sorry I realized I forgot GOOD_SERVER1+2's ntp.conf. They both are:
> > 
> > server 0.us.pool.ntp.org
> > server 1.us.pool.ntp.org
> > server 2.us.pool.ntp.org
> > server 0.ca.pool.ntp.org
> > server 0.mx.pool.ntp.org
> > 
> > 	No, no restrict. Yes, FQDN. Yes, name resolves to an A record, but
> > the forward/backward don't match. (I'm referencing GOOD_SERVER1 as ntp1.example.com,
> > but its in-addr.arpa is v.example.com . GOOD_SERVER2 as ntp2.example.com, but 
> > its in-addr.arpa is a.example.com . )  I've got the same ntp.conf on BAD_SERVER
> > as every OTHER server in the datacenter, and none of the others have the slightest
> > problem. dig +search shows an "IN A" of the proper IP. No errors in the logs.
> > 
> > 	Yup, they do. I can track the packets back and forth on both systems.
> > 
> > 			Tuc/TBOH
> > 
> 
> Then the next question is what does ntpq show when querying that server? 
> Your server is certainly saying that there is something wrong with that 
> server. Are these servers on the Internet or are they behind a firewall?
> 
> Danny
> 
	Not sure which server is "that server". If I ntpq/peers on BAD_SYSTEM,
I see ".INIT." for GOOD_SERVER1 and GOOD_SERVER2. If I ntpq/peers on ANOTHER_SYSTEM1
I see :

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
+ntp2.arttoday.c 10.0.0.55        3 u  416 1024  377   90.511   -5.703   0.519
 time.awin.com   .STEP.          16 u 380d 1024    0    0.000    0.000 4000.00
+198.247.173.220 128.206.12.130   3 u  439 1024  377   35.045    5.241   0.771
*GOOD_SERVER1    200.23.51.205    2 u  401 1024  377    0.470    3.214   0.636
+GOOD_SERVER2    148.234.7.30     3 u  365 1024  377    0.700   12.488   0.515

	and on ANOTHER_SYSTEM2 I see :

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
+clock.trit.net  192.12.19.20     2 u  242 1024  377   82.996   -8.153   0.216
+elle.fallingsno 138.23.180.126   3 u  335 1024  377   82.257   -2.162   0.965
+patbox3.patrick 64.90.182.55     2 u  311 1024  377    8.085   -2.549   0.257
*GOOD_SERVER1    200.23.51.205    2 u  230 1024  377    0.465   -4.408   0.908
-GOOD_SERVER2    148.234.7.30     3 u  329 1024  377    0.597    4.544   0.192

	I can even "ntpq GOOD_SERVER1" and "ntpq GOOD_SERVER2" from BAD_SYSTEM
and have it show me the peers there.

	It seems ONLY my personal server is claiming to have issues. The
systems are physically plugged into the same router, and not behind any sort
of NAT, or anything that would impeede it. The packet travels about 6 feet
of cable TOTAL between the 2 systems.

			Tuc



More information about the questions mailing list