Understanding NTP: Keeping Your Network Devices in Sync

Time might seem like a small detail, but in networking, it is critical. From logging events to running security protocols, accurate time helps everything run smoothly. This is where NTP, or Network Time Protocol, comes in. NTP is used to synchronize the clocks of devices across a network so they all follow the same accurate time source. In this blog, we will explore what NTP is, why it matters, and how it works in a simple way that even beginners can follow.

---

Before we get into the details of NTP, let’s take a moment to understand why time is so important in networking. Every event in a network is recorded with a timestamp, and this is especially critical in logging. Logs act like a record book, showing exactly when things happen. If the time on your devices is not accurate or consistent, those logs can become confusing, making troubleshooting and tracking issues much harder.

---

In most network devices, there are two types of time you’ll come across: system time and hardware clock (or calendar time).

• System Time – This is the time your device’s operating system uses while it is running. It starts counting from the moment the device is powered on and is often stored in volatile memory, meaning it resets when the device is restarted unless synchronized with a time source.

• Hardware Clock (Calendar Time) – This is the time stored in the device’s hardware, usually backed by a small battery so it can keep time even when the device is off. Think of it like the clock in your computer’s BIOS.

Both of these times need to be accurate and consistent across your network. Without synchronization, devices can drift apart, causing mismatches in logs, scheduling errors, and problems with time-sensitive operations. This is why protocols like NTP are essential.

Before we jump into NTP, it’s worth knowing that you can set the time manually on network devices. In Cisco IOS, this is useful for quick adjustments or when you do not have a time server available. However, manual configuration can be prone to human error and time drift, so it’s best used only in certain situations.

---

Manual Time Configuration in Cisco IOS

To set the time manually, you can use the clock set command in privileged EXEC mode.

Example:

Router> enable
Router# clock set 15:45:00 Aug 10 2025

• 15:45:00 – Time in hours, minutes, and seconds (24-hour format)

• Aug 10 2025 – Date in month, day, and year format

After setting the time, you can verify it with:

Router# show clock

If you also need to configure the time zone so logs and timestamps are correct for your location, you can do that in global configuration mode:

Router> enable
Router# configure terminal
Router(config)# clock timezone PHT 8
Router(config)# end
Router# show clock

Here, PHT is the time zone name and 8 is the offset from UTC.

---

Aside from setting the system time, you can also adjust the hardware clock, often called the calendar time, on a Cisco device. This is the time stored in non-volatile hardware so it can keep running even if the device is powered off. Synchronizing the hardware clock with the correct time is important because it ensures the device starts up with accurate time before any network synchronization takes place.

---

Hardware Clock (Calendar) Configuration in Cisco IOS

To set the hardware clock manually, use the calendar set command in privileged EXEC mode:

Router> enable
Router# calendar set 15:50:00 Aug 10 2025

This works the same way as clock set but applies to the hardware clock instead of the system time.

You can check the current hardware clock time with:

Router# show calendar

If you’ve already set the system time and want the hardware clock to match it, you can sync them using:

Router# write calendar

This command copies the current system time to the hardware clock.

Similarly, if you want to set the system time based on the hardware clock, use:

Router# clock read-calendar

---

Another time-related setting you might encounter on Cisco devices is Daylight Saving Time (DST), sometimes called summer time. While not all countries use DST, it’s important to configure it correctly if your region does. Without proper DST settings, your device’s clock could be off by an hour during certain months, which can cause confusion in logs and scheduled tasks.

---

Daylight Saving Time (Summer Time) Configuration in Cisco IOS

You can configure DST in global configuration mode with the clock summer-time command. The exact syntax can vary depending on your DST rules.

Example (Philippines does not use DST, but here’s a sample for a region that does):

Router> enable
Router# configure terminal
Router(config)# clock summer-time PDT recurring 2 Sun Mar 02:00 last Sun Oct 02:00
Router(config)# end
Router# show clock detail

Explanation:

• PDT – Name for daylight saving time (Pacific Daylight Time in this example).

• recurring – Means it will automatically adjust every year.

