Articles

NTP and time synchronisation: keeping network clocks aligned

How NTP keeps network devices on the same clock - the server hierarchy, the round-trip measurement, and why unauthenticated time is a risk.

Reading: 5 minNetworking

Article cover: NTP and time synchronisation: keeping network clocks aligned

Essential answer. NTP (Network Time Protocol) keeps the clocks of different devices aligned: each device measures the difference between its own clock and one or more time servers, then corrects itself. It runs over UDP on port 123, the port IANA registers for NTP with RFC 5905 as the reference. A device needs not an accurate clock of its own but a reachable reference and a loop-free hierarchy of servers working to the same UTC timescale. Cisco’s documentation notes that one packet per minute suffices to synchronise two machines to within a millisecond.

The mental model: a hierarchy, and a round trip

Two ideas carry the protocol. The first is the hierarchy: a reference clock - a GPS receiver, for example - is the root, a server directly attached to it is a primary server at stratum 1, and each level below takes a stratum number one higher. The second is the measurement: the server does not push “the time”. The two sides timestamp an exchange, and the client computes its offset from four timestamps, which cancels the network delay in each direction.

        reference clock (GPS, atomic)     convention: called "stratum 0"
                    |
             stratum 1 server             primary server
                    |
        +-----------+-----------+
        |                       |
   stratum 2 server        stratum 2 server
        |                       |
   clients (stratum 3)     clients (stratum 3)
client                       server
  |--- t1 (client transmit) ------------------->|
  |                          t2 (server receive) |
  |                          t3 (server transmit)|
  |<-- t4 (client receive) ---------------------|

offset  theta = 1/2 * [ (t2 - t1) + (t3 - t4) ]
delay   delta =         (t4 - t1) - (t3 - t2)

Terms. A stratum is the number of server levels between a device and the reference clock; a reference clock is a clock traceable to UTC, the timescale NTP distributes. The local time zone is a display setting, not part of the protocol. An association is a configured relationship with one server. The offset is the estimated clock difference, the delay the round-trip network component, and dispersion and jitter the estimated error. Slew applies a correction gradually, step applies it at once.

How a device synchronises, step by step

  1. The device is configured with one or more servers, each forming an association.
  2. It sends a request, recording the transmit timestamp t1.
  3. The server records the receive timestamp t2 and the reply transmit timestamp t3.
  4. The client records the arrival timestamp t4.
  5. From the four timestamps it computes the offset theta and the round-trip delay delta; the offset estimates how far the server’s clock is from its own, and the delay is the network component.
  6. The clock discipline applies the correction gradually when the offset is small, but corrects an offset above the step threshold - 125 ms in RFC 5905 - with a step, which invalidates the peer data.
  7. With several sources, the selection, clustering and combining algorithms discard outliers and disagreeing servers; between updates the device runs on a stored drift estimate, polled in minutes.
  8. A server advertises a stratum one greater than its own source; a device that cannot reach a valid source stays at stratum 16, the value that means “unsynchronised”.

A Cisco IOS-XE device as a client

Cisco IOS-XE is the reference platform here; the syntax below follows Cisco’s own documentation. The concepts are portable, the syntax is not.

ntp server 192.0.2.10 prefer
ntp server 192.0.2.11
show ntp status
show ntp associations

These are documented Cisco commands, not a session: no output is shown.

show ntp status states whether the clock is synchronised, the local stratum, the reference in use and the current offset. show ntp associations lists each configured source with its reachability, its stratum and its offset - the fields to read are the reach flag and the offset, since an unreachable or wild source is unusable. Changing the time is not neutral: log timestamps, certificates, token validation and scheduled tasks depend on it, and a step can break them. Apply time changes in a maintenance window, and prefer authenticated sources.

Limits and the common error

NTPv4 does not mandate authentication: RFC 5905 requires an MD5-keyed message authentication code only if authentication is implemented at all, and RFC 8573 deprecates MD5 in favour of AES-CMAC. Without authentication, anyone who can reach the device can forge a server reply and move its clock. BCP 223 recommends at least four independent, diverse sources: two cannot settle a disagreement, and one is a single point of failure. NTP control messages (mode 6) are a known amplification vector and should be blocked from outside the organisation. NTS (RFC 8915) adds TLS-based key establishment and authenticated time for client-server mode.

The common error is to read stratum as a quality ranking: a lower number is not automatically better time - NTP itself rejects a source whose time disagrees with the others - and a robust clock is built from diverse sources. The second error is to confuse synchronisation with the time zone: NTP carries UTC, and setting the local zone changes only what is displayed.

Level and prerequisites

L2 - operational. The L1 fundamentals are assumed and not repeated here: IPv4/IPv6 prefixes and the default gateway, so the request can be delivered, and Ethernet frames and MAC tables. The closest sibling is DNS and DHCP: a device can also learn its time servers through DHCP option 42. Those sheets own packet delivery and address assignment; the new skill here is choosing sources, authenticating them, and reading the show commands.

Where to go next

References

  • RFC 5905 - Network Time Protocol Version 4: Protocol and Algorithms Specification (2010).
  • RFC 8633 / BCP 223 - Network Time Protocol Best Current Practices (2019).
  • RFC 8573 - Message Authentication Code for the Network Time Protocol (2019).
  • RFC 8915 - Network Time Security for the Network Time Protocol (2020).
  • RFC 2132 - DHCP Options and BOOTP Vendor Extensions; NTP servers option 42 (1997).
  • IANA - Service Name and Transport Protocol Port Number Registry (ntp, 123/tcp and 123/udp).
  • Cisco - System Management Configuration Guide, “Network Time Protocol” module (IOS-XE).
  • Cisco - Basic System Management Command Reference, N-T Commands (ntp, show ntp).