From: "Vikram Goyal" <vikigoyal@xxxxxxxxx>
From: jdow <jdow@xxxxxxxxxxxxx>
Vikram needs to provide some information from his ntp.conf file.
It may be setup wrong. It is also possible he has recompiled his
kernel. There are options that make ntp synchronization very poor.
<snip>
I have the base kernel of fedora and the ntpd options are defaults only.
===8<---
ntpq> assoc
The diff output of ntpq are:
----------------------------------------------------------------
ntpq> assoc
ind assID status conf reach auth condition last_event cnt
===========================================================
1 18140 8000 yes yes none reject
2 18141 8000 yes yes none reject
3 18142 8000 yes yes none reject
4 18143 9614 yes yes none sys.peer reachable 1
5 18144 8000 yes yes none reject
----------------------------------------------------------------
ntpq> peers
----------------------------------------------------------------
ntpq> peers
remote refid st t when poll reach delay offset
jitter
==============================================================================
64-136-200-96.b .INIT. 16 u - 64 0 0.000 0.000
4000.00
ntp1.chorus.net .INIT. 16 u - 64 0 0.000 0.000
4000.00
64.235.218.180 .INIT. 16 u - 64 0 0.000 0.000
4000.00
*LOCAL(0) LOCAL(0) 10 l 13 64 377 0.000 0.000
0.004
clock1.redhat.c .INIT. 16 u - 64 0 0.000 0.000
4000.00
----------------------------------------------------------------
Strangely, I am able to sync with ntpdate with the above stated command.
Assoc seems to be showing the servers as reachable. But peers is
showing the local host being polled 377 times and the other servers
not being reached.
That suggests you have a firewall issue. You may need to open a hole in
the firewall for NTP service.
Or it may be there is some other issue. I "presume" you are starting
ntpd the normal way via the rcN.d automation at startup rather than
using any "ntp -d" call. The latter could cause problems. If you've
done that kill all running ntpd's and restart using "service ntpd
restart". From that point it should work.
Note that I'm not using one of the standard shorewall firewall setups.
So I handled ntp differently than you might have to. Look in your
firewall log, presumable in /var/log/messages, for blocked messages
on port 123, the ntp port. If you ae getting such messages then you
must tweak your firewall.
This is a distillation of my ntp.conf file:
===8<---
fudge 127.127.1.0 stratum 10
server xxxxxxx.xxx
server xxxxxxx.xxx
server xxxxxxx.xxx
driftfile /etc/ntp/drift
multicastclient # listen on default 224.0.1.1
broadcastdelay 0.008
#restrict default ignore
logfile /var/log/ntp
restrict xxxxxxx.xxx mask 255.255.255.255 nomodify notrap noquery
restrict xxxxxxx.xxx mask 255.255.255.255 nomodify notrap noquery
restrict xxxxxxx.xxx mask 255.255.255.255 nomodify notrap noquery
===8<---
It is the evolutionary product of my initially starting using xntpd
back when it was an experimental protocol. It has the advantage that
"it works for me." {^_-}
{^_^}