• 2 Sun Mar 02:00 – DST starts on the second Sunday of March at 2:00 AM.

• last Sun Oct 02:00 – DST ends on the last Sunday of October at 2:00 AM.

The show clock detail command will display whether DST is currently active and show the UTC offset.

---

Manual Time Configuration Command Summary

---

While setting the time manually can work, it is not the most reliable solution. Devices can slowly drift out of sync, and updating each one by hand is time-consuming, especially in large networks. This is where Network Time Protocol (NTP) comes in. NTP automatically keeps all your devices synchronized with a trusted time source, ensuring accuracy without constant manual adjustments.

---

What is NTP?

Network Time Protocol, or NTP, is a protocol used to synchronize the clocks of network devices with a precise and reliable time source. It works over the internet or within a local network, making sure that all devices follow the same accurate time. NTP can synchronize time down to milliseconds, which is important for logs, security, and time-sensitive operations.

How NTP Works

NTP operates in a hierarchy called the stratum system:

• Stratum 0 – High-precision time sources like atomic clocks or GPS clocks.

• Stratum 1 – Servers directly connected to stratum 0 devices.

• Stratum 2 and below – Devices that get their time from higher stratum servers.

Your network devices usually synchronize with a public or internal NTP server, which in turn gets its time from a higher-level source. NTP regularly checks and adjusts the time on your device, preventing drift and keeping everything consistent.

By using NTP, you remove the guesswork from time management in your network and ensure that every log, event, and process runs on the same clock.

---

NTP ports

• NTP uses UDP port 123 for both clients and servers.

• Allow outbound UDP/123 from clients to servers and allow the return traffic. Broadcast and multicast NTP traffic also use UDP/123.

What is stratum?
Stratum is a simple number that shows how far a device is from a reference clock. Lower is better.

• Stratum 0: Reference clocks like GPS receivers or atomic clocks. These are not network devices.

• Stratum 1: Servers directly connected to a stratum 0 reference clock. These are primary time servers.

• Stratum 2: Servers that sync to stratum 1 servers.

• Stratum 3, 4, ...: Each level syncs to the level above it.

• Practical notes: servers normally use strata 1 to 15. Stratum 16 means the device is unsynchronized. In general, pick a server with a low stratum and good reachability.

Useful Cisco show commands

show ntp associations   // shows peers, refid and stratum
show ntp status         // shows local sync status and stratum

---

Now that we know what stratum levels are, it’s easier to understand the concept of reference clocks. These are the highly accurate time sources that sit at the very top of the NTP hierarchy. Without them, there would be nothing for other devices to synchronize with. Let’s take a closer look at the types of reference clocks and how they provide the “master time” for the rest of the network.

---

Reference Clocks in NTP

A reference clock is a device that provides the most accurate time possible for NTP servers. They are considered stratum 0 devices because they are the direct source of time. NTP servers connected to them become stratum 1 servers.

Common types of reference clocks:

• Atomic Clocks – Extremely precise timekeeping devices often used in laboratories or national time centers.

• GPS Receivers – Get accurate time from satellites, widely used because they are reliable and accessible.

• Radio Clocks – Receive time signals from dedicated longwave radio transmitters.

In most networks, you will not connect directly to a reference clock. Instead, your devices synchronize with an NTP server that already uses one. This is much easier and more practical than managing your own stratum 0 device.

---

When setting up NTP, there are different ways a device can get or share time. These are called NTP modes, and each one is suited for a specific use case. Understanding them will help you choose the right approach for your network setup. Let’s go over the three main modes you’ll encounter in Cisco devices.

---

Three Main NTP Modes in Cisco Devices

1. NTP Client Mode

   • The device acts as a client and synchronizes its time from an NTP server.

   • This is the most common setup for routers, switches, and end devices.

   • Example:

       Router(config)# ntp server 192.168.1.10
     

2. NTP Server Mode

   • The device provides time to other NTP clients in the network.

   • Useful when you have one device already synced to an external time source and you want the rest of your devices to sync to it.

   • Example:

       Router(config)# ntp master 3
     

     The number after master sets the stratum level it will advertise (3 in this example).

