Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

A few days ago I had ntp setup on my network, and everything was running fine. One node was set to sync with upstream servers, and the rest of the nodes from the one set to sync upstream.

Yesterday I updated from CentOS 6.4 -> 6.5 and now all of the ntp functionality has ceased to operate as expected.

In efforts of trying to debug the situation, I ran the following on the upstream server:

$ -> ntpq -pnd
::1: timed out, nothing received
***Request timed out

$ -> ntpq -4 -pnd
1 packets reassembled into response
remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
2 packets reassembled into response
*50.116.55.65    64.246.132.14    2 u   42   64   37   77.742  189.392  14.812
2 packets reassembled into response
 199.102.46.73   .GPS.            1 u   44   64   37   73.786  216.082  18.406
2 packets reassembled into response
 198.60.22.240   .GPS.            1 u   48   64   37   22.617  189.405  15.996
2 packets reassembled into response
 127.127.1.0     .LOCL.          10 l  306   64   20    0.000    0.000   0.000

I get the same results (save for diff ip) on the nodes. It seems, somehow the ntp service is defaulting to ipv6, which I do not have configured. I've read some sites saying to pass -4 to the ntpd service, but how would I do that using chkconfig? Some other readings indicated that I should disable ipv6 via the kernel, but this seems like overkill.

Any suggestions?

For the sake of completeness, adding config file:

driftfile /var/lib/ntp/drift

# Permit time synchronization with our time source, but do not
# permit the source to query or modify the service on this system.
restrict default kod nomodify notrap nopeer noquery
restrict -6 default kod nomodify notrap nopeer noquery

# Permit all access over the loopback interface.  This could
# be tightened as well, but to do so would effect some of
# the administrative functions.
restrict 127.0.0.1

restrict 10.0.0.0 mask 255.255.192.0 nomodify notrap


server 0.centos.pool.ntp.org iburst

server 1.centos.pool.ntp.org

server 2.centos.pool.ntp.org


# In case net access is temporarily down
server 127.127.1.0
fudge 127.127.1.0 stratum 10
share|improve this question
2  
restrict -6 ::1? –  SaveTheRbtz Jan 11 at 21:18
    
Damn, your right that was it. Must have removed it by accident for some reason. –  Mike Purcell Jan 12 at 0:56
    
Ugh on another note. You fell victim to the worst ntp practical joke. Somewhere someone decided that it would be funny to recommend kod without limited, kod is useless without limited. wherever you see kod change it to kod limited. This has nothing to do with your problem but it is the right way to configure the default rate limiting. –  dfc Jan 13 at 5:52
    
@dfc: Duly noted, thanks for the input. –  Mike Purcell Jan 13 at 5:52
    
@dfc: Weird... I ran ntpq -pn on all the local nodes and they are all favoring the local server (127.127.1.0), whereas they used to favor the local ntp server (10.0.0.3). Wonder if the kod (without limited) caused the issue? Before the update I used to see chatter between the local ntp server and nodes, but now, nothing, just log entries on the nodes. –  Mike Purcell Jan 13 at 6:03

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Browse other questions tagged or ask your own question.