Need trusted NTP Sources

Tony Hain alh-ietf at tndh.net
Fri Feb 7 02:09:17 UTC 2014


> -----Original Message-----
> From: Notify Me [mailto:notify.sina at gmail.com]
> Sent: Thursday, February 06, 2014 4:54 AM
> To: Aled Morris
> Cc: nanog at nanog.org; Martin Hotze
> Subject: Re: Need trusted NTP Sources
> 
> Raspberries! Not common currency here either, but let's see!

While I would be using a Pi if I were doing it now, a few years ago I put
together a circuit that used a <$100 outdoor mast-mount GPS receiver* with a
PPS out, to feed an RS232 connection to 3 FreeBSD 8.1 systems compiled with:
	options         PPS_SYNC                #  
I don't know if that is still required in 10.0, and I understand Linux has
since fixed the kernel time resolution issues it was having, so research
into current OS configuration is required. To make the local time reference
preferred over external references, in ntp conf:
	server 127.127.20.1 mode 8 minpoll 4 maxpoll 4 prefer
The diagram is at http://tndh.net/~tony/GPS-PPS-5v-ttl_232-box.pdf
While there is 'some assembly required', the components to feed existing
servers may be easier to come by than a Pi, and an outdoor receiver will
have better reception than the Adafruit one stuck inside a datacenter. 

As others have said, several external references help protect against any
one source having a bad day, but you should also be aware that network
asymmetry WILL impact your results so factor topology into your source
selection. Using this setup and OWAMP** I was able to track down a ~20ms
"peering asymmetry" between HE & Comcast "inside the Seattle Westin colo",
which still persists.*** It would appear from the time delay that one of
their intermediaries is not really present in the building, but using a
fiber loop to a city about 400 miles away (Boise, or Medford ??). I am not
aware of the specific topology, other than traceroute shows different
intermediaries in each direction at one IP hop, with one taking 20ms longer
than the other to move between the same HE & Comcast routers inside that
colo. What I can see is the impact it has of showing the IPv6 connected NTP
peers as ~10ms off of the local IPv4 ones & the GPS receiver. 

Good luck


* MR-350P
http://www.amazon.com/Globalsat-Waterproof-External-Receiver-without/dp/B001
ENYWJC/ref=sr_sp-atf_title_1_1?ie=UTF8&qid=1391734470&sr=8-1&keywords=mr-350
p

** OWAMP >>> http://software.internet2.edu/owamp/

*** >ntpq -p
     remote           refid      st t when poll reach   delay   offset
jitter
============================================================================
==
xPPS(1)          .PPS.            0 l    7   16  377    0.000    0.001
0.002
oGPS_NMEA(1)     .GPS.            0 l    7   16  377    0.000    0.001
0.002 
*bigben.cac.wash .GPS.            1 u   69   64  372   13.058    1.638
36.654 
+clock.fmt.he.ne .CDMA.           1 u   15   64  373   32.641    1.938
28.828
-chronos6.es.net .CDMA.           1 u    9   64  377   92.321   10.473
2.335
-2001:4f8:2:d::1 129.6.15.29      2 u   31   64  377   35.545    9.912
43.519
-time0.apple.com 17.150.142.121   2 u    2   64  377   44.922   -1.275
26.193


> grateful for all the input and responses, this list is amazing as usual.
> 
> On Thu, Feb 6, 2014 at 1:41 PM, Aled Morris <aledm at qix.co.uk> wrote:
> > On 6 February 2014 12:30, Martin Hotze <m.hotze at hotze.com> wrote:
> >
> >> > I'm trying to help a company I work for to pass an audit, and we've
> >> > been told we need trusted NTP sources (RedHat doesn't cut it).
> >> > Being located in Nigeria, Africa,
> >>
> >  [...]
> >
> >> So build your own stratum 1 server (maybe a second one with DCF77 or
> >> whatever you can use for redundancy),
> >>
> >
> > I don't think DCF77 is going to reach Nigeria.
> >
> > Aled




More information about the NANOG mailing list