3. NTP Peering Mode

   • Two or more devices act as peers, sharing time with each other and helping maintain accuracy if one loses its main time source.

   • Often used between routers in the same network.

Example:

Router(config)# ntp peer 192.168.1.20

---

NTP Configuration in Cisco IOS CLI

Setting up NTP on a Cisco device is straightforward. In most cases, you’ll configure the device as an NTP client to sync with a reliable server.

Example – Configure as an NTP Client:

Router> enable
Router# configure terminal
Router(config)# ntp server 203.117.180.36
Router(config)# end
Router# write memory

• Replace 203.117.180.36 with the IP address or hostname of your chosen NTP server.

• You can also configure multiple servers for redundancy:

Router(config)# ntp server 203.117.180.36
Router(config)# ntp server 129.6.15.28

Verify NTP Status:

Router# show ntp status
Router# show ntp associations

• show ntp status – Shows whether the device is synchronized, its stratum level, and time source.

• show ntp associations – Shows connected servers or peers and their status.

---

Configure NTP as a Server

If your device already has accurate time (either from a reliable NTP source or manually set), you can make it act as an NTP server for other devices in your network. This is useful when you want one router or switch to provide time to all others.

Example:

Router> enable
Router# configure terminal
Router(config)# ntp master 3
Router(config)# end
Router# write memory

• The number after ntp master sets the stratum your server will advertise. In this example, it will be stratum 3.

• This is typically used only if your device is not syncing with an external NTP server. If it is, the stratum will be determined automatically.

---

Primary vs. Secondary NTP Servers

• Primary NTP Server – The first choice for time synchronization. Usually the most reliable and closest in terms of network hops.

• Secondary NTP Server – A backup server used if the primary is unreachable. It helps ensure your devices remain synchronized even if one server goes down.

You can configure multiple NTP servers:

Router(config)# ntp server 203.117.180.36 prefer
Router(config)# ntp server 129.6.15.28

• The prefer keyword tells the device which server should be considered the main source of time if multiple servers are available. Without it, the device chooses automatically based on the best connection and reliability.

---

Checking NTP Status

After configuring NTP, you can verify if your device is synchronized using:

Router# show ntp status

Sample output:

Clock is synchronized, stratum 3, reference is 203.117.180.36
nominal freq is 250.0000 Hz, actual freq is 250.0000 Hz
precision is 2**18
reference time is DFE31A2B.3F4B1E29 (08:15:23.246 PHT Sun Aug 10 2025)
clock offset is 0.1234 msec, root delay is 10.34 msec
root dispersion is 15.22 msec, peer dispersion is 0.45 msec

Key details to note:

• Clock is synchronized – Confirms the device is successfully syncing with an NTP source.

• Stratum 3 – Current stratum level of the device.

• Reference – The IP address or hostname of the server it is syncing to.

• Clock offset – Difference between the device’s time and the server’s time.

• Root delay/dispersion – Network delay and accuracy measurements.

---

Checking NTP Associations

To see the list of NTP servers or peers your device is communicating with, use:

Router# show ntp associations

Sample output:

  address         ref clock       st   when   poll  reach  delay  offset   disp
*203.117.180.36   .GPS.           1     32    64    377    0.56   0.123    0.02
+129.6.15.28      .ACTS.          1     60    64    377    1.20   0.456    0.05

What the columns mean:

• address – IP address or hostname of the NTP server or peer.

• ref clock – The time source that server is using (e.g., GPS, ACTS).

• st – Stratum level of the server.

• when – Seconds since the last poll.

• poll – Polling interval in seconds.

• reach – Reachability register (octal value). 377 means the server is reachable.

• delay – Round-trip delay to the server.

• offset – Time difference between the device and the server.

• disp – Dispersion or estimated error in milliseconds.

Symbols before the address:

• * – The server currently being used for synchronization.

• + – A candidate server (good source but not currently selected).

• - – Server not used due to large delay or offset.

• x – Server designated as a false ticker (providing incorrect time).

---

You can actually use a loopback interface address as the NTP server for another device. In fact, many network engineers prefer this because a loopback interface is always up as long as the device itself is running. This is different from a physical interface, which can go down if the link fails.

