By Andreja Jarc.
If you’re thinking of building your own NTP pool within your middle or large sized company, and if you are concerned about the safety and availability of time service in the network, you may consider a cluster setup with your NTP servers.
In one of our previous posts we discussed different approaches of redundancy in an NTP network and you are always welcome to have a glance at, yet this time our focus will be set particularly on how to build up and configure a cluster with Meinberg LANTIME servers for your LAN or WAN architecture.
Cluster mode is a specific way of operation which involves multiple NTP servers in a kind of a cloud. By means of a special algorithm they decide which of them has the best performance parameters and therefore starts to act as the current MASTER in the network. All the others reconfigure into a “slave” mode and they keep exchanging parameters until one of them may become the next master if it outplays the current one. May the current master lose synchronization to a reference or its power fails for example, other servers rearrange immediately and choose the next master. Exactly by this self-healing mechanism, sync clients do not get affected by faults on the server side (Figure 1).
Figure 1: Four Meinberg LANTIME servers join in a cluster. All are assigned to a common IP address by which the current master supplies NTP clients in the same subnet.
The MASTER server is chosen according to parameters in the following order:
- NTP status (sync, not sync);
- Priority (user configurable, the lower value the higher priority, default value is 0. See cluster configuration in Figure 2);
- Ref Clock Type (GNSS receiver has the highest rating, other (e.g. long wave DCF77 /PZF, MSF, WWVB or MRS- Multi Reference Source) receivers follow;
- Ref Clock Status (sync, not sync).
All else equal, the lowest MAC address succeeds against its closest server opponent.
In addition to the third attribute the Ref Clock Type, also a quality of the current reference signal plays a deciding role in the voting algorithm. For example if you have a selection of available reference signals as given below, then the voting algorithm picks in the following order:
- GPS / GNSS signal. PPS and 10MHz are at the same quality level as the GNSS reference signal.
- PZF (Long wave reference signal).
- IRIG DC or AM or any other Time Code input signal.
- NTP.
For a fully functional cluster operation two Meiberg LANTIME servers are sufficient. However, if there are at least three servers joint in a cluster, a falseticker detection and its handling is supported automatically.
Here is an explanation why. Let’s assume we only have two, it is not possible to decide objectively which is better since a reference between them is missing. In case there are three, the two with closer quality parameters will vote over the third one. That said it is unfortunately unavoidable to detect a false negative if one server is obviously more accurate than the other two; thus it may be improperly excluded from the further voting campaign. To be on the safe side it is recommended to use in total 4 cluster servers; to detect an outlier robustly and if one of servers is completely out of operation, time accuracy among the rest three can still be compared.
Let me explain you shortly how a falseticker detection works. There is a falseticker limit defined within a cluster, which is set to 500 ms. If one of cluster servers shows a time difference higher than the falseticker limit (compared with the rest of cluster servers), this server will be discarded from the voting algorithm and pronounced as a falseticker. A detection of the falseticker will trigger an alarm which you can capture via different notification channels (e.g. as an SNMP trap). The rest of the cluster servers they will participate in the voting algorithm which selects the current master.
In a cluster mode servers are assigned to a common IP address by which the current master replies to time requests of sync clients. This mode is particularly favored by the SNTP/NTP clients who are not capable to choose between different time servers (e.g. Windows DC domains) since they can only be entered one server IP address at a time, yet they still demand redundancy in servers.
Referring to Meinberg LANTIME models, a cluster can be built with servers operating with V5 or more recent versions of firmware. In case you have time servers with older firmware versions, it is recommended to upgrade them all to the latest version.
Figure 2: LANTIME 1 (left) and LANTIME 2 (right), respectively. In this example, the Cluster port configuration is in both servers assigned to LAN 0. It can be observed that the current status of LANTIME 1 is in a listening mode, rearranging from SLAVE to MASTER and of LANTIME 2 is in SLAVE mode. LANTIME 2 shows information: IP and MAC address of the current master.
To set a cluster mode configuration in your LANTIME, first log in to a web interface and continue to the Network menu and select Network Interfaces. In our example we choose Interface 01 assigned to LAN 0 also as a cluster port, both in the same subnet. The Cluster Tag of this interface is selected and filled in with the cluster IP and netmask settings as shown in Figure 2. The same cluster IP configuration should be assigned to all NTP servers in the cluster. If one sets the priority of server n to become a master before others, then its priority value should be left 0 as per the default and the rest should be assigned manually to a higher priority value. Namely, the lower the priority value, the higher are the chances for a server to become the master.
Cluster members communicate by default via multicast status messages. In this case switches and routers must be configured to forward multicast messages.
With the firmware version V6.18 and higher the cluster operation is available in unicast mode as well. The configuration is as follows:
Other server interfaces for example LAN 1, LAN 2, etc. can be configured as usual so that they may supply sync clients in different subnets, for instance.
Figure 3: Meinberg LANTIME Cluster Configuration Example. The current MASTER-SLAVE situation with LANTIME 1 and LANTIME 2, respectively (left). If LANTIME 1 loses its synchronization with a reference signal, LANTIME 2 becomes the new MASTER (right). The active Cluster IP stays unaffected.
Dear Andreja,
Thanks this was very help full. We got the NTP units up and running now in the IT system now.
Br
Didrik
Dear Andreja,
I have a question could you help me?
how can we do redundancy ,with one GPS with two ports ETH01,ETHO1?
Two Ethernet ports could be connected to different subnets, or otherwise different parts of your network. The Ethernet ports would serve NTP based on the same local clock, steered to GPS.
Dear Andreja,
Can you please explain a little more how the clusering works from a client perspeective? The clients do only see a single server IP-address, right? An adddress that is moved when a new master is selected?
Do the clients notice this is anyway? Do they need to notice in anyway that deviates from normal NTP procedures?
Hello Lennart,
yes the clients query time by a single cluster IP no matter which of the servers is currently the master. The IP address stays actually the same through all the time, since all cluster servers have the same cluster IP assigned as one of the virtual interfaces. The switchover (slave-> master) in reality lasts about 30s, therefore the clients which query time more frequently than that, they would notice some dropped packets, but for others NTP runs smoothly further. However, the MAC address of the master changes though.
Andreja, yet another question.
Let’s say I have a cluster of two servers with IP adresses I1 and I2 respektively, and that I use the adress I3 for the master address, i.e. the address that is moved between servers as the master Changes. Address I3 is of course also the address all clients use when addressing the master.
My question is, are the adresses I1 and I2 still usable.?
Hello Lennart,
yes, the clients can query by all 3 IP addresses at the same time, however if for example I1 and I3 belong to the same server since this is the master, they will receive the same timing information from both IPs.
Hello Andreja,
I would like to setup a cluster between two M1000’s on 6.18 code however the devices are connected to two separate networks and therefore 2 separate subnets in two different states on the west coast. Layer 3 connectivity between the two sites exists, however the use of a common IP will not be possible here for obvious reasons. Is there a way to setup a cluster without the use of a common way? Or is there another method that can be used?
Thanks!
Hello Nabeel,
for a cluster to function properly, the LANTIME server interfaces need to be configured in the same subnet as the cluster IP. In general all V6 fw running LANTIME servers support the cluster function.
You can use either multicast or unicast communication mode between the cluster servers.
I hope this information helps.
BR, Andreja
Hello,
is there possibility to do not use cluster mode (with VIP IP), but somehow synchronize two servers to receive most accurate time ?
Hello Slaw!
The idea behind the cluster is the redundancy between two or three servers for the case that one of severs fails (power down, antenna faulty), or is not available (link down). The servers do not synchronize as peers if this is what you may think.
In general they are all sync to GNSS or long wave signal and do not need peering among them.
Hello Slaw,
you can use any other signal generated by a LANTIME to synchronize other servers, e.g. PTP or IRIG.
Is this what you are looking for?
Regards,
Andreja
Hello Andreja!
Thank you for all the useful and interesting information you have published in this forum! Regarding the NTP cluster method, will it mitigate the risk of GNSS vulnerabilities (jamming, spoofing, signal replay, etc.) if all the NTP servers are GNSS-based? Could one or more of the NTP servers in a cluster be a Linux or Windows NTP server that can act as a master in case of a major GNSS incident? Or could a LANTIME M900 with a rubidium oscillator be used for this purpose?
Thanks!
Best regards;
Are K.
Hello Are! Thanks for your interest in our blog postings and your valuable feedback.
Well, indeed our cluster algorithm itself has a falseticker recognition. A falsticker is a NTP server which delivers its time, that is statistically seen further away from the rest of the servers in a cluster. For a falseticker detection to function properly you need at least 3 servers. In this case the falseticker would be kept out from the voting algorithm which determines the current master. However, the limit for a falseticker recognition is set rather loose, therefore it can take some time before the manipulated server is detected by this way.
As you mentioned yourself, a better way to detect a potential GNSS vulnerability is to use a rubidium oscillator as a backup source.
Another thing to mention. The cluster operation mode works only with Meinberg LANTIME V6 servers. It is namely a proprietary Meinberg voting algorithm.
I hope this information helps.
Kind regards,
Andreja
Hello Andreja,
is it possible to have the cluster IP configured on the same network physical interfaces running the non-clustered IP? The Q/A above indicates the NTP server can be accessed by cluster and non-cluster IP at the same time but I’m not sure about the physical interconnection.
Hello Petr,
the cluster and the non-cluster IP need to be configured on the same physical interface and in the same subnet. However, at each physical port you can assign many virtual interfaces with corresponding cluster IP.
I have two M3000 servers on my network and I Have 24 subnets connected directly to each server and all the subnets are connected to 2 routers this is what is called an FTE network. I am trying to create redundancy between the two of them is there a way to connect two of them together or do I have to create cluster between each subnet.
Hello Merih,
a cluster on each subnet should work. The other way of redundancy is when NTP clients in a subnet poll the time from both servers in parallel and synchronize to one of them. The other server is used for backup.
Thank you for your help.
Hi, When we deploy a cluster in two site with a layer 2 back to back for the ha.
What’s happened when the back to back link was down but the two lantime server was up. which one will be the master ? and when one of them was down during the time that the B2B still down.
thx for your answer
Hello Djibou,
thanks for your question. If a layer 2 link between cluster servers fails, the non-active server sends a ping request to the cluster IP. In case that the target host responds, the non-active server won’t set the cluster IP. And if the ping doesn’t get responded, then the non-active server sets the cluster IP and is ready to send out the time information.
However, instead of multicast you can configure unicast communication between cluster servers to avoid ambiguity with cluster IPs.
Hello I have 2 server ntp lantime M200 is I 2 switch federator good I would like to know is what I can use just the command
#ntp srver @IP from Lantime
Dear Oussama,
if your switch feeder supports standard NTP from ntp.org then you can use a command:
ntpdate ip-addr-of-the-lantime
otherwise check the documentation for your device.
Regards,
Andreja
I just wanted to know what will be IP address of other NTP server under unicast mode. Is it LAN0 IP address of 2nd server.
Once cluster is configure with IP address X.X..X.1, this same IP address we need to configure in switch side as NTP. Please advice
Hello Sir,
yes, you are correct. In the unicast mode you need to list manually all IPs of NTP servers which are included in the cluster (e.g. LAN0 IPs).
A cluster IP is a virtual one and is the same IP for all cluster servers, yes.
Does M100 also support this type of redundancy?
Yes, the cluster feature is supported by all LANTIME models and SyncFire models
How can I manually failover from one TS to the other in a cluster, as we have two servers. Is it possible to do the manual failover without powering off the current primary?
Hey Awais Ahmad,
You can force a failover by changing the cluster priority via the web interface. Lower is better 🙂
We are using two number of M300 for NTP Time Synchronization in our projects on PRP Network.
The client have configuration for two NTP Servers (Main & Backup NTP Server)
Customer is asking us to configure Master / Slave configuration,
so that in case if one time quality is not good, the second GPS Start Synchronizing the equipment.
Can you please confirm, if we can adopt the Cluster configuration on PRP Network?
We will appreciate, if you can share the recommended settings to setup the M300.
Also can you please describe the testing procedure, so that we can test the functionality.
Hello Farhan,
Yes, the NTP Cluster functionality can also be used on PRP interfaces. The PRP driver will take care of duplicating/dropping the network frames.
You can simply follow the instruction above to set up the cluster on your device, just select the PRP interface and everything will be good to go 🙂
Hello,
can we use the Cluster function with to M250? They have only one Ethernet-Interface.
In this article you user 2 Ethernet-Interfaces.
Hey Thomas,
Yes, you can also use the NTP cluster functionality if your device just has a single network interface like a LANTIME M250.
Your cluster configuration will be added to the existing interface configuration.
Hi,
we have 2 datacenters in 2 different locations
We would like two M320 . one for each datacenter.
What is de best practice to setup a cluster. all members in both datacenters wel look at one NTP adres (dns name)
And do we need an external antenna DCF77 .
MvD
Hi Martijn,
The interface IP addresses of your 2 x M320 and the cluster IP all have to be on the same subnet.
If you are interested in a M320 units with DCF77 receiver, you have to connect an external DCF77 antenna in order to synchronize the units. But our devices can also be purchased with a GPS receiver f.e. There are many options available. If you need further help, just open a support ticket by sending an email to techsupport@meinberg.de