IETF Logo Mail Archive

[TICTOC] Antw: Re: [ntpwg] Antw: operational experience with NTP symmetric mode

"Ulrich Windl" <Ulrich.Windl@rz.uni-regensburg.de> Mon, 09 May 2016 07:42 UTC

Return-Path: <Ulrich.Windl@rz.uni-regensburg.de>
X-Original-To: tictoc@ietfa.amsl.com
Delivered-To: tictoc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90F3712D1E7 for <tictoc@ietfa.amsl.com>; Mon, 9 May 2016 00:42:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.195
X-Spam-Level:
X-Spam-Status: No, score=-4.195 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3YGOpoQ5iV34 for <tictoc@ietfa.amsl.com>; Mon, 9 May 2016 00:42:36 -0700 (PDT)
Received: from rrzmta1.uni-regensburg.de (rrzmta1.uni-regensburg.de [194.94.155.51]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B04DE12D19B for <tictoc@ietf.org>; Mon, 9 May 2016 00:42:35 -0700 (PDT)
Received: from rrzmta1.uni-regensburg.de (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 7B9FF36C25 for <tictoc@ietf.org>; Mon, 9 May 2016 09:42:34 +0200 (CEST)
Received: from gwsmtp1.uni-regensburg.de (gwsmtp1.uni-regensburg.de [132.199.5.51]) by rrzmta1.uni-regensburg.de (Postfix) with ESMTP id F23DF5753C for <tictoc@ietf.org>; Mon, 9 May 2016 09:42:33 +0200 (CEST)
Received: from uni-regensburg-smtp1-MTA by gwsmtp1.uni-regensburg.de with Novell_GroupWise; Mon, 09 May 2016 09:42:37 +0200
Message-Id: <57305B86020000A100021293@gwsmtp1.uni-regensburg.de>
X-Mailer: Novell GroupWise Internet Agent 14.2.0
Date: Mon, 09 May 2016 09:42:30 +0200
From: Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de>
References: Message from "Ulrich Windl" <Ulrich.Windl@rz.uni-regensburg.de> of "Mon, 09 May 2016 08:44:28 +0200." <57304DEC020000A100021281@gwsmtp1.uni-regensburg.de> <20160509073337.E14F0406061@ip-64-139-1-69.sjc.megapath.net>
In-Reply-To: <20160509073337.E14F0406061@ip-64-139-1-69.sjc.megapath.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Archived-At: <http://mailarchive.ietf.org/arch/msg/tictoc/MCG5P-hdGhv_PIz8pkcDoArfLZI>
Cc: goldbe@cs.bu.edu, ntpwg@lists.ntp.org, "tictoc@ietf.org" <tictoc@ietf.org>
Subject: [TICTOC] Antw: Re: [ntpwg] Antw: operational experience with NTP symmetric mode
X-BeenThere: tictoc@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Timing over IP Connection and Transfer of Clock BOF <tictoc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tictoc>, <mailto:tictoc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tictoc/>
List-Post: <mailto:tictoc@ietf.org>
List-Help: <mailto:tictoc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tictoc>, <mailto:tictoc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 May 2016 07:42:37 -0000

>>> Hal Murray <hmurray@megapathdsl.net> schrieb am 09.05.2016 um 09:33 in
Nachricht <20160509073337.E14F0406061@ip-64-139-1-69.sjc.megapath.net>:

> Ulrich.Windl@rz.uni-regensburg.de said:
>> We used peering about as long as we used NTP (since 1993 or so).
>> Unfortunately the latest NTP release broke NTP peering with authentication
>> (bug 3001), so we turned it off until  the issue is fixed. 
> 
> Did you turn off peering or authentication?

Peering.

> 
> Peering seems natural for the case where you have 2 equal servers and you 
> want them to keep an eye on each other.  Aside from reducing the number of 
> packets by a factor of 2, are there any reasons for using peer rather than 
> server?  Is there any extra information exchanged?

If you operate clusters, you may have a tendency to let all the cluster nodes peer, because when in doubt it's more important that the nodes agree on a common time rather than having the correct time (if very odd things happen). Despite of that using "peer" instead of "two-way "server" is self-documentation: It's more clear from ntp.conf what happens  (is expected to happen) ;-)

> 
> 
> 
> 
> 
> -- 
> These are my opinions.  I hate spam.

v2.23.0 | Report a Bug | By Email