Network Time Protocol (NTP) is a protocol to synchronise the time on network devices in the Local Network Area (LAN). NTP ensures that all devices have the same accurate time, which is crucial for security, maintenance, and troubleshooting of the network.
NTP can synchronise the time with high precision throughout the whole network. The rule is straightforward. As the time signal is transmitted between the client and the server.
The NTP protocol must be set correctly to ensure that all logs correlate. Furthermore, many security protocols (such as SSL and TLS) require accurate time synchronisation to authenticate authenticity and avoid attacks. Accurate time can help with time-sensitive tasks like backups, maintenance, and scheduling.
Specific industries require a rigorous regulation regarding time synchronisation. The examples are telecom, finance or energy business sectors using the PTP (Precision Time Protocol – IEEE 1588 std) standard, which improves a commonly used NTP in the network.
Failure to keep the computer network up to date causes security threats, operational failures, and regulatory issues. As a result, modern IT environments require the implementation and maintenance of NTP in their networks.
Let's focus on a small local network with 4 routers and 4 switches. Static routing protocol is used to configure these network devices. Router 3 manages the connection across three VLANs using Router On A Stick configuration (ROAS). Router 1 supplies DHCP service to all devices in this lab. We are now focused on NTP configuration. So we need to configure our NTP master device, servers, and clients.
We made a decision to dedicate router 1 as an NTP master and routers 2, 3, and 4 as client servers.
Just to remind you, the router master is the primary time point in the network. We can set up our designated "master" device using local or external time. It is strongly recommended to use an external source rather than local. And when using an external source, it is important to ensure that the firewall does not block the dedicated external port 123 on the UDP protocol. NTP server device receives the time signal from the authoritative source (master device) and is able to distribute it to the client. NTP client receives time from the server and synchronises its own clock. In some cases we want our router to act only as a client.
Figure 1 - Local network with basic NTP configuration
Returning back to our topology, we checked the existing time on router 1 using the command 'show clock'. Also, we can check the NTP state by entering 'show ntp associations'. If any information was not presented (as shown in the script below), it confirms that NTP was not activated.
R1#show clock
*19:30:17.009 UTC Wed Apr 23 2025
R1#show ntp association
R1#
(no associations available)
As we decided in this lab, we would like to set up router 1 as the NTP master device to distribute the time signal in the local network to the rest of the devices. As you can see, under ntp master command, there is one more thing to set up: the stratum number. At the moment we stay with the default stratum setting or just click the Enter key from the keyboard. In this way we synchronise our NTP master with local time.
R1(config)#ntp master ?
<1-15> Stratum number
<cr>
R1(config)#ntp master
R1(config)#
Be careful; the first check from the command 'show ntp status' will not confirm any changes, as the synchronisation process must take some time. Still there (on router 1), we can see unsynchronised clocks.
R1#show ntp status
Clock is unsynchronized, stratum 8, reference is 127.127.1.1
nominal freq is 1000.0003 Hz, actual freq is 1000.0003 Hz, precision is 2**15
ntp uptime is 3100 (1/100 of seconds), resolution is 1000
reference time is EBB3BEA1.04FAA9F8 (19:31:45.019 UTC Wed Apr 23 2025)
clock offset is 0.0000 msec, root delay is 0.00 msec
root dispersion is 3937.83 msec, peer dispersion is 3937.58 msec
loopfilter state is 'FREQ' (Drift being measured), drift is 0.000000000 s/s
system poll interval is 16, last update was 15 sec ago.
R1#
To confirm NTP configuration on router 1, we check the association. The asterisk (*) attached to the IP address 127.127.1.1 confirms that the NTP protocol is activated with reference to the local time. The given IP address with the first octet of 127 is the loop address.
R1#show ntp associations
address ref clock st when poll reach delay offset disp
*~127.127.1.1 .LOCL. 7 4 16 37 0.000 0.000 437.72
* sys.peer, # selected, + candidate, - outlyer, x falseticker, ~ configuredsh
Now when the NTP master is ready to distribute its signal, we enter router 2 to initiate the NTP server state. Thus, router 2 is going to work in server mode, obtaining a signal from the NTP master router and redistributing it to the next routers.
Note we need to state the IP address of the NTP master. We can use IPv or IPv6 addressing format or hostname.In this lab we utilized IPV4 addressing as later in the script.
R2(config)#ntp server ?
A.B.C.D IP address of peer
WORD Hostname of peer
X:X:X:X::X IPv6 address of peer
ip Use IP for DNS resolution
ipv6 Use IPv6 for DNS resolution
vrf VPN Routing/Forwarding Information
Our configuration code of a single line for router 2 is very simple. We must specify the IP address of router 1, port G0/0, which is 172.16.10.2.
R2(config)#ntp server 172.16.10.2
Obviously, there are more parameters which we could deploy, as illustrated below in the script.
R2(config)#ntp server 172.16.10.2 ?
burst Send a burst when peer is reachable (Default)
iburst Send a burst when peer is unreachable (Default)
key Configure peer authentication key
maxpoll Maximum poll interval
minpoll Minimum poll interval
prefer Prefer this peer when possible
source Interface for source address
version Configure NTP version
<cr>
Let's check the synchronisation status of router 2 with association to router 1 (see both scripts below. In the first script we used work 'do' as command was executing from global configuration mode instead of execution mode).
R2#show ntp status
Clock is unsynchronized, stratum 9, reference is 172.16.10.2
nominal freq is 1000.0003 Hz, actual freq is 1000.0003 Hz, precision is 2**15
ntp uptime is 116200 (1/100 of seconds), resolution is 1000
reference time is EBB3C860.77F301C4 (20:13:20.468 UTC Wed Apr 23 2025)
clock offset is -446.0954 msec, root delay is 5.10 msec
root dispersion is 2768.16 msec, peer dispersion is 1938.13 msec
loopfilter state is 'FREQ' (Drift being measured), drift is 0.000000000 s/s
system poll interval is 64, last update was 58 sec ago.
R2#
R2#show ntp association
address ref clock st when poll reach delay offset disp
*~172.16.10.2 127.127.1.1 8 35 64 1 4.010 -437.10 938.25
* sys.peer, # selected, + candidate, - outlyer, x falseticker, ~ configured
R2#
Now we need to configure the NTP service on router number 3. The NTP service for router 3 will be dedicated from router 2, from the IP address 192.50.50.1. This is a result of router 2 acting as a server for router 3. Literally, router number 2 works in the first instance like a client updating time from router 1, from the master. Following that, router 2 switches to the server mode, redistributing the time protocol to the rest of the connected devices he is connected to, like switches or routers (excluding the master router 1).
Exactly in the same client-server mode are working routers 3 and 4. The time protocol continues to be distributed throughout the network, ensuring accurate time synchronisation across all devices.
Similarly , router 4 is updating the time protocol from router 3 using IP address 10.10.10.1.
R3(config)#ntp server 192.50.50.1
R4(config)#ntp server 10.10.10.1
Now we are able to check routers 3 and 4 with NTP server settings as shown in the scripts below. We could apply the same settings for the four switches from this topology, but we can omit it due to repetition.
R3#show ntp status
Clock is unsynchronized, stratum 10, reference is 192.50.50.1
nominal freq is 1000.0003 Hz, actual freq is 1000.0003 Hz, precision is 2**15
ntp uptime is 22600 (1/100 of seconds), resolution is 1000
reference time is EBB3CF5E.5489A0DB (20:43:10.330 UTC Wed Apr 23 2025)
clock offset is -4.5400 msec, root delay is 6.42 msec
root dispersion is 4608.80 msec, peer dispersion is 3937.55 msec
loopfilter state is 'FREQ' (Drift being measured), drift is 0.000000000 s/s
system poll interval is 64, last update was 24 sec ago.
R3#show ntp associations
address ref clock st when poll reach delay offset disp
*~192.50.50.1 172.16.10.2 9 39 64 1 4.842 26.814 1937.7
* sys.peer, # selected, + candidate, - outlyer, x falseticker, ~ configured
R3#
R4#show ntp status
Clock is synchronized, stratum 11, reference is 10.10.10.1
nominal freq is 1000.0003 Hz, actual freq is 1000.1518 Hz, precision is 2**15
ntp uptime is 459200 (1/100 of seconds), resolution is 1000
reference time is EBB3E072.A3D4E8CA (21:56:02.639 UTC Wed Apr 23 2025)
clock offset is -121.7659 msec, root delay is 8.24 msec
root dispersion is 1558.18 msec, peer dispersion is 1.79 msec
loopfilter state is 'CTRL' (Normal Controlled Loop), drift is -0.000151596 s/s
system poll interval is 64, last update was 134 sec ago.
R4#
R4#show ntp association
address ref clock st when poll reach delay offset disp
*~10.10.10.1 192.50.50.1 10 26 64 37 1.977 -121.76 1.828
* sys.peer, # selected, + candidate, - outlyer, x falseticker, ~ configured
R4#
Network Time Protocol (NTP) is a protocol that synchronises time on network devices in the Local Network Area (LAN), ensuring accurate time for security, maintenance, and troubleshooting. It must be set correctly to ensure logs correlate and is crucial for security protocols like SSL and TLS. Accurate time is essential for time-sensitive tasks like backups, maintenance, and scheduling. In industries like telecom, finance, and energy, strict regulations are required for time synchronisation. Modern IT environments require NTP implementation and maintenance to prevent security threats, operational failures, and regulatory issues. We practised NTP settings for the small local network with 4 routers and 4 switches. Router 1 was configured to master. Routers 2 , 3 and 4 were set up in client-server mode.