[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: FC4 NTPD problem



From: "Vikram Goyal" <vikigoyal gmail com>

From: jdow <jdow earthlink net>

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." {^_-}

{^_^}



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]