Mailing List Archive

NTP network design considerations
To all,

How are you integrating NTP into your infrastructures? Is it part of your
management network(s)?
In the past it used to be that the management network was a flat network,
now we deploy north of the FW security zone management network and south of
the FW security zone management network. In this case the stratum 1 time
sync is from an org within my company but outside of my division. I want to
isolate the NTP infrastructure via a FW interface for traffic isolation
and inspection.

I am curious how others are segmenting flows/traffic in their management
networks to isolate traffic flows. mngmt VRFs, vlans, L3 interfaces,
etc.... Specifically how are you dealing with NTP infrastructure that all
infrastructure obtains time from?


Mike
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: NTP network design considerations [ In reply to ]
Hi,

On Fri, Oct 14, 2022 at 10:27:16AM -0400, harbor235 via cisco-nsp wrote:
> How are you integrating NTP into your infrastructures? Is it part of your
> management network(s)?

NTP servers (appliances from Meinberg and regular FreeBSD servers, basically)
are just sitting "on the Internet" and our machines sync to them, and
monitor their relative times (= so if one is misbehaving, NTP will
do the right thing on its own, and monitoring will tell us so we can
fix it).

The machines protect themselves by local iptables rules for SSH/https,
and in-band by NTP access rules ("serve time to everyone, serve larger
responses only to management systems, do not believe anyone").

I've never understood this obsession on filtering things that are intended
to be put out in the wild.

gert

--
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany gert@greenie.muc.de
Re: NTP network design considerations [ In reply to ]
I hear what your saying but NTP is an active attack vector, I don't trust
outside resources implicitly and traffic segmentation is a prudent measure
especially if you are getting internet time. Now if you have your own
stratum1 then I understand your point more.


Mike

On Fri, Oct 14, 2022 at 10:45 AM Gert Doering <gert@greenie.muc.de> wrote:

> Hi,
>
> On Fri, Oct 14, 2022 at 10:27:16AM -0400, harbor235 via cisco-nsp wrote:
> > How are you integrating NTP into your infrastructures? Is it part of your
> > management network(s)?
>
> NTP servers (appliances from Meinberg and regular FreeBSD servers,
> basically)
> are just sitting "on the Internet" and our machines sync to them, and
> monitor their relative times (= so if one is misbehaving, NTP will
> do the right thing on its own, and monitoring will tell us so we can
> fix it).
>
> The machines protect themselves by local iptables rules for SSH/https,
> and in-band by NTP access rules ("serve time to everyone, serve larger
> responses only to management systems, do not believe anyone").
>
> I've never understood this obsession on filtering things that are intended
> to be put out in the wild.
>
> gert
>
> --
> "If was one thing all people took for granted, was conviction that if you
> feed honest figures into a computer, honest figures come out. Never
> doubted
> it myself till I met a computer with a sense of humor."
> Robert A. Heinlein, The Moon is a Harsh
> Mistress
>
> Gert Doering - Munich, Germany
> gert@greenie.muc.de
>
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: NTP network design considerations [ In reply to ]
You can setup a raspberry pi as a server and do GPS. Not sure on the
scalability (how many devices it can handle) of that but it does work.
I would do at least 3 in different servers/locations, then have my routers
slave off them and peer with each other.
It is internal and is cheap.
There are a few sources on the internet that I trust for time. It depends
on your level of comfort.

Aaron

On Fri, Oct 14, 2022 at 2:43 PM harbor235 via cisco-nsp <
cisco-nsp@puck.nether.net> wrote:

> I hear what your saying but NTP is an active attack vector, I don't trust
> outside resources implicitly and traffic segmentation is a prudent measure
> especially if you are getting internet time. Now if you have your own
> stratum1 then I understand your point more.
>
>
> Mike
>
> On Fri, Oct 14, 2022 at 10:45 AM Gert Doering <gert@greenie.muc.de> wrote:
>
> > Hi,
> >
> > On Fri, Oct 14, 2022 at 10:27:16AM -0400, harbor235 via cisco-nsp wrote:
> > > How are you integrating NTP into your infrastructures? Is it part of
> your
> > > management network(s)?
> >
> > NTP servers (appliances from Meinberg and regular FreeBSD servers,
> > basically)
> > are just sitting "on the Internet" and our machines sync to them, and
> > monitor their relative times (= so if one is misbehaving, NTP will
> > do the right thing on its own, and monitoring will tell us so we can
> > fix it).
> >
> > The machines protect themselves by local iptables rules for SSH/https,
> > and in-band by NTP access rules ("serve time to everyone, serve larger
> > responses only to management systems, do not believe anyone").
> >
> > I've never understood this obsession on filtering things that are
> intended
> > to be put out in the wild.
> >
> > gert
> >
> > --
> > "If was one thing all people took for granted, was conviction that if you
> > feed honest figures into a computer, honest figures come out. Never
> > doubted
> > it myself till I met a computer with a sense of humor."
> > Robert A. Heinlein, The Moon is a Harsh
> > Mistress
> >
> > Gert Doering - Munich, Germany
> > gert@greenie.muc.de
> >
> _______________________________________________
> cisco-nsp mailing list cisco-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: NTP network design considerations [ In reply to ]
Hi,

On Fri, Oct 14, 2022 at 02:41:45PM -0400, harbor235 wrote:
> I hear what your saying but NTP is an active attack vector, I don't trust
> outside resources implicitly and traffic segmentation is a prudent measure
> especially if you are getting internet time. Now if you have your own
> stratum1 then I understand your point more.

The Meinberg boxes have GPS receivers, so they provide Stratum 1 directly.

The FreeBSD boxes run standard NTP time, and sync to a variety of
official sources (like ntp.se) that are hard to manipulate all at
the same time.

Now what I'd really like is to use one of those...

https://www.oscilloquartz.com/de-de/products-and-services/ptp-grandmaster-clocks/sfp-pluggable-ptp-grandmasters/osa-5401-series

... plug it directly into one of our Aristas, *and* have the router
use the PTP time source to feed its own NTP service, as stratum 1...

"Less boxes"

gert
--
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany gert@greenie.muc.de
Re: NTP network design considerations [ In reply to ]
Hi,

On Fri, Oct 14, 2022 at 03:07:47PM -0400, Aaron wrote:
> You can setup a raspberry pi as a server and do GPS. Not sure on the
> scalability (how many devices it can handle) of that but it does work.

For a true time geek, the time the rPIs provide is just not good
enough (fluctuates +/- 20 usec if the rPI has work to do and gets
warm) :-)

http://www.satsignal.eu/ntp/Raspberry-Pi-NTP.html

... but for "I want my own Stratum 1 device and it should not cost
a fortune" it's definitely good enough... (I have one with a DCF77
antenna lying around somewhere here, for my network @ home)

gert

--
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany gert@greenie.muc.de
Re: NTP network design considerations [ In reply to ]
On Fri, 14 Oct 2022 at 23:32, Gert Doering via cisco-nsp
<cisco-nsp@puck.nether.net> wrote:

> For a true time geek, the time the rPIs provide is just not good
> enough (fluctuates +/- 20 usec if the rPI has work to do and gets
> warm) :-)

Meinberg does not do HW timestamping, nor does NTP. Almost every NIC
out there actually does support HW timestamping, but you'd need chrony
to actually enable the support.

When using Meinberg and clocking your host, ~all of the inaccuracy is
due to SW timestamping, oscillator doesn't matter. Basically with NTP
you are measuring the host context switch times in your jitter. This
is because networks have become organically extremely low jitter
(because storing packets is expensive).
We see across our network single digit microsecond jitters (in my M1
computer I see loopback pings having >50us stddev in latency), and
because the timing we use is SW timestamp, our one-way delay
measurement precision is measuring the NTP host kernel/software
context switch delays.
The most expensive oscillator would do nothing for us, but HW
timestamping and cheap 2eur OXCO would radically improve the quality
of our one-way delay measurements.


--
++ytti
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/