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.
As everybody knows, console cables and their corresponding interfaces are a scourge on a network administrators existence. They are always too short, COM-ports get renumbered, Baud-rates are unknown, etc. By their very nature, you also have to be physically present in the vicinity of the box you’re trying to configure. Today we’re going to change all that, by constructing a wireless console cable adaptor with almost infinite range.
I can almost here people shouting something about SSH and Telnet to their screens, as well as something about the Airconsole. First and foremost, telnet and SSH are both wonderful, after you’ve configured the device, but for initial setup, they sadly can’t be used. Airconsole is quite nice, and I use it almost daily, but it’s useful when you want to sit somewhere comfortable when configuring a device in the same room as you, not so much when you want to be comfortable on a beach half a world away from the offending device.
This we’re going to change today, with one device, the B+B SmartFlex router.
If you haven’t noticed already, I have something of a thing for everything time synchronization related. “Proper”, exact time is something that I find important, it’s probably OCD related.
As a part of my day job, I manage a quite large network, with hundreds of different devices. And all of these require some method to synchronize their clocks. Anyone who has at some point tried to diagnose a network problem knows how absolutely critical it is to have proper time available at the devices, so that you for example have any chance to compare logs etc.
The 2920 series switches from HPE/Aruba has a special feature that no other switches in the old ProCurve/E-Series line-up has; dedicated stacking interfaces. On other HPE switches, stacking merely facilitates “simplified” management, by allowing you to manage any switch in the stack from the stack commander’s CLI. On the 2920 series however, you can use dedicated stacking interfacing, giving you 2 20 Gbps links to other switches in the stack and merging two to four switches into one coherent switch. This is quite similar on how stacking works on some Cisco models, but the specialized stacking interfaces gives you higher speeds between the members. In this article, I’ll show you have to set up the commander switch and how to add switches to the stack once it’s created. I’ll also go into how it affects the configuration of the switches, which is quite crucial if you want to stack switches that are already in production.
If you’re anything like me, you like to get things up and running fast. And this means doing a bare minimum configuration of a new switch so you can get to testing connectivity as soon as possible.
So, what do you do? You boot the switch, give it a hostname and a some basic security settings, and then you configure the management VLAN and give it an IP address. After that you configure the trunk interface and try pinging the switch from another device. And everything fails. And you tear out your hair trying to figure out what’s wrong. And finally, after what feels like a lifetime (in reality about 2 minutes), you try pinging something else in the network from the new switch. And it works perfectly.
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)
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).