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

ulf.norberg at banverket.se ulf.norberg at banverket.se
Fri Jun 29 06:33:20 UTC 2007


Thanks Danny for your comprehensive explanation.

>I'm not sure where you think you are 
>getting redundancy since the redundancy comes from picking a 
>sufficient number of servers to provide time service to the 
>SCADA systems. You can skip the routers. They don't need to be 
>involved here.

Just to be clear. The redundancy I mention is not really for the NTP. The multiple subnets and interfaces are there to ensure the funtionality of the SCADA-system in case of any communication faliure. The problem for me then, is that our supplier of the SCADA system also wants NTP to use the communication redundancy which result in multiple entries per peering neighbours or upstream servers in the ntp.conf file. That's why I ask about the risk of sync loops or other strange behavior.

I can't skip the routers because they are a part of the NTP solution. 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. Therefore we are using the management subnet for the routers to distribute NTP time to all routers in the network and they can then provide NTP for all the subnets they handle respectively.

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. It would be alot easier if the NTP protocol was VRF-aware. Something to work on for version 4.3 ;-)

Best regards
Uffe



>-----Ursprungligt meddelande-----
>Från: Danny Mayer [mailto:mayer at ntp.isc.org] 
>Skickat: den 29 juni 2007 05:05
>Till: Norberg Ulf, LA
>Kopia: questions at lists.ntp.isc.org
>Ämne: Re: [ntp:questions] Peering and synching over multiple 
>interfaces and subnets.
>
>
>ulf.norberg at banverket.se wrote:
>> Hi all.
>> 
>> I have 2 questions about synching and peering over multiple 
>interfaces 
>> and subnets.
>> 
>> For redundancy reasons our supplier of a SCADA system wants to get 
>> NTP-time over multiple interfaces. The routers act as stratum-3 
>> servers. (they could possibly be raised to stratum-2 if necessary)
>> 
>> Question 1
>> The SCADA servers is serving 4 different subnets with services and 
>> getting it's NTP time from the default gateway on each 
>subnet. These 4 
>> subnets are served by 2 physical routers handling 2 subnets each, so 
>> what the SCADA system believes are 4 routers are actually 2. 
>Is there 
>> any problem asking the same NTP source twice from different subnets?
>> Any risk of synchronisation loops or other strange behaviour?
>
>You won't get loops since those servers aren't synching to 
>each other. They'd need to be on the same subnet to even be an 
>issue in the first place and refid's do a good job of loop 
>prevention if needed. I'm not sure where you think you are 
>getting redundancy since the redundancy comes from picking a 
>sufficient number of servers to provide time service to the 
>SCADA systems. You can skip the routers. They don't need to be 
>involved here.
>
>> Question 2
>> My second question is similar but is about peering.
>> I want to "clean up" the existing NTP-configuration and introduce 
>> peering between the SCADA server because they are mutual 
>dependent on 
>> each other and there's a need to keep their clocks as close to each 
>> other as possible. If I want to peer the SCADA servers with each 
>> other, is it any problem peering them over 2 subnets?
>
>It doesn't matter. You can peer across the other side of the 
>world if you want (though the quality would be poor across 
>such a distance).
>
>> Each SCADA server will then have 2 peering instances per 
>neighbour in 
>> the conf files. Will this cause any strange behaviour in the 
>> NTP-synchronisation?
>> 
>
>No.
>
>> If anyone needs a picture to follow my description above, I can send 
>> it as PDF to anyone willing to help me solve this issues.
>> 
>
>Not necessary.
>
>Danny
>



More information about the questions mailing list