In case you’re responsible for an enterprise network or data center you should care about NTP. Refer to “Why should I run own NTP Servers?“. As a hobby technician you might first think about Raspberry Pis with self soldered GPS modules. Well, good idea to play with, but not reliable at all. Way to unstable, hard to update, no alerting, no service agreements, and so on.
Hence you should use a dedicated NTP appliance such as the Meinberg LANTIME NTP Time Servers. I am using a LANTIME M200 with a DCF77 correlation receiver in my lab. With this post I am showing how to set up this NTP server, giving some insights, and listing the advantages of such an appliance compared to a Raspberry Pi or any other DIY server approach. My wish list aka feature requests to this product round things up.
The Time Server Specs
Basically the LANTIME M200 is a 19″ based, 1 rack unit high single-purpose NTP server. It is modular and can be used with different reference clock sources such as GPS, Galileo, DCF77, and some other. It is capable of IPv6 and legacy IP for NTP as well as all management protocols such as DNS, HTTPS, SSH, SMTP, Syslog, and SNMP. “A stable and precise oscillator is capable of bridging interferences or a temporary loss of reception”, as listed at the manufacturer: Compact NTP Time Server with integrated Reference Clock. For further technical details you can have a look at the official specs sheets there.
To get an idea I have made some photos of the device:
I measured the power consumption of the LANTIME M200 at 230 V: It consumed about 10 W by 24 VA, which is a 
Initial Operation
This is what I love most about these enterprise NTP servers: They are working out of the box. Of course you need to configure the IP addresses of the device, but the actual functionality, namely: NTP via external reference clocks, is working out of the box. No need to install other tools or to fine-tune configurations. Even more: the initial setup of the IP addresses can be done via the front panel without extra displays, keyboards or serial adapters. Nice.
Anyway, you should carefully read and follow the advises from the official documentation chapter “Security User Guide / Security Advisories“. They give some good hints, such as generating/replacing the TLS certificate, disabling “root” login, using SNMPv3 rather than SNMPv1/2c, and locking the front panel. You should obey those steps to operate your NTP server in a secure manner.
Advantages
Following are some obvious advantages of this Meinberg NTP appliance compared to DIY Raspberry Pi NTP projects:
- Out of the box operation: As already said, your LANTIME works almost out of the box. Basically you only need to configure the IP addresses, change the default login password, and you’re done. Of course you need to set up some other services for proper operation such as DNS, SNMP, Syslog, backup NTP servers, etc., but there is no need to configure the external clock source (in my case: DCF77) in any way. It simply works.
- Highly precise reference clock: I am using the DCF77 radio clock from Germany as the reference clock. While DIY projects are using the normal amplitude modulated signal to get the time, Meinberg uses the phase modulated variant. This dramatically improves the accuracy. Compared to my Raspi DCF77 receiver, whose offset ranges from +/- 1 ms, the offset of the Meinberg M200 with phase modulated DCF77 ranges from +/- 1 µs, which is better by a factor of 1000! (Blogposts about monitoring NTP servers will follow.) Note that you can use some other reference clocks as well, such as GPS, Galileo, GLONASS, MSF, and so on.
- Built-in hardware clock: An NTP server must stay stable for some time even in case of a reference clock failure. Therefore the LANTIME boxes have an oscillator inside that keeps the internal clock stable. There are different oscillator types available such as OCXO, TCXO, Rubidium. Whatever that means. ;) My M200 is shipped with a TCXO.
- GUI: It’s really great to have a dedicated GUI for your use case. In this case we have an NTP server reachable via Ethernet – hence all visible buttons and configuration options are either related to the network settings or to NTP itself. It is really easy to click through all menus in order to have an overview about all possible settings. This is much easier than trying to find your relevant options within text-based configuration files all over the system that don’t list all variables by default.
- Built-in statistics: There are some statistic modules that can be enabled within the GUI such as ntp_counters, ntp_offset, or pzf_stats. These data records offer basic graphs that show the raw values over the last 24 hours. Of course this cannot replace a real monitoring system, but it helps to get an idea in case of failures, rather than looking at text-based logfiles only.
- Front panel w/ display, buttons, and status LEDs: While it is a standard 19″ rack device it has a display, some buttons, and status LEDs. With these you can do the initial config of IP addresses and you’re always informed about its status. Nice. Walking through the data center you can easily see whether the device is in “normal operation” or not.
- Configuration revision: You can save and download (and activate) configurations on the box directly. The configuration archive has all relevant config files inside. That is: Within a single archive you have everything you need. Much easier compared to my Linux config files that are scattered all over the file system.
- Notification/Alerting: This is really important! In case of a failure you need some notifications to take action. There are a couple of built-in services that can catch you, first and foremost: email, syslog, and SNMP trap. But even other options can be used such as “user defined notifications” or an external LED display. Via a detailed table you can configure which event shall trigger which notification type. Furthermore you have an easy overview about all triggered events in the past with timestamps.
- SNMP MIB: Monitoring your services is crucial. Meinberg delivers an own enterprise MIB (download) which enables your monitoring system to poll the most relevant OIDs without the need of custom scripts or the like.
- Firmware updates: Keeping your NTP servers up-to-date is key to get rid of bugs and to limit the security attack surface. While I ran into some issues doing simple upgrades on my Linux NTP servers, Meinberg regularly serves quality assured firmware updates for their devices.
- Documentation & support: While Google is your friend for do-it-yourself projects you get a quite solid and technical documentation from Meinberg concerning their appliances and NTP in general. And of course they have a technical support. That is: In case of real failures you have someone to blame for. ;)
Following are a couple of screenshots from the LANTIME M200, firmware version 6.24.015, an SNMP view through the MIB Browser loaded with the enterprise MIB from Meinberg, and a screenshot of an alerting mail:
My Wish List
However, there are still a few things that I am not completely happy with:
- Outdated GUI: As you might have seen from the screenshots above, the GUI is not “Next-Gen” like. ;) Since I am working with all of those next-generation firewalls in my daily business, I am used to click in well designed GUIs with lots of included functionalities rather than a mere frame-based HTML page. Especially the “System” tab is quite messy since you have to navigate through different menus that are not visible at all, but only after some button clicks.
- Integrated firmware updates: The only way to install a new patch release is to download it from the Meinberg homepage, upload it to the server and “Start Update”. I would like to have a built-in update feature in which the device notifies me about a new update which I can download and install with one click within the box itself, preceding a backup of all configuration files.
- Auto-backup of config files to external storage: I would like to have an automatic transfer of all configuration files to a remote location via SCP, WebDAV or the like. It’s always good to have the most current configuration snapshot saved somewhere else.
- Refid should be “DCFp” and not “PZF”: When using the external time source DCF77 with phase modulated pseudorandom sequence, Meinberg lets the NTP server list a refid of “PZF” which is the German translation of pseudorandom: “Pseudozufall”. This seems to be very Meinberg specific because other instances list “DCFp” which seems more generic. (While DCFa is for the simple amplitude modulation, DCFp identifies the phase modulation.) However, you cannot change this refid on the Meinberg time server.
- Jitter is missing via SNMP: While you can request many OIDs through SNMP such as the offset from the reference clock, you can’t request the jitter. Ok, this is not that crucial, but since I am monitoring the jitter for all of my other NTP servers, I would like to monitor it for the Meinberg as well.
- Documentation links in the GUI: Rather than downloading the manual PDF I would like to have some “help” buttons/links in every configuration tab that directly points to the needed paragraph in the online documentation.
Conclusion
After I made my experiences in installing and operating some Raspberry Pis as stratum 1 NTP servers (1, 2, 3) and all of its problems such as bad radio clock signal, configuration errors, failed updates, and so an, I am really happy with the Meinberg appliance. While my Pis brought me some general Linux and ntp know-how, they are still a hobby project. With the Meinberg device I am now running an NTP service I can rely on.
Well, I think that was expected, since it is a single-purpose device with quite some good reputation. It is operable within minutes, stable in reference clock failures, while it sends me notification mails in case of problems. Fire-and-forget. (Except for regular firmware update, of course.) Well documented. Perfect.
Featured image “View from from Refugio Lagazuoi, Italy” by J. Philipp Krone is licensed under CC BY-NC-ND 2.0.