Configure a Cisco Router as an NTP Client

Learn how to configure a Cisco IOS router as an NTP client, verify synchronization, understand NTP status fields, and troubleshoot UDP port 123 connectivity.

What NTP Does

Network Time Protocol (NTP) synchronizes device clocks across an IP network. NTP operates at the application layer and uses UDP port 123.

Consistent time is important because network devices use timestamps in logs, authentication events, monitoring data, troubleshooting records, certificates, and security event correlation. If routers, switches, servers, and security appliances have different clocks, it becomes difficult to reconstruct the order of events or determine whether a certificate and authentication attempt are valid.

NTP Client and Server Roles

An NTP server provides time information. An NTP client obtains time from that server. In this lesson, the Cisco router acts as the NTP client.

You identify the NTP server by an IPv4 address or, where DNS resolution is available, by a hostname. A configured server is a time-source candidate; the router synchronizes only after it can reach the server and complete a valid NTP exchange.

For the example topology, router R1 can reach an internal NTP server at 10.0.0.200.

Basic Configuration

Enter global configuration mode and add the NTP server with the ntp server command.

R1# configure terminal
R1(config)# ntp server 10.0.0.200
R1(config)# end

The router now attempts to use 10.0.0.200 as an NTP time source. Configuration alone does not prove synchronization; verify the association and status before saving the configuration.

Using More Than One Server

When the network design requires resiliency, configure multiple approved time sources. The router can select an available, suitable source if one server becomes unavailable.

R1# configure terminal
R1(config)# ntp server 10.0.0.200
R1(config)# ntp server 10.0.0.201
R1(config)# end

Reachability and Transport Requirements

NTP uses UDP port 123. The router must have Layer 3 reachability to the server, and the server must be configured to answer client requests.

Verify that the server address and route are correct.
Check ACLs and firewalls for required UDP 123 traffic.
Consider NAT behavior if the NTP request crosses a translated boundary.
Use the correct management VRF routing context when the server is reached through a management VRF.
Confirm that the NTP server itself is available and synchronized to a valid source.

A successful ping does not guarantee NTP success. ICMP may be permitted while UDP port 123 is blocked, or the server may reject NTP clients.

Verify NTP Synchronization

Check Overall Status

Use show ntp status to determine whether the router clock is synchronized.

R1# show ntp status
Clock is synchronized, stratum 2, reference is 10.0.0.200
nominal freq is 250.0000 Hz, actual freq is 250.0000 Hz, precision is 2**18
reference time is A1B2C3D4.12345678 (12:34:56.123 UTC)
clock offset is 0.5000 msec, root delay is 2.00 msec
root dispersion is 5.00 msec, peer dispersion is 1.00 msec

The exact formatting varies by IOS release. The important result is a synchronized state and a selected reference server. In this example, 10.0.0.200 is the reference source and the router reports stratum 2.

If the output says the clock is unsynchronized, the router has not accepted a valid NTP source. The server may be unreachable, blocked, unavailable, incorrectly configured, or the router may still be waiting for valid responses.

Confirm the Displayed Time

Use show clock to inspect the router's current time after synchronization.

R1# show clock
12:35:04.567 UTC Mon Aug 17 2026

NTP synchronization and the displayed local time zone are separate concerns. A router can be synchronized to the correct UTC time while displaying a different local time zone than expected.

Inspect NTP Associations

Use show ntp associations to inspect configured peers, reachability, and the selected system peer. Use show ntp associations detail when more detailed association information is needed.

R1# show ntp associations
  address         ref clock       st   when   poll reach  delay  offset  disp
*~10.0.0.200      10.0.0.1         1     32     64   377   2.00    0.50  1.00

A leading asterisk commonly identifies the selected system peer, while a tilde commonly indicates a configured NTP association. Symbols and columns can vary by IOS version, so consult the command's output on the device.

Understanding NTP Status Fields

