NTP

What Is NTP (Network Time Protocol)?

NTP, the Network Time Protocol, is the protocol devices use to synchronize their clocks against a common time reference over a network.

It is one of the oldest protocols still in daily use, and the current version, NTPv4, is defined in RFC 5905.

Every server, switch, firewall and workstation keeps its own clock. Each one runs slightly fast or slightly slow. NTP corrects them continuously against an upstream source.

That way, a timestamp written on one machine means the same instant as one written on another.

Over a local network it holds devices within a millisecond or so. Across the public internet, expect a few tens of milliseconds.

That sounds minor until something breaks. When you line up a firewall log, an application log and a database log to work out the order of events in an incident, you assume those clocks agreed. If one host sits forty seconds out, the sequence you reconstruct is fiction.

How Does NTP Work?

NTP measures the round trip to a time source and corrects for it. It never simply accepts whatever time the server reports.

A single exchange carries four timestamps:

1. T1 when the client sent the request.

2. T2 when the server received it.

3. T3 when the server sent its reply.

4. T4 when the client received that reply.

From those four values the client works out two things.

Round-trip delay comes out as (T4 − T1) − (T3 − T2), the time spent in transit with the server's own processing removed.

Clock offset comes out as ((T2 − T1) + (T3 − T4)) / 2, which is how far the client's clock sits from the server's once half the round trip is accounted for.

Clients repeat this against several sources, polling every 64 to 1,024 seconds by default. They drop any source that disagrees with the rest. Querying more than one server protects you from a single upstream that is confidently wrong.

Corrections apply in two ways. A small offset gets slewed: the clock runs slightly fast or slow until it catches up, so time never jumps backwards and no log entry lands out of order.

A large offset gets stepped, jumping straight to the correct value. ntpd steps once the offset passes 128 milliseconds, and it exits entirely beyond a panic threshold of 1,000 seconds.

NTP runs over UDP on port 123 in both directions, because a late time measurement is a worthless one.

Retransmitting a lost packet would deliver timestamps that no longer match the current round trip, so NTP waits for the next poll instead.

In practice that means your firewall rules must allow UDP 123 between clients and their time sources. A blocked rule produces no error.

Clocks drift apart over days, and we have watched the resulting problems get blamed on almost everything else first.

NTP vs SNTP vs PTP

The three differ in precision and cost.

SNTP uses the identical packet format, so an SNTP client and an NTP server talk to each other without any special handling.

What Are NTP Stratum Levels?

Stratum is a hop count describing how far a device sits from an authoritative time source. Lower means closer.

Watch for stratum 16 in operations. It is how a device reports that it has no working time source at all.

Accuracy degrades gently as the number climbs. So, a stratum 4 host causes no trouble on its own, but a deep chain gives a single failure more places to spread.

Keep the chain shallow. The design we see work most often runs two or three internal servers synchronized to external stratum 1 or 2 sources, with every other device pointed at those. Clocks then stay consistent with each other even when the external link drops.

What Is Clock Drift and What Causes It?

Clock drift is the gradual divergence of a device's clock from true time. This drift is caused by its oscillator running slightly off its rated frequency.

Most computers keep time with a quartz crystal, and its oscillation rate shifts with 4 things. They are temperature, supply voltage, age and manufacturing tolerance.

A typical crystal holds to within tens of parts per million.

That sounds precise until you do the math. For example, 50 ppm works out to roughly 4.3 seconds a day, or over two minutes a month, on a machine that never synchronizes.

Virtual machines drift the worst. A guest measuring time while descheduled loses ticks it cannot recover. That is why hypervisors offer their own time services.

Hosts in hot racks drift faster than the spec sheet suggests. A device that loses its configured source runs on the last correction it had. Moreover, this gap widens quietly until something fails.

Why Does Clock Drift Break Your Logs?

Log analysis rests on an assumption you rarely state out loud: timestamps from different systems are comparable. Clock skew quietly breaks it.

Say a web server's clock runs thirty seconds ahead of the database IT queries. Your centralized log view now shows the database returning results before the request initiates.

An engineer reconstructing an outage sees an impossible sequence and hunts for a cause in the wrong place. SIEM correlation fails the same way. A rule that expects a failed login followed by a privilege change within sixty seconds never fires when the two hosts disagree by more than that window.

Authentication is the other common casualty. Kerberos, which underpins active directory logins, rejects tickets when client and domain controller disagree by more than the configured tolerance.

Windows sets that tolerance to five minutes by default. A domain controller that loses time sync starts refusing logins across the estate. Additionally, nobody reports the symptom as a clock problem.

TLS behaves the same way, treating valid certificates as not yet valid or already expired.

Scheduled jobs, backup retention windows, service level agreement measurement and audit evidence all rest on the same foundation.

Several compliance regimes go further and require logs to carry a synchronized time source.

How Do You Monitor NTP and Time Sync?

Time synchronization is easy to monitor and almost always overlooked until it causes an incident. That makes it a cheap thing to get right.

Start with the time source itself. A service check over UDP 123 confirms each internal time server both responds and responds promptly.

Monitor every internal time server this way, because a source that stops answering produces no immediate symptom, only a slow estate-wide drift.

Then watch the clients. On Windows, the Time Service writes specific events as synchronization degrades, and log processing picks them up.

Event ID 36 means the service could not synchronize for an extended period. Events 47 and 48 mean no valid response arrived from configured or domain peers.

Event 49 means the difference from a peer exceeded the acceptable threshold. Event 50 means it grew too large to correct at all, which announces that the host's timestamps can no longer be trusted. On Linux, read the daemon's reported offset and stratum instead.

The alerting rule holds either way. Alert on stratum 16, on offset passing a threshold you set, and on any host that has not synchronized within a defined period.

Put those signals alongside syslog output and interface metrics, and you catch a drifting clock early.

Every other correlation then stays sound, because the timestamps underneath are known to be accurate. Time sync is the dependency beneath root cause analysis, and it deserves verifying instead of assuming.