Configuring a Cisco IOS device (router/switch) is probably one of the easiest things that you can do. But there is a little homework you should to do make sure you implement a NTP configuration that will perform well.
Define your NTP Strategy
Before you start, you need to determine your NTP strategy.
The ultimate goal is that all of the devices in your network should be using NTP to set their clock. But you do not want all of your devices going outside of your network to synchronize their time. This creates extra traffic on your links to the Internet as well as puts extra load on the NTP servers that you are pointing at.
The most efficient way to handle this is to chose 2-4 devices in your network that will act as your primary NTP servers. These are the devices that will go out to the Internet to set their clocks. These are the devices that all of your other internal devices will set their time off of. In a simple network, the IOS routers that are connecting you to the Internet might make the most sense to use as these primary NTP clocks in your network.
I like to configure four public NTP servers in these routers to sync against. I also like to choose four servers that are geographically distributed to mix it up a bit. This should give your device the best chance of finding the most reliable NTP clock to synchronize against.
Here is a sample configuration:
LabRouter(config)#ntp server 132.163.97.1
LabRouter(config)#ntp server 128.138.140.44
LabRouter(config)#ntp server 132.163.96.1
LabRouter(config)#ntp server 129.6.15.28How do you know what servers to use? Read the What NTP servers should I point my network devices at? section below.
Once you configure the four servers, take a look at how your router is doing with the NTP associations. It may take a few minutes for all of the NTP peers to synchronize.
LabRouter#sh ntp associations
address ref clock st when poll reach delay offset disp
+~132.163.97.1 .NIST. 1 33 64 377 36.3 -24.89 1.2
-~128.138.140.44 .NIST. 1 175 64 204 36.7 -30.87 876.0
+~132.163.96.1 .NIST. 1 28 64 377 39.7 -23.22 1.2
*~129.6.15.28 .NIST. 1 41 64 377 43.3 -25.86 0.7
* master (synced), # master (unsynced), + selected, - candidate, ~ configuredThis output shows that 129.6.15.28 is the master or synchronized clock. This is the NTP peer that your device is currently syncing with. This is indicated by the “*” in front of the address. The other peers will still continue to be consulted. But your router will synchronize with the peer that has the least dispersion. Dispersion is the maximum amount of different in the difference in times each time your device checks in with this peer. A lower number means that there is very little difference or variance each time you check in.
The other three peers are still there as backup if for some reason your master NTP peer were to go away.
Once your router has synchronized with an external NTP server (as a NTP Client), as well as it is now a NTP server itself for your internal network for other internal devices to synchronize against. This one ntp server command is what enables both this NTP client mode as well as NTP server mode.
You can check to see if you clock has now been updated by NTP. The show clock detail command will tell you the current time and show you what has been used to set the clock.
With NTP:
LabRouter#show clock detail
21:12:15.754 UTC Sun Apr 4 2020
Time source is NTPWithout NTP:
Router>sh clock detail
*0:0:19.61 UTC Mon Mar 1 1993
Time source is hardware calendarConfigure Other Devices
Now it is time to configure all your other devices (routers/switches/access-points/etc) to synchronize off the new internal NTP servers on your network. Make sure that you configure all of the new NTP servers you have setup in these other devices. That will make sure they have reliable and redundant servers in the event something should happen to one of them.
Don’t forget to set your servers and workstations to also point at these new internal NTP servers that you have set up.
That is it! You should now have a resilient NTP infrastructure that will ensure that all of your devices have synchronized time.
What NTP servers should I point my network devices at?
NIST Servers
A list of public NTP servers can be found on the NIST Internet Time Servers page. These are the official NTP servers maintained by the National Institute of Standards. I strongly recommend using the NIST NTP servers as they are reliable and change very infrequently.
I will generally pick four different servers from different parts of the country from that list.
LabRouter(config)#ntp server time-a-g.nist.gov
LabRouter(config)#ntp server time-a-wwv.nist.gov
LabRouter(config)#ntp server time-a-b.nist.gov
LabRouter(config)#ntp server utcnist.colorado.eduYou can enter these by either their DNS name (if you have an ip name-server x.x.x.x configured in your router) or by their IP address. If you use the DNS name the router will use DNS to resolve the name to and IP address and then store that IP address in the actual running configuration.
LabRouter(config)#ntp server time-a-g.nist.gov
Translating "time-a-g.nist.gov"...domain server (192.168.1.253) [OK]
LabRouter(config)#ntp server time-a-wwv.nist.gov
Translating "time-a-wwv.nist.gov"...domain server (192.168.1.253) [OK]
LabRouter(config)#ntp server time-a-b.nist.gov
Translating "time-a-b.nist.gov"...domain server (192.168.1.253) [OK]
LabRouter(config)#ntp server utcnist.colorado.edu
Translating "utcnist.colorado.edu"...domain server (192.168.1.253) [OK]
LabRouter#show running-configuration
...
ntp server 132.163.97.1
ntp server 128.138.140.44
ntp server 132.163.96.1
ntp server 129.6.15.28ntp.org NTP Pool Project
Another popular set of NTP servers is to use the NTP.ORG pool servers that are listed at on the NTP Pool Project website. One challenge with using these servers and they work best when you use their DNS names vs IP addresses. The project uses a DNS round-robin system to distribute the load to many different servers in the pool.
LabRouter(config)#ntp server 0.pool.ntp.org
LabRouter(config)#ntp server 1.pool.ntp.org
LabRouter(config)#ntp server 2.pool.ntp.org
LabRouter(config)#ntp server 3.pool.ntp.orgThe trouble with this configuration is that when you enter each of those configuration commands, the router will do a DNS lookup on the name and the enter the command into the running-config as an IP address. This will result in a final configuration that looks like this:
LabRouter(config)#ntp server 0.pool.ntp.org
Translating "0.pool.ntp.org"...domain server (192.168.1.253) [OK]
LabRouter(config)#ntp server 1.pool.ntp.org
Translating "1.pool.ntp.org"...domain server (192.168.1.253) [OK]
LabRouter(config)#ntp server 2.pool.ntp.org
Translating "2.pool.ntp.org"...domain server (192.168.1.253) [OK]
LabRouter(config)#ntp server 3.pool.ntp.org
Translating "3.pool.ntp.org"...domain server (192.168.1.253) [OK]
LabRouter#show running-configuration
...
ntp server 199.102.46.78
ntp server 162.159.200.1
ntp server 216.218.254.202
ntp server 12.167.151.1The issue that arises is that if any of these servers are taking down for some reason (which happens fairly frequently as these are all volunteer servers that are in the pool), your router will start to lose NTP peers.
For this reason, as I mentioned above, I strongly recommend pointing at the NIST time servers.
What is the ntp master command used for?
There is some confusion out there regarding the ntp master command.
LabRouter(config)#ntp master 1This command configures this router as an NTP server, but it will use it’s own internal clock as the clock source. The number “1” in the command is what can be used to set what stratum the server will identify as.
This really defeats the whole purpose of NTP as it will be almost impossible for you to keep this clock accurate, especially after an unexpected power outage/reload.
Leave a Reply