Network Time Protocol, otherwise known as NTP, is designed to synchronize the clocks of computers over the network.
NTP first came into this world in 1985, making it one of oldest internet protocols still in use today. There are alternatives to NTP that have been developed and utilized over the years, but as a testament to the protocol’s robustness, it still is in use today and supported by many operating systems, networking equipment, and connected devices.
The NTP protocol we know and use today is either version 3 or 4 and utilizes a latency compensation algorithm to set clocks within milliseconds of each other. The algorithm works so well that millisecond clock alignment can be achieved even over the internet.
When working with NTP, it is important to be familiar with the concept of stratum.
pool.ntp.org?Note: Concerning large networks, like with any services, NTP should be planned out. At least one, preferably two, stratum 1 servers should be implemented.
References:
I cannot overstress the importance of time synchronization, not only for networking devices, but for servers and client computers as well.
Most servers and client computers implement what is known as a real-time clock (RTC), which is usually backed by a battery or capacitor so that it can retain the correct time when powered off or rebooted. Sadly, there are devices and servers/client computers that have dead RTC batteries or no RTC at all. These devices usually require a time source to synchronize to if utilize time in anyway.
Beyond just the compelling reason to keep the right time on all devices and computers, it really is important when dealing with multiple devices and troubleshooting events on the network. For example, if you are investigating a security incident, having all the devices time-synced means the logs are in alignment, and it makes it easier to correlate events across the network, servers, and applications.
Time plays a role in more things in modern computing that most people who are even technical are not aware of. From the application level all the way down to the network, time being accurate is important to the stable functioning of the system as a whole.
There are many options today when it comes to NTP servers. Depending on the device and IOS XE feature set, even a switch or router can be an NTP server.
As said before, even switches and routers have the ability to be NTP servers. The question is, should they be? That depends on the size of the network, switch, and router CPU load and time accuracy needs. The reality is that modern operating systems either have native NTP server capabilities, installable open-source NTP servers, or commercially available implementations.
There are a few implementations available:
We will not go into the full design and implementation of network time services here because that would be a whole subject matter better covered independently.
References:
Depending on the device hardware, version, and the software feature sets of IOS XE, the implementation detail may differ from what is outlined here.
ntp server 192.168.1.11
ntp server 192.168.1.21 prefer
This is an example of a basic configuration for IOS XE that supports NTP. Here, we have defined two NTP servers, 192.168.1.11 and 192.168.1.21, the latter of which is marked as prefer, which means it will be used first unless unavailable. If the preferred server is unavailable, then the remaining list of servers will be utilized.
sw0#show ntp status
Clock is synchronized, stratum 4, reference is 192.168.1.21
nominal freq is 286.1023 Hz, actual freq is 286.0884 Hz, precision is 2**20
ntp uptime is 735914300 (1/100 of seconds), resolution is 3496
reference time is E70ABB45.470BF553 (17:23:17.277 EDT Mon Oct 31 2022)
clock offset is 3.1642 msec, root delay is 40.99 msec
root dispersion is 47.81 msec, peer dispersion is 2.24 msec
loopfilter state is 'CTRL' (Normal Controlled Loop), drift is 0.000048527 s/s
system poll interval is 512, last update was 1573 sec ago.
Once NTP is configured, we should check that it is working. By using the show command for ntp status, we can see that the switch is synchronized with server 192.168.1.21. We also can see a lot of particular details, including the stratum number for the device NTP server, the clock offset, and more.
sw0#show ntp associations
address ref clock st when poll reach delay offset disp
+~192.168.1.11 68.87.66.59 3 45 512 377 0.909 3.948 0.079
*~192.168.1.21 68.87.66.58 3 239 512 377 0.901 3.164 0.144
* sys.peer, # selected, + candidate, - outlyer, x falseticker, ~ configured
Another command worth mentioning—and really is the command I use to confirm NTP is working—is the show command for ntp associations. As you can see from the output above, we have the two NTP servers along with the stratum number st, offset, delay, and more displayed. This allows you to determine pretty quickly if NTP has synced the clocks and from where, but it also shows you information about all the servers instead of the previous show command for ntp status.
Reference: Verifying NTP Status with the show ntp associations Command
On some platforms, the example here being an autonomous Wi-Fi access point, NTP is not available. Typically in these cases, Simple Network Time Protocol (SNTP) implementation will be available.
SNTP is just a simpler implementation of NTP on a few levels, from the simplified algorithm for time synchronization to the limitation that only one NTP server can be utilized at a time. SNTP typically will be used where the CPU is a premium, like embedded devices, access points, etc.
sntp server 192.168.1.11
sntp server 192.168.1.21
This example is configuring SNTP with two servers. It must be noted that while there are two NTP servers defined, the SNTP service on the device will only use one at a time. If one that it is using becomes unavailable, then the SNTP service will attempt the other listed NTP servers and then connect to the first working server from the remaining NTP servers.
ap0#show sntp
SNTP server Stratum Version Last Received
192.168.66.11 3 4 00:20:32
192.168.66.21 3 4 00:00:44 Synced
Once configured, the status of the device’s SNTP service can be checked using the show command for sntp. As you can see in the output, the two configured servers are displayed, but unlike the previous NTP examples, this one is simpler, showing only the server, stratum number, version, the last time the server was contacted, and finally, which server the SNTP service is using to synchronize time.
Hopefully, after going through this tutorial, you have a basic understanding of why time synchronization is important, potentially which server implementations will work for your situation, and a basic understanding of how to configure IOS XE time services.