Virtualizing NTP servers has been quite a hot topic for some time, but regardless of what some people say, you can actually virtualize NTP servers, as long as you know what you’re doing. If you examine some public NTP servers more closely, you’ll actually find that a lot of them are running on AWS, which should attest to virtualizing being a possible route to go down.
There’s some things though that you might want to consider before going down this route, and some special configurations you need to do to make sure everything works as intended.
This is more for my own reference than anything else, but what follows here is a short tutorial on how to get NTP up and running on your Cisco iOS device.
First we need to get DNS working for the switch to be able to resolve the DNS name for the time server. If you run your own time server you can use the static IP for the NTP server and skip this step, but if you use one of the public NTP pools just resolving the domain name for the pool one time and hard coding that into your switch won’t do it. First of all, that NTP server might go down some time down the line, and then your time synchronization stops working. Secondly, and this is actually a far bigger problem, if you resolve the IP of a NTP pool, you’re actually only using one server in that pool constantly since the pools load balancing is constructed using DNS round robin. This skews the load on the (already heavily loaded) public NTP infrastructure, which isn’t very good. While we’re on the topic, if you are using public NTP servers, consider setting up your own internal NTP servers and have your clients sync to them, thus limiting the load you put on public NTP servers. If you, like me, run your own GPS NTP servers, then you can do as you like (but the DNS round robin trick is also useful to do internal load balancing and fail-over)
This is a short guide on how to set up NTP time synchronisation on HP Network devices. I’ll be covering SNTP settings in this guide, as well as some of the niftier things that aren’t in the manuals but still are really handy. NTP time synchronisation allows you to maintain correct time across your network, which is very important for troubleshooting when comparing logs between two switches for example.
Yesterday my Raspberry Pi arrived, and today I had some time over to set it up and have a first look.
First of all, I don’t see this becoming a desktop machine for anybody, it’s just too slow to be able to even render webpages fast, never mind streaming HD video, at least the Raspbian version, I haven’t tried the media PC oriented distributions yet, but since they almost certainly lack support for Netflix, HBO and the like, I’m not so confident that they will be much better.
Anyhow, where I think the Raspberry Pi will indeed be useful are areas like automation and tasks were you need to interface with the real world. A good example is an low cost stratum 1 NTP server. The Raspberry has more than enough processing power to handle thousands of NTP querys per second, and it’s very easy to interface it with a serial GPS receiver for example.
Another great application would be custom made protocol converters for industry applications, which mostly convert a serial line protocol to something that can be shifted over Ethernet.
I’ll look into the hardware aspects of the Raspberry during the following weeks and get back to you guys with an update. One thing I’d really like to build is a I/O board for it, so we’ll see about that. Or maybe a NTP time server coupled to a big clock of some sort (maybe even the relay clock I’ve been planning to build for years now).