[ntp:questions] Peering and synching over multiple interfaces and subnets.

Danny Mayer mayer at ntp.isc.org
Tue Jul 3 02:16:17 UTC 2007


ulf.norberg at banverket.se wrote:
>>> Because of all of the different subnets in this SCADA network (not 
>>> just around these servers) it is not possible to have the Stratum-1 
>>> servers reachable on each subnet. The security guys won't allow it.
>> Why not? Don't they have enough work to do? There's no 
>> security reason for this.
> 
> Well, Steve asked me the same question.
> Maybe I used the word subnet wrongly. I should maybe say virtual network
> or even virtual private network (VPN). From now on I will use VPN. 
> The SCADA-system in question has a very strict security policy. It's a
> nationwide system and the Swedish railroad would be in serious trouble
> if the system went down. Therefore any communication between different
> VPN's has to go via a firewall environment. Any other openings or
> potential openings between the different VPN's are strictly prohibited,
> so the 4 Stratum-1 servers that we use today can't be connected to more
> than one VPN at a time.

So put each Stratum-1 in different locations and point the clients at
them. The VPN will take care of routing the packets correctly. I assume
that each location can access the other locations.

> 
>>> Work is in progress to raise all our access routers to Stratum-2 and 
>>> to solve NTP redundancy for clients in need of more than 1 
>> NTP source.
>>
>> You seem to misunderstand. Each system needs to have multiple 
>> servers - 3 or more.  Anything less isn't useful. It's also 
>> useful to have those servers get their own servers from 
>> multiple different sources. If it's only getting from a single 
>> source it is not sufficient unless you don't care about accuracy.
>>
> I hope not.
> Via the management VPN all core routers gets its time from the 4 S1's
> and all access routers either gets their time from at least 4 core
> routers or from the S1's. This was the only way we could find to
> distribute time to all parts of the network and be able to serve all
> VPN's and their respective subnets with NTP without having to go thru
> the firewall environment, which would have been a bottleneck and a
> configuration nightmare.

Aren't all of the S-1 servers accessible via the VPN setup? If not why
not? The firewalls are just gateways, from the VPN's point of view, to
other parts of the VPN.

> In the core part of the SCADA-system the vital interface-servers gets
> their time from 4 access routers (the ones we are about to raise to S2,
> mentioned earlier).
> The several hundred RTU's (Remote Terminal Units) around the country
> uses SNTP (not our choice) and they gets the time on the local LAN's
> from their respective default gateway.
> 
> And yes, I do know that routers aren't optimized to handle general
> services like NTP but for the moment we don't have much of a choice. We
> are looking at upgrading our current S1's to something that has more
> than 1 interface for NTP like Symetricom's new S-200 or Meinberg's M600
> so we can connect them to more than 1 VPN without compromising the
> security scheme. We also want to increase the numbers of S1's but it's
> all about money and acceptance from the management.
> 
>>> It would be allot easier if the NTP protocol was VRF-aware. Something
> 
>>> to work on for version 4.3 ;-)
>>>
>> I have no idea what you mean by VRF.
>>
> Virtual Routing and Forwarding. A technology for creating virtual
> private networks. Best described by Wikipedia.
> http://en.wikipedia.org/wiki/VRF
> According to one of our router gurus it would be possible to let a
> NTP-server serve multiple VPN's without the need of firewalls if the
> NTP-protocol or, if possible, the NTP-servers where VRF aware.
> 

Well that technology is at the IP layer, below the UDP layer that NTP
uses. NTP doesn't care how it received the packet, just that it did so
and contains information for it to use. So NTP will get routed any which
way it needs. You don't need to program anything.

Danny



More information about the questions mailing list