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)