Configuring and Verifying NTP Client-Server for Time Synchronization

1. NTP Fundamentals: Stratum and Synchronization

Before we jump into configuration, let's understand how NTP works. NTP operates in a hierarchical model to distribute time from a highly accurate source throughout a network. The key concept here is stratum.

A device's stratum level indicates how many "hops" it is from an authoritative time source.

• Stratum 0: These are the reference clocks themselves, such as atomic or GPS clocks. They are the most accurate sources but are not directly used in the network.
• Stratum 1: These are servers directly connected to Stratum 0 clocks. They are considered the most authoritative time servers on the network. Public NTP servers on the internet are often Stratum 1 or 2.
• Stratum 2: A server that receives its time from a Stratum 1 server.
• Stratum 3: A server that receives its time from a Stratum 2 server, and so on.
• Stratum 15: This is the highest valid stratum level.
• Stratum 16: Indicates that a device is unsynchronized or the source is unreachable.

NTP uses UDP port 123 for communication. A client will periodically poll a server to request the time, and the protocol includes sophisticated algorithms to account for network delay, ensuring high accuracy.

To get a solid grasp of these core concepts, let's watch a short video.

2. Designing an NTP Hierarchy

In an enterprise network, you don't want every single device reaching out to public internet time servers. This is inefficient and creates a heavy dependency on external connectivity. The best practice is to create an internal, hierarchical structure.

As the guide explains, a hierarchical structure is scalable and stable. A typical design involves:

1. A small number of core routers or dedicated servers that sync with reliable external (public) Stratum 1 or 2 servers.
2. These internal "master" servers then provide time to distribution layer devices.
3. Access layer switches and other clients then sync with their local distribution layer devices.

This creates a clean, tiered model for time distribution that is robust and easy to manage.

3. Configuring NTP in a Client/Server Hierarchy

Let's put this theory into practice. Our goal is to configure an internal NTP hierarchy. We'll use a scenario where one router acts as our primary internal time server, and another acts as a client.

Step 1: Configure the NTP Server

There are two main ways to set up your primary internal server.

Method A: Sync with Public Servers (Recommended)
This is the most common and recommended approach for networks with internet access. The router syncs with reliable public NTP servers and then serves this time to your internal network.

Method B: Configure as Master Clock (Isolated Networks)
If the network is isolated or if you want a local authoritative source for a lab, you can configure a router to act as an NTP "master". It uses its own internal clock as the source. This is less accurate than a public source but ensures all internal devices are synchronized with each other.

The following video demonstrates both configuration approaches, as well as crucial best practices like using loopback interfaces.

Example Configuration

Let's configure our Core Switch (Core-SW) from the diagram to sync with public NTP servers and our Access Switch (Access-SW) to sync with the Core Switch.

On the Core Switch (Core-SW):

! Configure timezone and daylight saving for correct local time display
! Note: NTP itself always communicates in UTC.
clock timezone EST -5
clock summer-time EDT recurring

! Best Practice: Create a loopback interface to use as a stable source IP
interface Loopback0
 ip address 10.10.10.1 255.255.255.255

! Use the loopback as the source for all NTP packets
ntp source Loopback0

! Point the switch to one or more reliable public NTP servers.
! Using hostnames from pool.ntp.org is a common practice.
ntp server 0.pool.ntp.org
ntp server 1.pool.ntp.org

! (Optional, for isolated networks) If this switch had no internet access,
! you would use this command instead of the 'ntp server' commands above.
! The number '3' sets the stratum level.
! ntp master 3

Step 2: Configure the NTP Client

Now, we configure the Access Switch to use our Core Switch as its time source.

On the Access Switch (Access-SW):

! Configure local timezone
clock timezone EST -5
clock summer-time EDT recurring

! Point the client to the internal NTP server's IP address (the loopback of Core-SW)
ntp server 10.10.10.1

With this simple hierarchy, Core-SW gets accurate time from the internet (becoming Stratum 2 or 3), and Access-SW gets accurate time from Core-SW (becoming Stratum 3 or 4).

4. Verifying NTP Operation

Configuration is only half the battle. You must be able to verify that synchronization is working correctly. The most important commands are show ntp status and show ntp associations.

A crucial point for verification is that NTP does not synchronize instantly. It can take several minutes (sometimes 10-15 minutes) for a device to vet a time source and achieve synchronization. Initially, you will likely see a stratum of 16, which means "unsynchronized." This is normal.

Key Verification Commands

Let's look at what the output of these commands tells us.

• show ntp status: This is your primary command.

  Core-SW# show ntp status
  Clock is synchronized, stratum 3, reference is 199.102.46.73
  ...
  

  • Clock is synchronized: The most important line. If it says "unsynchronized," it's not working yet.
  • stratum 3: This device's stratum level.
  • reference is 199.102.46.73: The IP address of the server this device is currently synchronized with.

• show ntp associations: This command shows the state of all configured servers.

  Access-SW# show ntp associations
        address         ref clock     st   when   poll   reach   delay   offset    disp
  *~  10.10.10.1        199.102.46.73  3      6     64    377     1.24    0.281     0.49
   * sys.peer, # selected, + candidate, - outlyer, x falseticker, ~ configured
  

  • The most important symbol is the asterisk (*), which indicates this is the "sys.peer"—the server your device has chosen to synchronize with.
  • st 3: The stratum of the server (10.10.10.1).
  • reach 377: An octal value indicating the success of the last 8 polls. 377 means all 8 were successful.

! Set the source interface for NTP packets
ntp source Loopback0

! Configure both HQ servers for redundancy
ntp server 10.1.1.10
ntp server 10.1.1.11

clock timezone PST -8
clock summer-time PDT recurring

Conclusion

In this lesson, you've learned how to implement one of the most fundamental IP services. Ensuring consistent time across all network devices is a cornerstone of network stability, security, and manageability.

Key Takeaways:

• NTP is Critical: It's essential for log correlation, certificate validation, and time-based access control.
• Stratum Hierarchy: NTP uses stratum levels (0-15) to measure the distance from an authoritative reference clock. Stratum 16 means unsynchronized.
• Hierarchical Design: The best practice is to build an internal NTP hierarchy, where core devices sync externally and serve time to internal clients.
• Configuration:
  • ntp server <ip-address> configures a device as an NTP client.
  • ntp master [stratum] configures a device as an authoritative source (for isolated networks).
  • ntp source <interface> is a best practice to provide a stable source IP address for NTP packets.
• Verification:
  • show ntp status provides a high-level summary of synchronization state.
  • show ntp associations shows the status of configured servers. Remember that synchronization is not instant.

Preview of the Next Lesson:

We've covered how devices get addresses (DHCP) and how they agree on the time (NTP). Next, we will venture into the world of one-to-many communication. In the upcoming lesson, we will explain multicast fundamentals, including IGMP operation and multicast addressing, which is the foundation for efficiently delivering streaming video, financial data, and other group-based traffic across the network.