CCNA online course

Configure and Verify NTP on Cisco IOS Devices

Learn how to configure, authenticate, verify, and troubleshoot NTP time synchronization on Cisco IOS routers and switches.

Network Time Protocol (NTP) synchronizes the clocks of networked devices. This lesson shows how to configure Cisco IOS routers and switches as NTP clients, verify synchronization, provide time to downstream devices, and troubleshoot common failures.

This lesson assumes familiarity with Cisco IOS configuration modes, IPv4 addressing, routing, ping, loopback interfaces, standard ACLs, DNS, and UDP.

Why Accurate Network Time Matters

A Cisco device has a local software clock. Without synchronization, that clock may drift, reset, or differ from the clocks on other devices. NTP provides a common time reference so devices can maintain consistent timestamps.

  • Logs and Syslog: Accurate timestamps show when events occurred and help order messages from multiple devices.
  • Authentication: AAA systems and time-sensitive protocols can reject requests when clocks are too far apart.
  • Certificates: Certificate validation depends on valid start and expiration times.
  • Monitoring: Performance and availability tools use timestamps to calculate durations and correlate events.
  • Troubleshooting: Consistent time makes it easier to match an interface failure, routing change, authentication event, and application alert.
  • Incident response: Investigators can correlate records from routers, switches, firewalls, servers, and security systems.

The configured timezone changes how the device displays time; it does not replace synchronization. NTP normally distributes time based on UTC, while the Cisco device applies its timezone and optional daylight-saving rules for local display.

NTP Fundamentals

Network Time Protocol is an application-layer protocol that synchronizes clocks over IP. In the common client-server model, a Cisco device sends periodic requests to one or more NTP servers. The device measures the exchange, estimates the difference between clocks, and gradually disciplines its local clock.

NTP uses UDP port 123. Successful synchronization therefore requires IP reachability and policy permitting UDP 123, normally in both directions.

Stratum

Stratum describes the number of logical steps from an authoritative reference clock. A reference clock may be backed by GPS, an atomic clock, or another highly accurate source. A server directly connected to that reference is commonly stratum 1. A server synchronized to a stratum 1 server may be stratum 2, and downstream devices have higher stratum values.

A lower valid stratum number is generally closer to the reference clock. Stratum alone does not guarantee that a server is reachable, synchronized, or appropriate; NTP also evaluates the quality and consistency of available associations.

Important NTP Measurements

  • System peer: The association selected as the device's active synchronization source.
  • Offset: The calculated difference between the local clock and the server clock.
  • Delay: The measured network path delay for NTP exchanges.
  • Jitter: Variation in measured timing values over time.
  • Reachability: An association health indication based on replies to recent polls.
  • Poll interval: The interval between synchronization requests.

A configured server is only a candidate. The device must receive valid replies and select a suitable source before its clock becomes synchronized.

Configure the Cisco Clock and Timezone

First inspect the current software clock:

show clock detail

Set the local display timezone with clock timezone. The name is a display label and the offset is measured from UTC.

configure terminal
clock timezone EST -5

Where regional policy requires recurring daylight-saving changes, configure them explicitly. The exact rule depends on the region and IOS release.

clock summer-time EDT recurring

UTC is the global time basis normally used by NTP. The timezone command controls local display, and the summer-time command applies a seasonal display adjustment. An incorrect timezone can make the displayed local time look wrong even when NTP reports synchronization.

Basic NTP Client Configuration

Configure approved NTP servers using their IP addresses:

configure terminal
ntp server 10.10.10.10
ntp server 10.10.20.10

Using multiple reliable sources improves availability and lets the device compare candidates. In this example, the branch router can route to both internal servers. The normal process is:

  1. The router resolves or uses the configured server address.
  2. It polls the server using UDP 123.
  3. It evaluates replies, timing measurements, stratum, and association health.
  4. It selects a valid system peer.
  5. It disciplines the local clock over time.

You can configure a DNS hostname instead of an IP address when the platform and IOS release support it:

ntp server ntp1.example.internal

Hostname-based configuration requires working DNS resolution, a configured resolver, and reachability to the resolved address. IP-based configuration removes DNS as a dependency but still requires routing and UDP 123 access.

Use a Stable NTP Source Interface

By default, the source address of an NTP packet may depend on the outgoing interface. A stable loopback address is often preferable because it remains available while physical paths change and gives the NTP server one predictable client address.

configure terminal
interface Loopback0
 ip address 10.255.255.1 255.255.255.255
exit
ntp source Loopback0
ntp server 10.10.10.10
ntp server 10.10.20.10

