[ntp:questions] .INIT. oddity

Tuc at T-B-O-H.NET ml at t-b-o-h.net
Fri Jul 11 15:08:56 UTC 2008


> 
> 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



More information about the questions mailing list