Written by Remco Kersten, 04/03/2022

Categories: ccna

What is NTP and why it’s so important?

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.

Where does time come from?

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.

Configure NTP on Cisco devices

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.

Netwerk structuur

Set time and date manually

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:

  1. Set date and time
  2. Set time zone

1. Set date and time

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.

2. Set time zone

The time zone (in the case of the Netherlands UTC+1) should be configured as follows:

  • clock timezone name UTCtime
  • clock summer-time name recurring

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.

Set NTP server

A Cisco device can have 2 roles:

  • NTP master: only plays the role of NTP server
  • NTP server: plays the role as both NTP client and NTP server

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
*~213.136.0.252   .PPS.            1      9     64     1 15.290  -0.871 187.53
+~149.210.142.45  17.253.38.125    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 213.136.0.252. 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, 213.136.0.252 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 213.136.0.252

Loopback interface for better availability

2 routes from Router 4 to Router 1

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 (182.20.0.1) 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      213.136.0.252    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 213.136.0.252 (NTP Pool Project).