The NTP servers must have a return route to 10.255.255.1. Their access controls and any firewalls must permit UDP 123 from that address. The source interface must be up, have a valid address, and be reachable through bidirectional routing.

Cisco IOS NTP Configuration Commands

Purpose — Command — Important Notes

Set timezone — clock timezone EST -5 — Use the applicable local UTC offset.

Set recurring daylight saving — clock summer-time EDT recurring — Controls seasonal display adjustment.

Configure an NTP server — ntp server 10.10.10.10 — Use an approved, reachable source.

Select packet source — ntp source Loopback0 — Ensure return routing and server policy permit the address.

Enable authentication — ntp authenticate — Enables authentication processing.

Create a key — ntp authentication-key 10 md5 ExampleSharedSecret — Match the key ID, algorithm, and secret on both systems.

Trust a key — ntp trusted-key 10 — Marks the key as acceptable for synchronization.

Apply a key to a server — ntp server 10.10.10.10 key 10 — Associates the server with the intended key.

Provide lab time — ntp master 5 — Advertises the local clock at the configured stratum.

Save settings — copy running-config startup-config — Save only after validation.

Configure Symmetric-Key NTP Authentication

Symmetric-key authentication uses a shared key identifier and secret to help a client verify that NTP messages came from a trusted participant and were not altered in transit. It does not encrypt NTP traffic, protect the entire network path, or prove that the remote clock is authoritative. Network Time Security (NTS) is a more modern related technology where platform and server support are available; Cisco IOS symmetric-key authentication remains the core configuration covered here.

Example: the router and enterprise NTP server share key ID 10 and the same secret.

configure terminal
ntp authenticate
ntp authentication-key 10 md5 ExampleSharedSecret
ntp trusted-key 10
ntp server 10.10.10.10 key 10

The key number and value must match on both participating systems. The server statement must reference the intended key, and the key must be trusted locally. Authentication syntax and supported algorithms can vary by Cisco platform and IOS release; protect secrets according to organizational policy.

Serve Time to Downstream Devices

A Cisco device that has a valid upstream NTP synchronization source can provide time to downstream clients. For example, a distribution switch can synchronize with central servers while access switches use the distribution switch as a nearby source.

Serving time does not make the Cisco device authoritative. Verify its upstream state first:

show ntp status

ntp master makes the local clock an advertised NTP source at a configured stratum. It is useful in an isolated training lab or as a carefully planned fallback, but it should not replace a reliable authoritative source in production.

configure terminal
ntp master 5

The configured value represents the advertised master stratum. A higher value indicates greater distance from an authoritative reference than a lower value. Do not use an unsynchronized local clock as a production time authority merely because clients can reach it.

Control NTP with Access Groups

Cisco IOS NTP access groups use standard ACLs to restrict NTP behavior. The mode determines what matching addresses are allowed to do.

Mode — Permitted Behavior — Typical Use

peer — Permits NTP peer associations — Restrict explicitly configured peer relationships.

serve — Permits the device to provide time and permits broader NTP interaction than serve-only — Use when clients or peers require service.

serve-only — Permits matching addresses to receive time, but not to establish peer relationships — Common choice for downstream clients.

query-only — Permits status and control queries but not time synchronization — Allow monitoring systems to query NTP status.

Example allowing clients in 10.20.0.0/16 to receive time:

configure terminal
access-list 10 permit 10.20.0.0 0.0.255.255
ntp access-group serve-only 10

Choose the least-permissive mode that meets the requirement. An incorrect access-group can block legitimate synchronization, including upstream associations if the policy is applied too broadly. Test both approved and unapproved source networks after applying the policy.

Verify NTP Operation

Inspect the Clock

show clock detail

Check the displayed time, timezone, daylight-saving indication, and whether the clock is identified as authoritative or synchronized by NTP.

Inspect Overall NTP Status

show ntp status

A healthy result identifies a synchronized state, the current stratum, reference source, and clock quality indicators. An unsynchronized message means that configuration alone has not produced a valid system peer.

Inspect Associations

show ntp associations
show ntp associations detail

Association output shows candidate servers, selection state, reachability, poll information, and peer health. Detailed output adds measurements such as offset, delay, jitter, and server details.

Symbol — Meaning — Administrative Action

* — Selected system peer — Confirm this source is approved and healthy.

+ — Suitable candidate — Keep as a redundant source and monitor reachability.

- — Candidate rejected for selection — Review quality, stratum, or timing measurements if unexpected.

? — Reachability or information is insufficient — Check routing, UDP 123, server response, and elapsed convergence time.

