Network Time Protocol (NTP) is a networking protocol that synchronizes the clocks of computers and devices over a network to within milliseconds of Coordinated Universal Time (UTC). It underpins log correlation, certificate validation, and authentication across distributed systems – including every node in a Versa Director, Analytics, and VOS deployment.
Key takeaways
- NTP keeps clocks on a network synchronized to milliseconds of UTC.
- Modern NTP uses a stratum hierarchy and can authenticate servers with keys.
- Versa Director and Analytics nodes use Chrony as the NTP service since 23.1.1.
- VOS devices can sync via NTP, be set manually, or act as an NTP server.
- Accurate time keeps logs, certificates, and SSO tokens valid across a deployment.
On this page: Why it mattersHow it worksTypesNTP & VersaFAQ
Why is NTP important?
Distributed systems only make sense if their clocks agree. When a Director node, an Analytics cluster, and dozens of VOS devices all log events, security teams need those timestamps to line up so they can reconstruct an incident across the fabric – a few seconds of clock drift can turn a straightforward correlation into a guessing game. NTP is what keeps that agreement intact, continuously nudging every clock in a deployment toward the same reference time.
Time accuracy is also a security dependency, not just an operational convenience. TLS certificate validation checks issue and expiry dates against the local clock, so a device with skewed time can reject valid certificates or accept expired ones. Authentication protocols that rely on time-limited tokens – Kerberos tickets, SSO assertions, one-time codes – fail once clocks drift past their tolerance window. Because NTP sits underneath so many of these functions without ever appearing in the UI, it is easy to overlook until something breaks; a stale or unreachable NTP source is a common root cause of hard-to-diagnose authentication and logging failures.
What is NTP?
NTP runs over UDP port 123. A client sends a request to a time server, the server stamps it with its own clock reading, and the client uses the round-trip delay and the reported offset to calculate how far its own clock has drifted. Rather than jumping the clock forward or backward abruptly – which can break time-ordering assumptions in running processes – NTP normally slews it, making small continuous adjustments until the two clocks converge.
Servers are organized into a stratum hierarchy. Stratum 0 devices are reference clocks – GPS receivers, atomic clocks – that are never queried directly. Stratum 1 servers attach directly to a stratum 0 source; stratum 2 servers synchronize from stratum 1, and so on, with accuracy degrading slightly at each hop. To prevent a rogue or spoofed server from feeding a network false time, NTP supports authentication keys – historically MD5, and now SHA-1 and the SHA-2 family – that a client and server both hold and use to sign their exchanges.
Types of NTP
NTP defines a few distinct association modes. Client-server (unicast) mode is the common case: a client polls one or more servers directly and applies their responses. Symmetric active/passive mode lets two peers, typically servers themselves, exchange time bidirectionally so either can correct the other. Broadcast/multicast mode has a server announce time to an entire subnet without individual polling, trading some accuracy for scale.
Two protocol versions remain in use. NTPv3, defined in RFC 1305, is the older specification; NTPv4, defined in RFC 5905, is the current version and stays wire-compatible with v3 clients. A lightweight subset, SNTP (Simple NTP), drops the statistical filtering and peer-selection algorithms full NTP uses, trading precision for a simpler implementation suited to embedded devices that don’t need millisecond accuracy.
The daemon that actually disciplines the clock matters too. Legacy deployments run ntpd; newer ones increasingly run Chrony, which converges faster after a restart, handles intermittent network connectivity better, and supports the newer SHA-2 authentication types.
NTP & Versa
Every part of a Versa deployment depends on synchronized time, and each component configures NTP a little differently. On a Director node, administrators add NTP servers under Administration > System > NTP > Server, optionally attaching an authentication key created under System > NTP > NTP Key – MD5 and SHA-1 from Release 22.1.4, with SHA-256, SHA-384, and SHA-512 added in 23.1.1. From Release 23.1.1 onward, Director’s systemwide functions run NTP over Chrony instead of the legacy ntpd daemon, with chronyc sources, chronyc tracking, and chronyc ntpdata available for diagnosing sync and authentication issues.
Individual VOS devices are configured through Time Settings in Director’s Appliance view, where an administrator chooses NTP or manual time, adds NTP servers with iburst enabled for faster initial sync, and – from Release 22.1.4’s December 2024 service release – can configure the device itself to act as an NTP server. Analytics clusters require NTP as part of initial software configuration: every node lists its NTP servers in clustersetup.conf, since node-to-node database replication depends on clocks staying aligned.
Frequently asked questions
What port does NTP use?
NTP operates over UDP port 123. A client sends a timing request to a server on that port, and the server responds with its own timestamp; firewalls between a device and its configured NTP servers must permit UDP 123 in both directions for synchronization to succeed.
What is the difference between NTP and SNTP?
NTP applies statistical filtering across multiple servers and peers to select the most reliable time source and estimate error bounds; SNTP is a simplified client that trusts a single server’s response directly. SNTP suits low-power or embedded devices that don’t need NTP’s full precision.
What is a stratum in NTP?
A stratum is a server’s distance, in hops, from a stratum 0 reference clock such as a GPS or atomic clock. Stratum 1 servers attach directly to a reference clock; stratum 2 servers synchronize from stratum 1, and so on, with accuracy decreasing slightly at each additional hop.
Why did Versa move from ntpd to Chrony?
Starting in Release 23.1.1, Versa Director and Analytics nodes run Chrony instead of the legacy ntpd daemon. Chrony converges on accurate time faster after a restart, handles unreliable or intermittent network connections better, and adds support for SHA-2 authentication algorithms, while staying interoperable with standard remote NTP servers.
Can a VOS device act as its own NTP server?
Yes. From Release 22.1.4’s December 2024 service release, a VOS device can be configured, under Time Settings, to serve NTP to other clients – specifying a source network, source interface, and description in addition to acting as an ordinary NTP client for its own clock.
More on NTP
If you want to learn more, these are sources we trust.
| RFC 5905: NTPv4 Protocol and Algorithms | RFC 1305: NTP Version 3 |
|---|---|
| The current IETF specification: association modes, the stratum model, and the algorithms clients use to filter and select time sources. | The earlier NTPv3 specification that NTPv4 remains wire-compatible with; useful background on the protocol’s original design. |
Related terms
If you’re reading about NTP, these are worth looking at next.
| Versa Director | Simple Network Management Protocol | Remote Authentication Dial-In User Service |
|---|---|---|
| The console where administrators add NTP servers, create authentication keys, and configure time settings across a deployment. | Another open network protocol for monitoring devices; SNMP traps and polling records carry the timestamps NTP keeps accurate. | An authentication protocol whose time-limited tokens and session records depend on client and server clocks staying synchronized. |