Enterprise NTP Architecture - NTP
This is a discussion on Enterprise NTP Architecture - NTP ; Hi,
I need to design a new NTP architecture for my company, medium-sized
with about 2000 workstations and servers. We use ActiveDirectory 2003
as the main directory for workstations but we also have VMWare, UNIX
and LINUX servers. I was ...
-
Enterprise NTP Architecture
Hi,
I need to design a new NTP architecture for my company, medium-sized
with about 2000 workstations and servers. We use ActiveDirectory 2003
as the main directory for workstations but we also have VMWare, UNIX
and LINUX servers. I was wondering what architecture would suit us
best. We have 2 lines of firewalls and DMZs before the internet, and a
corporate switched LAN with a few core routers.
I was thinking of a distributed time topology with two peered NTP
servers in DMZ (on different sites if possible), with ISP external
sources, delivering time to two peered Cisco core routers inside the
LAN. These routers would be the masters clocks for the internal
network, composed of our ActiveDirectory DCs (with all the
workstations pointing on them), the internal network equipments, and
the internal servers (including the VMWare farm). The DMZ machines
would point to the DMZ NTP servers.
What is your opinion ? Is it a good idea to have the DCs sync to
routers ? If no, what should I choose as the main time server for my
internal network (a PDC server, a router, a simple server ?)
Thank you for your answers!
/David
-
Re: Enterprise NTP Architecture
david.hache.david@gmail.com wrote:
> Hi,
>
> I need to design a new NTP architecture for my company, medium-sized
> with about 2000 workstations and servers. We use ActiveDirectory 2003
> as the main directory for workstations but we also have VMWare, UNIX
> and LINUX servers. I was wondering what architecture would suit us
> best. We have 2 lines of firewalls and DMZs before the internet, and a
> corporate switched LAN with a few core routers.
>
> I was thinking of a distributed time topology with two peered NTP
> servers in DMZ (on different sites if possible), with ISP external
> sources, delivering time to two peered Cisco core routers inside the
> LAN. These routers would be the masters clocks for the internal
> network, composed of our ActiveDirectory DCs (with all the
> workstations pointing on them), the internal network equipments, and
> the internal servers (including the VMWare farm). The DMZ machines
> would point to the DMZ NTP servers.
>
> What is your opinion ? Is it a good idea to have the DCs sync to
> routers ? If no, what should I choose as the main time server for my
> internal network (a PDC server, a router, a simple server ?)
>
> Thank you for your answers!
>
> /David
Routers do not make the best clocks! They are highly specialized
devices with a great deal of work to do.
Do you have an old X86 server that's not quite good enough any longer?
NTP is not terribly demanding and an old server running Linux would make
a very good time server.
You might consider using broadcast or multicast modes.
-
Re: Enterprise NTP Architecture
On Mon, Sep 29, 2008 at 4:20 PM, wrote:
> I was thinking of a distributed time topology with two peered NTP
> servers in DMZ (on different sites if possible), with ISP external
> sources, delivering time to two peered Cisco core routers inside the
> LAN. These routers would be the masters clocks for the internal
> network, composed of our ActiveDirectory DCs (with all the
> workstations pointing on them), the internal network equipments, and
> the internal servers (including the VMWare farm). The DMZ machines
> would point to the DMZ NTP servers.
Having two NTP servers in a tier is the worst possible configuration.
Three or more servers are required for redundancy and accuracy. If you
have two servers, how do you know which server has the correct time?
I have a client with a similar topology, and use four internal NTP
servers that peer with one another at two sites. Two of these are
actually VMware ESX hosts (not VMs!), which run NTP in the service
console. All have one unique internet time source in addition to three
"peer" lines referencing the others.
All of the Windows 2003 domain controllers (again, two at each site)
are configured as clients of all four "real" NTP servers. Windows
clients get time from domain controllers automatically. Other
non-windows servers, workstations, and network devices are NTP clients
of all four of the NTP server farm via "ntp0-4" DNS aliases. We use
NTP authentication where needed.
Actual placement of the servers inside your network doesn't matter
much - NTP is a lightweight protocol with a very small attack surface.
As others have mentioned, for some reason routers make poor time
servers (at least Ciscos). I used to use core routers as NTP servers
at this client, and discovered they inexplicably drifted 50ms or more
in either direction, even when lightly loaded.
--
RPM
-
Re: Enterprise NTP Architecture
Richard B. Gilbert wrote:
> Routers do not make the best clocks! They are highly specialized
> devices with a great deal of work to do.
Seconded.
>
> Do you have an old X86 server that's not quite good enough any longer?
> NTP is not terribly demanding and an old server running Linux would make
> a very good time server.
FreeBSD is exactly the same cost, but makes for even better startum 1
servers, i.e. with a $100 GPS receiver attached.
Terje
>
> You might consider using broadcast or multicast modes.
--
-
"almost all programming can be viewed as an exercise in caching"
-
Re: Enterprise NTP Architecture
Thank you all for your answers. For FreeBSD, I know it would be cheap
but :
- we don't need a high time accuracy.
- we need to take into account the corporate environment (who manages
the server ? what about the maintenance (soft and hard) ? who patches
it ? etc)
- we need to keep the network as homogeous as possible.
/David
-
Re: Enterprise NTP Architecture
Once upon a time, Terje Mathisen said:
>Richard B. Gilbert wrote:
>> Routers do not make the best clocks! They are highly specialized
>> devices with a great deal of work to do.
>
>Seconded.
>>
>> Do you have an old X86 server that's not quite good enough any longer?
>> NTP is not terribly demanding and an old server running Linux would make
>> a very good time server.
>
>FreeBSD is exactly the same cost, but makes for even better startum 1
>servers, i.e. with a $100 GPS receiver attached.
What about routers that run FreeBSD (e.g. Juniper)? :-) Oops, no
attached clock until you get to the big Junipers (who need it for SONET
timing).
--
Chris Adams
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
-
Re: Enterprise NTP Architecture
> What about routers that run FreeBSD (e.g. Juniper)? :-) *Oops, no
> attached clock until you get to the big Junipers (who need it for SONET
> timing).
I know Juniper routers are FreeBSD. I think you misunderstood me, it
was not an attack on *BSD. I's just that I need to keep my network
homogeneous. Indeed, people who manage the machines don't know BSD. We
have chosen to focus on Win32/64, AIX and Linux platforms, in addition
to the specific network equipments. I have nothing against FreeBSD.
/david
-
Re: Enterprise NTP Architecture
david.gouranton@gmail.com wrote:
> Thank you all for your answers. For FreeBSD, I know it would be cheap
> but :
> - we don't need a high time accuracy.
In which case any Linux server will do just fine.
> - we need to take into account the corporate environment (who manages
> the server ? what about the maintenance (soft and hard) ? who patches
> it ? etc)
> - we need to keep the network as homogeous as possible.
For my corporate network I set up a total of 6 servers, two in each of
our three main locations.
I let every client machine (mostly unix and Win* servers but also some
end-user boxes) connect to all six servers, since they can easily handle
10-100 K client machines each.
Average load from 100K clients on a single server would be 100K
request/reply packets every 64 seconds, or about 1500 request/second.
Since each packet is very short, this is on the order of 1 Mbit/s, i.e.
any PC produced within the last 10-15 years can handle this without
breaking a sweat.
The above was for worst-case loads, i.e. after a full reset of all
clients at the same time. A more normal/average load is 1/8 of this,
with each client sending a request every 512 seconds.
Terje
--
-
"almost all programming can be viewed as an exercise in caching"
-
Re: Enterprise NTP Architecture
On Tue, 30 Sep 2008 08:29:15 -0500, Chris Adams wrote:
>
> What about routers that run FreeBSD (e.g. Juniper)? :-) Oops, no
> attached clock until you get to the big Junipers (who need it for SONET
> timing).
>
Do anyone have knowlegde about external timing would be used to dicipline
ntp on Juniper M320.
/hjj
-
Re: Enterprise NTP Architecture
>>> In article <7b69d111-18f7-47f4-a7a2-e8eb8e523959@i76g2000hsf.googlegroups.com>, david.gouranton@gmail.com writes:
david> Thank you all for your answers. For FreeBSD, I know it would be cheap
david> but:
david> - we don't need a high time accuracy.
What tools are you looking at that will give you less accuracy and less
work?
This is a serious question.
More to the point, what are the cost differences between an NTP solution and
whatever else you are considering?
david> - we need to take into account the corporate environment (who manages
david> the server ? what about the maintenance (soft and hard) ? who patches
david> it ? etc)
This could be really trivial - it is entirely reasonable to use a few
soekris boxes (for example) and turn them in to NTP servers and just forget
about them until somebody decides to see if there is reason to look at them.
You could also buy a commercial NTP appliance and get vendor support.
david> - we need to keep the network as homogeous as possible.
OK, so this will either be case of "we're gonna use what we have already" or
"we get sufficient benefit from using NTP on an FOO server that we'll use
that instead."
--
Harlan Stenn
http://ntpforum.isc.org - be a member!