Field	Meaning	What to Look For
Clock synchronization state	Whether the router has accepted a valid NTP source.	Look for a synchronized message rather than unsynchronized.
Stratum	The clock's distance from a primary authoritative reference clock.	Lower values generally indicate a source closer to the primary reference. A client synchronized to a stratum 1 server normally reports stratum 2.
Reference	The selected upstream reference server or clock.	Confirm that the expected NTP server, such as 10.0.0.200, is selected.
Clock offset	The measured difference between the local clock and the selected NTP source.	A smaller, stable offset generally indicates better agreement.
Root delay	The estimated network delay to the primary reference source.	Review unusually large or unstable values as possible indicators of path or source problems.
Root dispersion	The estimated maximum error relative to the primary reference source.	Lower and stable dispersion generally indicates a more reliable time estimate.
Peer dispersion	The estimated error associated with the selected NTP peer.	Use it with offset and association state to assess the peer's quality.

NTP Strata and Time Quality

Stratum describes how far a clock is from an authoritative reference clock. A reference clock is an upstream source used to establish the current clock value. Lower stratum values generally represent sources closer to the primary reference.

For example, a stratum 1 server is directly connected to a primary reference such as a precise hardware clock. A router synchronized to that server normally reports itself as stratum 2. Stratum alone is not a complete measure of quality; delay, dispersion, reachability, source stability, and network design also matter.

Save the Configuration

After verification, save the running configuration to startup configuration so the NTP settings remain after a reload.

R1# copy running-config startup-config

Common NTP Problems

Symptom	Likely Cause	Verification	Corrective Action
Clock is unsynchronized	The router has not received enough valid NTP responses, or the source is unavailable.	Run `show ntp status` and `show ntp associations`.	Check the server, route, UDP 123 policy, and server-side NTP service. Allow time for valid responses.
No NTP association	The server command is missing, the address is incorrect, or DNS resolution failed when a hostname was used.	Inspect the running configuration and association output.	Configure the correct IPv4 address or a resolvable hostname.
Server is unreachable	There is no route, an interface is down, or a management VRF is not being used correctly.	Test Layer 3 reachability and inspect routing and interface state.	Correct the route, interface, VRF context, or addressing.
UDP port 123 is blocked	An ACL, firewall, or NAT policy permits ICMP but blocks NTP.	Review security policy and traffic counters for UDP 123 in required directions.	Permit only the required NTP traffic between approved sources and clients.
Incorrect server address or route	The configured address is mistyped or points to a different network.	Review the NTP configuration and routing table.	Correct the address or route, then verify the association again.

When Ping Works but NTP Does Not

If R1 can ping 10.0.0.200 but remains unsynchronized, ICMP may be allowed while UDP port 123 is blocked. Other possibilities include the server rejecting R1, the server not serving clients, or the server itself lacking valid synchronization.

Confirm that UDP 123 is permitted by ACLs and firewalls.
Inspect show ntp associations for reachability and peer state.
Check the NTP server's client policy and synchronization status when server-side access is available.

When the Time Appears Incorrect

A synchronized clock can still appear incorrect if the displayed time zone is not configured as expected. Compare UTC time with the router's display and review local clock and time-zone settings separately from NTP synchronization. Also confirm that the upstream server has an accurate source.

Operational and Security Considerations

Use trusted internal or approved external NTP sources.
Configure more than one NTP server when resiliency is required.
Restrict NTP traffic with security policy while allowing required UDP 123 communication.
Use authenticated NTP where the Cisco IOS release, server, and security requirements support it.
Do not rely on manually set time as a long-term replacement for NTP synchronization. Manual time can provide a temporary value, but it does not track clock drift or provide a shared authoritative source.

Command Reference

Command	Mode	Purpose
`ntp server <address>`	Global configuration	Configures an IPv4 address or hostname as an NTP server candidate.
`show ntp status`	Privileged EXEC	Reports synchronization state, reference, stratum, offset, delay, and dispersion.
`show ntp associations`	Privileged EXEC	Displays NTP peers, reachability, and association state.
`show clock`	Privileged EXEC	Displays the router's current clock value and time zone.
`copy running-config startup-config`	Privileged EXEC	Saves verified NTP configuration for use after reload.

For related management-plane topics, review protecting the management plane, enabling SSH on a Cisco router, and syslog configuration and timestamp accuracy.