Does Network Time Really Matter?

Introduction

Welcome to Part 22 of the Network Fundamentals study notes! If you haven’t already, we recommend watching the video first.

It might not seem like a big deal whether your router has the right time. But accurate time across network devices matters more than most people realise. In this part we look at why it matters and how to get it right — both manually and automatically with NTP.

Why Time Matters

Network devices constantly generate log messages — events like interfaces going up or down, configuration changes, authentication attempts, and much more. Every log has a timestamp. When an issue affects several devices simultaneously, you need to correlate those logs across multiple devices. If each device has a different idea of what time it is, that correlation becomes unreliable or impossible.

Beyond logging, accurate time matters for:

• Security certificates – certificates have expiry dates. A device with the wrong time may reject a valid certificate or accept an expired one.
• Windows domain authentication – Windows requires that client and domain controller clocks are within five minutes of each other. If they drift further apart, logins fail.
• Intrusion detection – security systems correlate events across time to identify attack patterns. Inaccurate timestamps undermine this completely.
• Scheduled tasks – router reboots, maintenance windows, or automated backups must happen at the right time.
• Legal requirements – some industries are legally required to maintain accurate, tamper-evident logs.

Setting the Clock Manually

You can configure time manually on a Cisco device, though it requires a few steps and needs to be done on every device individually.

First, set the timezone in global configuration mode:

clock timezone AEST 10

If your region observes daylight saving time (summertime), configure that separately:

clock summer-time AEDT recurring ...

Then set the actual time and date. This is done in privileged EXEC mode (not configuration mode):

clock set 14:30:00 1 Jun 2026

Verify with show clock.

If you have devices spread across multiple timezones, consider setting them all to UTC rather than local time. Correlating logs from different timezones is much easier when everything shares a common reference.

The obvious downside of manual configuration is that it’s tedious, not very accurate, and the clock will drift over time without anything correcting it.

NTP – Network Time Protocol

The better solution is NTP — Network Time Protocol. Devices configured as NTP clients automatically synchronise their time with an NTP server, keeping all devices accurate and in sync with each other.

The Stratum Hierarchy

NTP servers are organised into layers called strata:

• Stratum 0 – specialised hardware time sources such as atomic clocks and GPS receivers. Not directly accessible over a network.
• Stratum 1 – NTP servers connected directly to stratum 0 hardware. These are the most accurate network-accessible time sources.
• Stratum 2 – servers that synchronise with stratum 1. Slightly less accurate, but still extremely precise.
• Stratum 3, 4, … – each layer synchronises with the one above. Each hop introduces tiny additional inaccuracies — fractions of a millisecond — but for practical purposes, stratum 2 or 3 servers are more than accurate enough for network devices.

Choosing an NTP Server

You have a few options:

• Internet NTP server – free public servers are widely available. NTP uses UDP port 123, so you may need to allow this through a firewall.
• Internal NTP server – if you have a Windows Domain Controller, it’s already running as an NTP server by default. You can point your network devices at it, then have the DC synchronise with an internet server.
• Both – configure an internal server as primary and an internet server as backup. This is a common and resilient approach.

Configuring NTP on Cisco Devices

NTP configuration on Cisco is refreshingly simple. From global configuration mode:

ntp server pool.ntp.org

pool.ntp.org is a public pool of NTP servers — you don’t need to find specific server IPs. There are also regional variants (e.g. au.pool.ntp.org for Australia) that route requests to nearby servers for lower latency.

To configure multiple servers with one preferred:

ntp server 192.168.1.10 prefer
ntp server pool.ntp.org

The prefer keyword tells the device to use that server as its primary source. The other is used as a fallback.

Verification

• show ntp associations – lists configured NTP servers. A * marks the actively used server; a + marks the candidate backup.
• show ntp status – shows whether the clock is synchronised and the current stratum.
• show clock – confirms the current date and time.

The initial synchronisation takes at least 10 minutes. NTP exchanges several messages with the server first to measure the round-trip time and compensate for network delay — especially important if the server is geographically distant. After the initial sync, the client periodically checks in to stay accurate.

Troubleshooting tip: if NTP is struggling to synchronise, try manually setting the clock to approximately the correct time first. The process tends to work more smoothly when the client and server clocks aren’t wildly out of sync to begin with.

Resources

Test your knowledge with the Introduction to Networking quizzes.