perfSONAR User Q&A and Other Discussion

["Hagen, Skye ()" <>]

There are a number of things that this could be.

iptables is not the only access control for NTP running on the system.
ntpd itself has access controls (see the 'restrict' directive) in the
configuration file.

You should verify that you can traceroute to the other servers, do you
have the correct routing?

There could be firewalls, such as a border firewall, somewhere in the
network path that is blocking you.

The remote end could be blocking you. You should check the access policy
for the sites that you are using.

While it doesn't appear to be the case here, NTP can also be authenticated.

You may want to check out the NTP Debugging Techniques page at
http://www.eecis.udel.edu/~mills/ntp/html/debug.html

Skye.

On 3/31/14 11:45 PM, "Amit" 
<>
 wrote:

>Hi,
>
>One of my server is not able to sync with public NTP servers. Please check
>below output for ntpq
>
>[root@perfdel
> ~]# ntpq -p
>     remote           refid      st t when poll reach   delay   offset
>jitter
>==========================================================================
>==
>==
>*10.255.255.3    10.255.255.35    2 u   85  128  377    1.345   -3.608
>27.818
> chronos.es.net  .INIT.          16 u    - 1024    0    0.000    0.000
>0.000
> nms-rlat.chic.n .INIT.          16 u    - 1024    0    0.000    0.000
>0.000
> nms-rlat.hous.n .INIT.          16 u    - 1024    0    0.000    0.000
>0.000
> nms-rlat.losa.n .INIT.          16 u    - 1024    0    0.000    0.000
>0.000
> nms-rlat.newy32 .INIT.          16 u    - 1024    0    0.000    0.000
>0.000
> saturn.es.net   .INIT.          16 u    - 1024    0    0.000    0.000
>0.000
>
>ntpq> as
>
>ind assid status  conf reach auth condition  last_event cnt
>===========================================================
>  1 31515  966a   yes   yes  none  sys.peer    sys_peer  6
>  2 31516  8011   yes    no  none    reject    mobilize  1
>  3 31517  8011   yes    no  none    reject    mobilize  1
>  4 31518  8011   yes    no  none    reject    mobilize  1
>  5 31519  8011   yes    no  none    reject    mobilize  1
>  6 31520  8011   yes    no  none    reject    mobilize  1
>  7 31521  8011   yes    no  none    reject    mobilize  1
>
>I tried with turning iptables off. What could be the issue?
>
>--
>Thanks & Regards
>
>Amit Kumar
>Scientific Officer
>Operation and Routing Group
>M/O Communication and IT, NIC, A- Block, CGO Complex, New Delhi
>Ph. +911122900332, NKN VoIP:7332
>Mob. +919910611621
>
>
>
>
>-----Original Message-----
>From: 
>
>[mailto:]
> On Behalf Of Hagen, Skye
>()
>Sent: Tuesday, April 01, 2014 9:57 AM
>To: Bruce A. Mah; John Mann
>Cc: Amit Kumar; Aaron Brown; 
>
>Subject: RE: [perfsonar-user] Now BWCTL issue....
>
>With NTP, one of the better setups is to call ntpdate during startup of
>the
>system. This will set the clock. Then, run ntpd to keep the clock in sync.
>If the clock is widely out of sync, ntpd will not correct it.
>
>I use 5 servers, this will protect against one false chimer, and allow for
>one to be off-line at the same time. Two is worse than one, unless you
>setup
>ntp to prefer one server.
>
>The interesting thing on his first server is the value of 'reach'. This
>is a
>bit map of the last 8 contact attempts, displayed in octal. So, 352 means
>that, working from the oldest attempt to the newest, attempts 8, 7, 6, 4
>and
>2 got a response. Attempts 5, 3 and the last attempt did not get a
>response.
>(That is, assuming I am interpreting my octal correctly. Remember, there
>are
>three kinds of people in the world. Those that are good at math, and those
>that are not. :-) )  This would seem to indicate a congested link, or
>discards on the path.
>
>Skye Hagen
>Network Engineer
>University of Idaho
>
>
>________________________________________
>From: 
>
><>
> on behalf of Bruce A. Mah
><>
>Sent: Monday, March 31, 2014 5:29 PM
>To: John Mann
>Cc: Amit Kumar; Aaron Brown; 
>
>Subject: Re: [perfsonar-user] Now BWCTL issue....
>
>If memory serves me right, John Mann wrote:
>> Hi,
>>
>> [ CC: list trimmed ]
>>
>> If memory serves me ... ntp likes to sync to a group of servers that
>> are giving about the same time.
>> If it can only see 1 source, it can't decide whether that is a
>> truetimer or an outlying falseticker.
>
>Well...if there's only one source, and it's valid, ntpd has to use that
>one.
>(One of the hazards of having only one or two time servers.)  I would
>expect
>that perfSONAR host to (eventually) sync with that first server.
>
>Also it's not clear why he couldn't sync with the public timeservers.
>Firewall rules / network ACLs maybe?
>
>> https://tools.ietf.org/html/rfc5905#section-11.1
>> NMIN, CMIN ...
>>
>> Suggestions:
>> - Wait.  Sometimes ntp comes good after 20 mins / several hours.
>
>Yes, depending on how the local ntpd is configured.
>
>> - Add another ntp "server" (that has sync'd time) to the setup
>>      - e.g. use a router
>
>I'm trying to resist the temptation to dive into NTP configuration trivia,
>but having two servers isn't a whole lot better than one, because if one
>of
>them misbehaves, the client can't tell which one to trust.  My usual
>practice for generic (i.e. non-perfSONAR) hosts, which mirrors what I
>understand to be best practice, is to pick either 3 or 5 servers, with the
>usual considerations for diversity.
>
>> - "peer" the ntp clients together so that they can have confidence in
>> each other and the primary source
>
>Hrm, a bunch of clients that all peer with each other and get time from a
>single server isn't really any better than just going to the single
>server.
>If that server loses sync or goes down, the client are all going to lose
>sync too, eventually, unless some of them are configured to use their
>local
>clocks as high-stratum NTP servers (I am not recommending that step).
>
>I'm pretty sure the original poster didn't want to set up a local NTP
>infrastructure, he just wants to use what's available.
>
>> It is a bit of a black art.
>
>Oh it's not *that* bad.  I haven't had to sacrifice any goats for several
>years now.  :-)
>
>Bruce.
>
>> You might end up with a ntp cloud that regains sync if you reboot one
>> node, but if you reboot everything all at once it won't re-sync.
>>
>> Thanks,
>>     John
>>
>>
>> On 1 April 2014 07:49, Bruce A. Mah 
>> <
>>  
>> <mailto:>>
>> wrote:
>>
>>     If memory serves me right, Amit Kumar wrote:
>>     > Yes Aaron
>>
>>     If I'm reading the ntpq -p output correctly...
>>
>>     >>>      remote           refid      st t when poll reach   delay
>>     offset
>>     >>> jitter
>>     >>>
>>
>==========================================================================
>==
>>     >>> ==
>>     >>> 10.255.255.3    10.255.255.35    2 u  519 1024  352    1.396
>>     -4.134
>>     >>> 12.624
>>     >>> chronos.es.net <http://chronos.es.net>  .INIT.          16 u
>>      - 1024    0    0.000    0.000
>>     >>> 0.000
>>     >>> nms-rlat.chic.n .INIT.          16 u    - 1024    0    0.000
>>      0.000
>>     >>> 0.000
>>     >>> nms-rlat.hous.n .INIT.          16 u    - 1024    0    0.000
>>      0.000
>>     >>> 0.000
>>     >>> nms-rlat.losa.n .INIT.          16 u    - 1024    0    0.000
>>      0.000
>>     >>> 0.000
>>     >>> nms-rlat.newy32 .INIT.          16 u    - 1024    0    0.000
>>      0.000
>>     >>> 0.000
>>     >>> saturn.es.net <http://saturn.es.net>   .INIT.          16 u    -
>>     1024    0    0.000    0.000
>>     >>> 0.000
>>
>>     ...it looks like the host in question isn't synched against
>10.255.255.3
>>     (or anything else for that matter) because there's no "*" in front
>>of
>>     that line...that indicates a host that is the current time source.
>>
>>     Bruce.
>>
>>
>>
>
>