Symbols can vary slightly by IOS release, so use the command's legend when available. The asterisk is the key exam and operational indicator: it normally marks the selected system peer.

NTP Verification Commands and Expected Results

Command — What It Checks — Healthy Indicators

show clock detail — Local clock and display rules — Correct time, timezone, and synchronization indication.

show ntp status — Overall synchronization — Clock synchronized, valid stratum, and reference source shown.

show ntp associations — Candidate and selected peers — At least one healthy association, usually marked with *.

show ntp associations detail — Detailed peer health — Reachability, poll data, offset, delay, and jitter are populated and reasonable.

show running-config — Persistent NTP settings — Correct servers, source interface, authentication, ACLs, and timezone policy.

Save and Maintain the Configuration

After successful validation, save the running configuration:

copy running-config startup-config

Document the approved time servers, source interface, timezone and daylight-saving policy, authentication-key handling, NTP access groups, and firewall requirements. NTP configuration persists in the startup configuration, but the live clock and synchronization state change over time. Monitor them periodically.

Structured NTP Troubleshooting

Use this order rather than changing several settings at once:

  1. Review the configuration.
  2. Test IP reachability using the intended source address.
  3. Validate routing and UDP 123 policy in both directions.
  4. Inspect associations and reachability.
  5. Inspect overall NTP status.
  6. Confirm the displayed clock and timezone.

Useful Tests

show running-config
ping 10.10.10.10 source Loopback0
show ntp associations
show ntp associations detail
show ntp status
show clock detail

If necessary, packet debugging can show NTP exchanges, but it can generate substantial output and affect an operational device:

debug ntp packets
undebug all

Use debugging cautiously, preferably in a lab or maintenance window, and disable it immediately after collecting the required evidence.

Common NTP Failures

Symptom — Likely Cause — Verification Step — Corrective Action

Clock is unsynchronized — Server unreachable, UDP 123 blocked, no valid peer, or upstream server unsynchronized — Check status, associations, routes, and policy — Restore reachability, permit UDP 123, or use a valid server.

Configured server is not selected — Wrong address, DNS failure, authentication mismatch, server ACL rejection, or healthier competing source — Inspect detailed associations and configuration — Correct destination, DNS, authentication, or server policy.

Failure after source-interface change — New address lacks return route or is not permitted — Ping with the new source and inspect server policy — Add routing and permit the new source address.

Authentication prevents synchronization — Key ID, secret, trust setting, or server key reference differs — Compare all authentication commands on both systems — Make the key ID, algorithm, secret, and trust settings match.

Displayed time is wrong but status is synchronized — Incorrect timezone or daylight-saving configuration — Review show clock detail — Correct local display settings; do not treat this as an NTP transport failure.

Downstream clients cannot obtain time — Upstream device is unsynchronized, access group denies clients, or UDP 123 is filtered — Check serving device status, ACLs, routing, and policy — Synchronize upstream, correct access groups, and permit client traffic.

Interpretation Rules

A server command only creates an association candidate. It does not guarantee that the server responds, passes authentication, is synchronized itself, or wins peer selection. Allow sufficient time for polling and convergence before concluding that a new configuration has failed.

When using a hostname, confirm DNS resolution. When using a loopback source, confirm that the server can route back to the loopback address. When authentication is enabled, compare key ID and secret exactly. When an ACL or firewall is present, validate both the source address and UDP 123 behavior.

Practical Configuration Scenarios

Branch Router with Redundant Internal Servers

configure terminal
clock timezone EST -5
clock summer-time EDT recurring
ntp server 10.10.10.10
ntp server 10.10.20.10
end
show ntp status
show ntp associations

This provides two approved sources and establishes the local display policy. Validate that one association becomes the system peer and that the clock reports synchronization.

Loopback-Sourced NTP

configure terminal
interface Loopback0
 ip address 10.255.255.1 255.255.255.255
exit
ntp source Loopback0
ntp server 10.10.10.10
ntp server 10.10.20.10
end

Confirm return routing and server-side permission for 10.255.255.1.

Distribution Switch Serving Access Switches

Configure the distribution switch with resilient upstream servers, verify that it is synchronized, and then permit only the access-switch subnet with a suitable NTP access group. Configure access switches to use the distribution switch as their NTP server.

Isolated Training Lab

configure terminal
ntp master 5

This lets other lab devices use the router as a local source. It is intentionally non-authoritative and should not be substituted for enterprise or external time infrastructure in production.

Related Cisco Topics

Accurate NTP supports Cisco NTP configuration and complements the OSI reference model when analyzing protocol operation. For broader networking foundations, review computer networking concepts.