Using a loopback also makes things more consistent. Instead of relying on an IP address that might change depending on which interface you use, you can stick to one stable address for NTP, management, and other services. As long as routing is set up properly, the loopback IP will always be reachable, even if one path fails.

For example, let’s say Device B will act as the NTP server and Device A will be the client. On Device B, we create a loopback interface and give it an IP address:

RouterB(config)# interface loopback0
RouterB(config-if)# ip address 10.10.10.1 255.255.255.255
RouterB(config)# ntp master 3

On Device A, we point it to that loopback IP:

RouterA(config)# ntp server 10.10.10.1

As long as Device A can reach that loopback IP through the network, NTP will work just fine.

---

Configuring NTP in Peer Mode

Aside from client and server mode, NTP also supports peer mode. In this setup, two devices act as equals, sharing time information with each other. If one loses its main time source, it can still stay accurate by syncing with its peer.

This is useful between routers in the same network where you want both to keep accurate time without relying solely on an external server.

Example – Device A and Device B as peers:

On Device A:

RouterA(config)# ntp peer 192.168.1.2

On Device B:

RouterB(config)# ntp peer 192.168.1.1

Here, each device’s IP address is the one that the other can reach (it could be a physical interface or a loopback interface if routing is in place). Once configured, they will exchange time updates automatically.

The key difference from client/server mode is that in peer mode, neither device is considered “above” the other. They both work to keep each other accurate.

---

Securing NTP with Authentication

By default, NTP messages are not secured, which means anyone could potentially send false time information to your devices. This might not sound serious at first, but in some environments, wrong timestamps can cause major issues especially in logging, security events, or scheduled tasks.

NTP authentication helps solve this by making sure your device only accepts time updates from trusted sources. It works by using a shared secret key and an MD5 hash to verify the authenticity of NTP packets.

Step 1 – Define the authentication key

Router(config)# ntp authentication-key 1 md5 MySecureKey

• 1 is the key ID.

• md5 MySecureKey is the encryption method and password.

Step 2 – Enable NTP authentication

Router(config)# ntp authenticate

Step 3 – Tell the device which keys are trusted

Router(config)# ntp trusted-key 1

Step 4 – Apply the key when pointing to an NTP server

Router(config)# ntp server 192.168.1.10 key 1

If the key and password match on both ends, NTP sync will work. If not, the device will reject the time updates.

To check the authentication status:

Router# show ntp associations

In the output, you’ll see if the key is in use and whether the association is valid.

---

NTP Configuration Summary

Here’s a quick reference of the main NTP commands in Cisco IOS:

Set time manually

clock set HH:MM:SS DAY MONTH YEAR

Configure hardware clock

calendar set HH:MM:SS DAY MONTH YEAR

Set daylight saving time

clock summer-time TIMEZONE recurring [start] [end]

NTP client mode

ntp server <ip-address/hostname> [prefer] [key <key-id>]

NTP server mode

ntp master [stratum]

NTP peer mode

ntp peer <ip-address>

Use loopback address for NTP

interface loopback0
 ip address <ip-address> 255.255.255.255
ntp master <stratum>

NTP authentication

ntp authentication-key <key-id> md5 <password>
ntp authenticate
ntp trusted-key <key-id>
ntp server <ip-address> key <key-id>

Verify NTP status

show ntp status
show ntp associations

With this reference, you can quickly recall how to configure NTP in different scenarios, whether you’re setting time manually, using an external server, peering between devices, or securing NTP with authentication.

---

Wrapping Up

Time might seem like a small detail in networking, but accurate clocks keep logs consistent, help troubleshoot issues faster, and ensure security events line up correctly. NTP makes this easy by automating synchronization across all your devices, whether they get time from an external source, a peer, or a loopback-based internal server.

Once you’ve set it up and verified it’s working, NTP pretty much runs on its own. Just remember to secure it with authentication in sensitive environments and keep a backup server or peer in mind. With the right setup, your network will stay in sync down to the second and you won’t have to chase mismatched timestamps ever again.