perfsonar-user - RE: [perfsonar-user] Now BWCTL issue....
Subject: perfSONAR User Q&A and Other Discussion
List archive
- From: Amit <>
- To: "'Hagen, Skye'" <>, "'Bruce A. Mah'" <>, 'John Mann' <>
- Cc: 'Aaron Brown' <>,
- Subject: RE: [perfsonar-user] Now BWCTL issue....
- Date: Wed, 02 Apr 2014 09:36:35 +0530
Hi Skye,
I Have already checked everything, nothing is the case, I am having 5 more
servers with the same configuration and settings.
Please find below configuration file.
----------------------------------------------------------------------------
------------------------
# /etc/ntp.conf, configuration for NTP
# by default act only as a basic NTP client
restrict -4 default nomodify nopeer noquery notrap
restrict -6 default nomodify nopeer noquery notrap
# allow NTP messages from the loopback address, useful for debugging
restrict 127.0.0.1
restrict ::1
logfile /var/log/ntpd
driftfile /var/lib/ntp/ntp.drift
statsdir /var/lib/ntp/
statistics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable
# You should have at least 4 NTP servers
server 127.127.1.0 # local clock
server 10.255.255.3 iburst
server chronos.es.net iburst # ESnet - New York, NY USA
server owamp.chic.net.internet2.edu iburst # Internet2 - Chicago, IL USA
server owamp.hous.net.internet2.edu iburst # Internet2 - Houston, TX USA
server owamp.losa.net.internet2.edu iburst # Internet2 - Los Angeles, CA
USA
server owamp.newy.net.internet2.edu iburst # Internet2 - New York, NY USA
server saturn.es.net iburst # ESnet - Sunnyvale, CA USA
----------------------------------------------------------------------------
--------------------------------
Secondly I could do the traceroute the above NTP server, also please find
below the "ntpdate" output for particular server
----------------------------------------------------------------------------
------------
[root@perfdel
~]# ntpdate -ud saturn.es.net
2 Apr 09:28:04 ntpdate[18041]: ntpdate
Sat Nov 23 18:21:48
UTC 2013 (1)
Looking for host saturn.es.net and service ntp
host found : saturn.es.net
transmit(198.129.252.38)
receive(198.129.252.38)
transmit(198.129.252.38)
receive(198.129.252.38)
transmit(198.129.252.38)
receive(198.129.252.38)
transmit(198.129.252.38)
receive(198.129.252.38)
server 198.129.252.38, port 123
stratum 1, precision -22, leap 00, trust 000
refid [CDMA], delay 0.30948, dispersion 0.00000
transmitted 4, in filter 4
reference time: d6e60951.a0b860f1 Wed, Apr 2 2014 9:28:09.627
originate timestamp: d6e60958.883e60d2 Wed, Apr 2 2014 9:28:16.532
transmit timestamp: d6e6094e.32824d9a Wed, Apr 2 2014 9:28:06.197
filter delay: 0.30952 0.30948 0.30952 0.30952
0.00000 0.00000 0.00000 0.00000
filter offset: 10.19292 10.19292 10.19292 10.19291
0.000000 0.000000 0.000000 0.000000
delay 0.30948, dispersion 0.00000
offset 10.192929
2 Apr 09:28:06 ntpdate[18041]: step time server 198.129.252.38 offset
10.192929 sec
----------------------------------------------------------------------------
----------------------------------------------------
--
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 11:47 PM
To: Amit; 'Bruce A. Mah'; 'John Mann'
Cc: 'Aaron Brown';
Subject: Re: [perfsonar-user] Now BWCTL issue....
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.
>>
>>
>>
>
>
- RE: [perfsonar-user] Now BWCTL issue...., Hagen, Skye (), 04/01/2014
- RE: [perfsonar-user] Now BWCTL issue...., Amit, 04/01/2014
- Re: [perfsonar-user] Now BWCTL issue...., Hagen, Skye (), 04/01/2014
- RE: [perfsonar-user] Now BWCTL issue...., Amit, 04/02/2014
- Re: [perfsonar-user] Now BWCTL issue...., Jason Zurawski, 04/02/2014
- RE: [perfsonar-user] Now BWCTL issue...., Amit, 04/03/2014
- Re: [perfsonar-user] Now BWCTL issue...., Jason Zurawski, 04/02/2014
- RE: [perfsonar-user] Now BWCTL issue...., Amit, 04/02/2014
- Re: [perfsonar-user] Now BWCTL issue...., Hagen, Skye (), 04/01/2014
- RE: [perfsonar-user] Now BWCTL issue...., Amit, 04/01/2014
Archive powered by MHonArc 2.6.16.