Time might seem like a trivial detail, but in networking it is critical. Syslog messages need accurate timestamps to be useful. Security certificates rely on correct time to validate expiration. Troubleshooting a problem across five devices is nearly impossible if each device’s clock is off by minutes or hours. NTP (Network Time Protocol) exists to keep every device’s clock synchronized to a common, accurate time source — often down to milliseconds.
This article explains NTP from first principles and walks through configuring devices as both NTP clients and NTP servers, on Cisco IOS and Linux, with verification and troubleshooting.
Why Clock Accuracy Matters in Networking
Consider a security incident where an attacker breaches three servers within a two-minute window. If those three servers’ clocks are all off by different, unknown amounts, correlating the logs to reconstruct the attack timeline becomes extremely difficult — potentially impossible. NTP eliminates this problem by ensuring all devices agree on the same time, typically synchronized to within milliseconds of true time.
Beyond security, accurate time is essential for:
- Certificate validation (SSL/TLS certificates have expiration timestamps).
- Scheduled jobs and automation running at expected times.
- Accurate syslog correlation across devices (see the Syslog article in this series).
- Routing protocol authentication in some implementations that use time-based keys.
How NTP Works, From First Principles
NTP operates in a hierarchical structure of “strata,” where each stratum level represents a step away from an authoritative time source:
- Stratum 0 — the reference clocks themselves (atomic clocks, GPS receivers). These are not directly on the network.
- Stratum 1 — servers directly connected to a Stratum 0 device. These are considered highly authoritative.
- Stratum 2 — servers that synchronize from Stratum 1 servers.
- Stratum 3 and beyond — each level synchronizes from the level above it.
flowchart TD
A[Stratum 0: Atomic Clock / GPS] --> B[Stratum 1: NTP Server<br/>directly connected to Stratum 0]
B --> C[Stratum 2: Company's Central NTP Server]
C --> D[Stratum 3: Branch Router - NTP Client]
C --> E[Stratum 3: Core Switch - NTP Client]
D --> F[Stratum 4: End devices sync from branch router]A device can act as both a client and a server simultaneously — this is extremely common. For example, a company’s central router might sync from a public Stratum 1 server (acting as a client), while also serving time to all internal switches and servers (acting as a server).
How NTP Achieves Millisecond Accuracy
NTP calculates the round-trip delay and offset between the client and server by exchanging timestamped packets, then adjusts for network latency — this is why NTP can be accurate to within milliseconds even across a WAN link, unlike simply trusting a single one-way time value.
sequenceDiagram
participant Client
participant Server
Client->>Server: Request (T1: client send time)
Note over Server: T2: server receive time<br/>T3: server send time
Server-->>Client: Response (T2, T3)
Note over Client: T4: client receive time<br/>Calculates offset & round-trip delayConfiguring a Cisco Router as an NTP Client
Router(config)# ntp server 132.163.97.1
Router(config)# ntp server 132.163.97.2Using two or more servers allows the router to cross-check sources and detect a server providing incorrect time.
Authenticating NTP (Recommended for Security)
Without authentication, a malicious actor could spoof NTP responses and shift a device’s clock, undermining log correlation or certificate validity.
Router(config)# ntp authenticate
Router(config)# ntp authentication-key 1 md5 NtpSecretKey123
Router(config)# ntp trusted-key 1
Router(config)# ntp server 132.163.97.1 key 1
Configuring a Cisco Router as an NTP Server (for Internal Clients)
Router(config)# ntp master 3The number 3 here sets the stratum level this router will claim if it has no upstream reference (used carefully — typically only appropriate for isolated lab networks without external time access). In production, you’d normally have the router act purely as a client of an external source and then also serve time to downstream devices automatically — you don’t need ntp master if it already has a valid upstream server; that command is specifically for when the device itself becomes the authoritative source.
Allowing Internal Devices to Sync from This Router
Any router or switch that has ntp server <this router's IP> pointed at it will automatically be served time — no separate “enable server mode” command is required in standard configurations, since NTP server functionality is inherent once the device has synchronized.
Restricting NTP Access with ACLs (Security Best Practice)
Router(config)# access-list 20 permit 10.1.1.0 0.0.0.255
Router(config)# ntp access-group peer 20This ensures only devices within the 10.1.1.0/24 internal network can query this router as an NTP source, preventing it from being abused as an open NTP relay (a known category of attack used in NTP amplification DDoS attacks).
Verifying NTP on Cisco IOS
Router# show ntp statusSample output:
Clock is synchronized, stratum 3, reference is 132.163.97.1
nominal freq is 250.0000 Hz, actual freq is 249.9998 Hz, precision is 2**18
reference time is EA8A9E5D.71EB851E (10:15:41.443 UTC Fri Jul 24 2026)Key phrase to look for: “Clock is synchronized” — if instead it says “Clock is unsynchronized,” the device has not yet locked onto a valid time source.
Router# show ntp associationsSample output:
address ref clock st when poll reach delay offset disp
*~132.163.97.1 .GPS. 1 45 64 377 23.4 0.892 1.2The * symbol next to an address indicates this is the currently selected, synchronized source. The ~ indicates it is configured (statically defined). If no entries show a *, the router has not yet chosen a valid synchronization source.
Router# show clock detail10:16:03.223 UTC Fri Jul 24 2026
Time source is NTP“Time source is NTP” confirms the clock is being set by NTP rather than manually or from an unreliable local hardware clock.
Configuring NTP on Linux (chrony)
Modern Linux distributions typically use chrony instead of the older ntpd.
sudo apt install chrony -y
sudo nano /etc/chrony/chrony.confClient configuration:
server pool.ntp.org iburst
server 132.163.97.1 iburstServer configuration (allowing an internal subnet to sync from this Linux box):
allow 10.1.1.0/24
local stratum 10sudo systemctl restart chrony
sudo systemctl status chronyVerifying NTP on Linux
chronyc trackingSample output:
Reference ID : 84A3611D (ntp1.example.com)
Stratum : 2
Leap status : Normal
System time : 0.000042 seconds fast of NTP timechronyc sources -vMS Name/IP address Stratum Poll Reach LastRx Last sample
^* ntp1.example.com 1 6 377 23 +42us[ +51us] +/- 1234us
The ^* prefix indicates the currently selected best source, similar to the * marker in Cisco’s show ntp associations.
Comparison Table: Cisco IOS vs Linux (chrony) NTP Commands
| Task | Cisco IOS | Linux (chrony) |
|---|---|---|
| Configure client source | ntp server <ip> | server <ip> iburst in chrony.conf |
| Verify sync status | show ntp status | chronyc tracking |
| Verify sources/associations | show ntp associations | chronyc sources -v |
| Become a server for others | Implicit once synced (or ntp master) | allow <subnet> in chrony.conf |
| Restrict server access | ntp access-group peer <ACL> | allow/deny statements |
| Authenticate | ntp authentication-key, ntp trusted-key | keyfile + server ... key <id> |
Automating NTP Health Checks with Python
import subprocess
def check_ntp_sync():
result = subprocess.run(
["chronyc", "tracking"], capture_output=True, text=True
)
output = result.stdout
if "Normal" in output:
print("NTP sync status: OK")
else:
print("NTP sync status: WARNING - check manually")
print(output)
check_ntp_sync()For fleets of Cisco devices, a similar check can be scripted with Netmiko, parsing show ntp status output for the string “synchronized” to build a simple compliance report across all routers and switches — flagging any device whose clock is not properly synced.
Best Practices
- Always configure at least two, ideally three or more, NTP servers for redundancy and to allow the device to detect an inaccurate source (NTP uses statistical algorithms to reject outlier time sources when multiple are configured).
- Use NTP authentication in production environments to prevent time-spoofing attacks.
- Restrict which devices can query your NTP server using ACLs (
ntp access-group), preventing abuse as an open relay. - Configure a stable, reliable internal NTP source (often the core router or a dedicated appliance) and have all other internal devices sync from it, rather than every device independently reaching out to the Internet.
- Set the correct timezone on every device (
clock timezone) so that log correlation across regions is intuitive, even though NTP itself typically operates in UTC internally. - Monitor NTP sync status as part of routine health checks — an unsynchronized clock can silently break logging, certificates, and troubleshooting.
Troubleshooting
| Symptom | Likely Cause | Fix |
|---|---|---|
| “Clock is unsynchronized” | No reachable NTP server, or firewall blocking UDP/123 | Verify connectivity, check ACLs/firewall for UDP port 123 |
No * in show ntp associations | Server reachable but not yet selected (needs time to stabilize), or authentication mismatch | Wait a few polling cycles; verify ntp trusted-key matches |
| Time drifts significantly over time | Faulty local hardware clock, or device not actually syncing | Confirm show clock detail shows “Time source is NTP” |
| Devices in different timezones report confusing log times | clock timezone not configured, or configured inconsistently | Standardize NTP servers in UTC internally, set correct local clock timezone per device |
| NTP server abused for amplification attack | No access restriction configured | Apply ntp access-group peer <ACL> to restrict client access |
Real-World Example: Enterprise NTP Hierarchy
A company’s design uses a two-tier NTP hierarchy: the core router syncs from two public Stratum 1 sources, and every other device internally syncs from the core router.
! Core Router - acts as client to external sources, server to internal devices
ntp authenticate
ntp authentication-key 1 md5 CoreNtpKey!
ntp trusted-key 1
ntp server 132.163.97.1 key 1
ntp server 132.163.97.2 key 1
access-list 20 permit 10.0.0.0 0.0.255.255
ntp access-group peer 20
! Branch Switch - client of the core router only
ntp authenticate
ntp authentication-key 1 md5 CoreNtpKey!
ntp trusted-key 1
ntp server 10.1.1.1 key 1This design minimizes external NTP dependencies (only the core router talks to the Internet for time), simplifies firewall rules, and keeps the entire internal network tightly synchronized through a single authoritative internal source.
Conclusion
NTP quietly underpins nearly every other network operation that depends on accurate timestamps — logging, security certificates, automation scheduling, and troubleshooting correlation. Understanding the stratum hierarchy, configuring devices in both client and server roles, securing NTP with authentication and access restrictions, and knowing how to verify synchronization status with show ntp status/show ntp associations (Cisco) or chronyc tracking/chronyc sources (Linux) are essential, practical skills for any network professional.
References
- RFC 5905 – Network Time Protocol Version 4 — https://datatracker.ietf.org/doc/html/rfc5905
- Cisco NTP Configuration Guide — https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/bsm/configuration/xe-16/bsm-xe-16-book/nm-ntp.html
- Chrony Documentation — https://chrony-project.org/documentation.html
- NTP Pool Project — https://www.ntppool.org/
- NIST Internet Time Service — https://www.nist.gov/pml/time-and-frequency-division/time-distribution/internet-time-service-its
