NTP (Network Time Protocol) is used for time synchronization. In a network, it is desirable (and even required for proper functioning) that all network devices use the same time and date. A few seconds difference can already lead to non-functioning for certain protocols.
Cisco devices can act as NTP server themselves. For example, by setting the internal clock to the correct time, a Cisco router can pass the time on to the rest of the network equipment. However, it is of course desirable that this “NTP server” itself also knows the exact time. While the internal clock is fairly accurate, a router’s primary job isn’t keeping time.
There is hardware that has been specially developed to keep accurate time. Several specially equipped servers are publicly accessible for free, such as the NTP Pool Project.
In this example we are going to configure R1 as an NTP client and get the time from the NTP Pool Project.
Since R1 has the exact time after this (it comes from the NTP Pool Project), we also give R1 the role as NTP server so that R2, R3 and R4 can take over R1’s time.
Before synchronizing the time with an NTP server, it is necessary to set the current time and date on a Cisco device as accurately as possible. If the time or date of the Cisco device and the time of the NTP server differ too much, the Cisco device will not accept the time of the NTP server.
To set the time, 2 configurations need to be carried out:
The date and time can be viewed with the command show clock. If the time or date is incorrect, set the time and date with the command clock set hh:mm:ss dd month yyyy from enabled mode.
The time zone (in the case of the Netherlands UTC+1) should be configured as follows:
The name value is for your own reference
The recurring option tells the router to automatically switch between daylight saving time and daylight time.
In this case, on router 1, 2 3 and 4 I set the time zone with the following configuration:
R1#conf t R1(config)#clock timezone NLD 1 *Apr 3 12:50:22.343: %SYS-6-CLOCKUPDATE: System clock has been updated from 12:50:22 UTC Sun Apr 3 2022 to 13:50:22 NLD Sun Apr 3 2022, configured from console by console. R1(config)#clock summer-time NLS recurring *Apr 3 12:50:37.490: %SYS-6-CLOCKUPDATE: System clock has been updated from 13:50:37 NLD Sun Apr 3 2022 to 14:50:37 NLS Sun Apr 3 2022, configured from console by console. R1(config)#end R1#show clock *14:56:50.203 NLS Sun Apr 3 2022
After setting the timezone +1, the time automatically jumps to the Dutch time (UTC + 1). However, because at the time of writing we were in daylight saving time, the time again jumps forward one hour after setting daylight saving time.
A Cisco device can have 2 roles:
In this case, we are going to set R1 as the server. We want him to get the time from the NTP Pool Project, and make himself available as a server to pass this time back to routers 2, 3 and 4.
In this example we are using 2 servers from the NTP Pool Project: 0.pool.ntp.org and 1.pool.ntp.org. We set 0.pool.ntp.org as primary server.
R1(config)#ntp server 0.pool.ntp.org prefer R1(config)#ntp server 1.pool.ntp.org R1(config)#end R1#show ntp associations address ref clock st when poll reach delay offset disp *~126.96.36.199 .PPS. 1 9 64 1 15.290 -0.871 187.53 +~188.8.131.52 184.108.40.206 2 3 64 1 12.472 -0.878 187.53 * sys.peer, # selected, + candidate, - outlyer, x falseticker, ~ configured
Here we see that 0.pool.ntp.org has been translated to IP 220.127.116.11. The asterisk indicates that this server is used as NTP source.
show ntp status shows the status of NTP. In this case, R1 has stratum status 2. Stratum indicates the “exactness” of the time. The source of a time (usually a clock specifically intended for accurate timekeeping, such as a atomic clock) gets stratum 1. Each subsequent source gets one stratum higher.
In this case, 18.104.22.168 has the exact time with stratum 1. So R1 gets stratum 2, and routers 2, 3 and 4 get stratum 3 when they take over the time from R1.
R1#show ntp status Clock is synchronized, stratum 2, reference is 22.214.171.124
Now we have to set up NTP on router 2, 3 and 4 with Router 1 as server. Looking again at the network, we see that we can reach router 1 via 2 interfaces: G0/1 and G0/2.
But suppose we set router’s 1 G0/1 as NTP source on router 2 to 4. What happens if G0/1 fails? Routers 2 to 4 can no longer reach router 1 and can no longer synchronize the time. However, router 1 is still reachable, but under G0/2.
To solve this problem, we can create a loopback interface on router 1, and specify the loopback interface of router 1 as NTP source on routers 2 to 4. Should G0/1 or G0/2 fail on router 1, it is up to the routing protocols to choose an alternative route to router 1.
R1(config)#int lo1 R1(config-if)#ip add 172.20.0.1 255.255.255.255 R1(config-if)#exit R1(config)#ntp source lo1 R1(config)#end R1#show int lo1 Loopback1 is up, line protocol is up Hardware is Loopback Internet address is 172.20.0.1/32
Assuming a routing protocol is in place, routers 2 through 4 can now ping router 1 at 172.20.0.1, regardless of which interface.
R4#ping 172.20.0.1 Sending 5, 100-byte ICMP Echos to 172.20.0.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 3/3/5 ms R4#
On routers 2 through 4 we can now specify router’s 1 loopback interface (126.96.36.199) as NTP source.
R4(config)#ntp server 172.20.0.1 prefer R4(config)#end R4#show ntp associations address ref clock st when poll reach delay offset disp *~172.20.0.1 188.8.131.52 2 0 64 1 3.333 1.521 3937.5 * sys.peer, # selected, + candidate, - outlyer, x falseticker, ~ configured R4#show ntp status Clock is synchronized, stratum 3, reference is 172.20.0.1
We see here that R4 gets stratum 3 (since R1 has stratum 2) and router’s 1 reference clock is 184.108.40.206 (NTP Pool Project).