Network Time Protocol (NTP) Tutorial
The Network Time Protocol (NTP) is a crucial service not only for Cisco devices but for most network devices. Any device needs to be accurately synchronized with a reliable time source such as an NTP server.
For networking devices, precise timekeeping is very important because many services depend on it. A common and frequently used example is logging and SNMP.
How NTP Works
NTP uses Client/Server model:
+ NTP Client: periodically contacts an NTP server to request time information
+ NTP Server: responds with its current time, and the client uses this information to adjust its clock.
An NTP server usually queries its time from an authoritative time source, usually a reference clock (for example: radio clock, atomic clock…) and then distributes this time across the network.
NTP uses the concept of a stratum to describe how many NTP hops away a device is from an authoritative time source. A reference clock is a stratum 0 device that is assumed to be accurate and has little or no delay associated with it. Stratum 0 servers cannot be used on the network but they are directly connected to computers which then operate as stratum 1 servers. A stratum 1 time server acts as a primary network time standard.
A stratum 2 server is connected to the stratum 1 server; then a stratum 3 server is connected to the stratum 2 server and so on. A stratum 2 server gets its time via NTP packet requests from a stratum 1 server. A stratum 3 server gets its time via NTP packet requests from a stratum-2 server… A stratum server may also peer with other stratum servers at the same level to provide more stable and robust time for all devices in the peer group (for example a stratum 2 server can peer with other stratum 2 servers).
NTP uses the Multicast address 224.0.1.1 and UDP port 123 as both the source and destination.
Configuration
– To configure a Cisco device as an Authoritative NTP Server, which uses its own clock to offer time to others, use the ntp master [stratum] command. An Authoritative NTP Server can distribute time even when it is not synchronized to an existing time server.
Device(config)#ntp master
– To configure the local device as a NTP client and use a remote NTP clock source, use the command ntp server {IP address}. For example:
Device(config)#ntp server 192.168.1.1 //get time from a NTP server at 192.168.1.1
Note: The “ntp server” command configures the local device as an NTP client, not an NTP server.
Two above commands (“ntp master” and “ntp server”) can be used simultaneously for redundancy. In this case the device will act as an NTP client (with the “ntp server” command) and fall back to its own clock (with the “ntp master” command) if the connection fails. Therefore it always offers time no matter which source it uses.
Finally, if we want our device act as both NTP server and NTP client, we can use the ntp peer {address | hostname} command. This mode is called “symmetric active mode”. For example:
Device(config)#ntp peer 192.168.10.1
Let’s take an example to understand about this command. Suppose:
+ R1 is an NTP client and get time from NTP Server 1
+ R2 is an NTP client and get time from NTP Server 2
R1 and R2 can communicate to each other so R1 & R2 may want to receive time from each other as backup when their primary NTP server fails. In this case, the best solution is to configure R1 & R2 the NTP peer of each other.
On R1: R1(config)#ntp server 192.168.1.1 //use NTP Server 1 as its main NTP source R1(config)#ntp peer 192.168.2.2 //use R2 as its NTP peer (synchronize) On R2: R2(config)#ntp server 192.168.2.1 //use NTP Server 2 as its main NTP source R2(config)#ntp peer 192.168.1.2 //use R1 as its NTP peer (synchronize)
With this configuration, R1 prefers using NTP Server 1 and use R2 as its backup source. R2 prefers using NTP Server 2 and use R2 as its backup source as well. Therefore we can see an NTP peer can be both source and client of each other.
Time & NTP Verification
Two most popular commands to display time sources statistics: show ntp status and show ntp associations
+ show ntp status: display the current NTP status of the local device
R1#show ntp status Clock is synchronized, stratum 10, reference is 10.1.2.1 nominal freq is 250.0000 Hz, actual freq is 249.9987 Hz, precision is 2**18 reference time is D5E492E9.98ACB4CF (13:00:25.596 CST Wed Jul 17 2024) clock offset is 15.4356 msec, root delay is 52.17 msec root dispersion is 67.61 msec, peer dispersion is 28.12 msec
The router tells us that we are synchronized with stratum 10 and the reference clock is at 10.1.2.1.
Another example:
R1# show ntp status Clock is unsynchronized, stratum 16, no reference clock nominal freq is 250.0000 Hz, actual freq is 250.0006 Hz, precision is 2**24 reference time is 00000000.00000000 (02:00:00.000 Greece Mon Jan 1 1900) clock offset is 0.0000 msec, root delay is 0.00 msec root dispersion is 0.00 msec, peer dispersion is 0.00 msec loopfilter state is 'FSET' (Drift set from file), drift is -0.000002405 s/s system poll interval is 64, never updated.
This output tells us our router is not synchronized so the stratum is 16 (the upper limit for stratum is 15)
+ show ntp associations: show NTP servers to which the client is connected
CoreRouter#show ntp associations address ref clock st when poll reach delay offset disp *~146.185.130.223 193.79.237.14 2 26 64 1 10.857 -5.595 7937.5 * sys.peer, # selected, + candidate, - outlyer, x falseticker, ~ configured
The output of this command shows that our device is configured (~) to synchronized with our selected NTP server 146.185.130.223, however, it is synchronized with the star (*) symbol in front of the tilde (~). The ‘ref. clock’ column shows the IP address of the NTP server from which our device is synchronized.
The * in front of the IP address tells us that we have synchronized and the stratum (st) is 2. That means the NTP server is pretty close to a reliable time source. The “poll” field tells us we will try synchronizing the time every 64 seconds.
Another example:
Router# show ntp associations address ref clock st when poll reach delay offset disp ~129.6.15.28 .INIT. 16 - 64 0 0.000 0.000 16000. ~206.246.122.250 .INIT. 16 - 64 0 0.000 0.000 16000. * sys.peer, # selected, + candidate, - outlyer, x falseticker, ~ configured
From the output above, we can see both of our NTP servers are in the “INIT” state. NTP is very slow compared to other protocols. It can take upwards of five minutes to synchronize with an upstream server.
Finally, if we want to check the current date and time on our device, use the “show clock” command:
Router# show clock *06:58:34.345 UTC Wed Jul 24 2024
NTP Authentication
– The ntp authenticate command is used to enable the NTP authentication feature (NTP authentication is disabled by default).
– The ntp trusted-key command specifies one or more keys that a time source must provide in its NTP packets in order for the device to synchronize to it. This command provides protection against accidentally synchronizing the device to a time source that is not trusted.
– The ntp authentication-key defines the authentication keys. The device does not synchronize to a time source unless the source has one of these authentication keys and the key number is specified by the ntp trusted-key number command.
