NTP (Network Time Protocol) – Time Synchronisation, Stratum Levels, and Cisco IOS Configuration

1. What Is NTP and Why Does It Matter?

NTP (Network Time Protocol) is a networking protocol defined in RFC 5905 that synchronises the clocks of computers and network devices to within milliseconds of a reference time source. Without NTP, each device maintains its own independent clock that drifts at a different rate — in just a few days, clocks across a network can diverge by minutes or hours.

Clock accuracy is not merely a convenience — it is a functional requirement for several critical network systems. Syslog timestamps become meaningless for cross-device event correlation when clocks disagree. Security protocols including Kerberos and TLS certificate validation embed timestamps in authentication tokens and will actively reject connections if the time difference between client and server exceeds a threshold (Kerberos default: 5 minutes). Compliance frameworks including PCI-DSS, HIPAA, and SOX mandate accurate log timestamps for audit evidence. 

  What accurate time makes possible:

  Router1 log: Jul 10 14:03:12.001  %LINK-3-UPDOWN: Gi0/1 down
  Switch1 log: Jul 10 14:03:12.345  %OSPF-5-ADJCHG: Nbr 2.2.2.2 from FULL to DOWN
  Firewall log: Jul 10 14:03:12.450  DENY tcp 10.0.0.5→192.168.1.100:443

  → 344ms and 449ms gaps reveal a clear causal chain:
    cable pulled → OSPF neighbour lost → firewall traffic blocked

  Without NTP (clocks drift independently):
  Router1 log: 14:03:12   Gi0/1 down
  Switch1 log: 08:03:12   OSPF adjacency lost   ← 6-hour difference!
  Firewall log: 22:15:09   DENY tcp              ← completely uncorrelated

  → No causal chain visible. Troubleshooting takes hours instead of minutes.

Related pages: show logging | Syslog Configuration Lab | show ip protocols | show running-config | ACLs | Named ACLs | Common Port Numbers | SSH Configuration | Troubleshooting Methodology | NTP Configuration Lab

2. How NTP Works

NTP uses a client-server model over UDP port 123. A client sends a request to an NTP server containing the client's current time. The server responds with its own timestamp. The client then calculates the round-trip delay (how long the packet took in each direction) and the offset (how far the client's clock differs from the server's) — and applies a correction to gradually adjust its clock without causing an abrupt jump that could disrupt time-sensitive applications. 

  NTP four-timestamp exchange:

  Client                              Server
    │                                   │
    │── T1: client sends request ───────→│  (T1 = client transmit timestamp)
    │                                   │
    │                                   │  Server records T2 (receive time)
    │                                   │  Server records T3 (transmit time)
    │                                   │
    │←─ T4: client receives response ───│  (T4 = client receive timestamp)
    │
  Client now has: T1, T2, T3, T4

  Round-trip delay = (T4 - T1) - (T3 - T2)
  Clock offset     = ((T2 - T1) + (T3 - T4)) / 2

  The client applies the offset to its clock — gradually (slewing) if the
  offset is small (±128ms), or immediately (stepping) if the offset is large.

  NTP uses multiple servers simultaneously and applies Marzullo's algorithm
  to identify and discard outliers (servers reporting significantly different
  times from the majority), improving overall accuracy.

NTP Polling Intervals

  NTP uses an adaptive polling interval:

  Initial sync (or after iburst):  poll = 64 seconds  (more frequent)
  Stable sync achieved:            poll grows to 1024 seconds (~17 minutes)

  The polling interval doubles until the clock is stable, then remains
  at the maximum. This reduces network traffic while maintaining accuracy.

  iburst option: sends a burst of 8 packets at 2-second intervals when
  first connecting to an NTP server — dramatically reduces time to achieve
  initial synchronisation from minutes down to seconds.

3. NTP Stratum Hierarchy

NTP uses a hierarchical stratum model to measure distance from the authoritative time reference. Lower stratum numbers indicate higher accuracy and closer proximity to an atomic reference clock. Stratum is incremented by 1 for each hop away from a Stratum 0 source. 

  Stratum hierarchy:

  Stratum 0: Physical reference clock
  ├── GPS satellite receiver         ← provides nanosecond accuracy
  ├── Caesium or rubidium atomic clock
  └── WWVB radio time signal
  (NOT directly on the network — connected to a Stratum 1 server via RS-232)

  Stratum 1: Primary NTP servers (directly connected to Stratum 0)
  ├── time.google.com  (Google's public NTP — GPS-backed)
  ├── time.apple.com   (Apple's public NTP)
  ├── pool.ntp.org     (distributed public NTP pool)
  └── Corporate GPS-disciplined NTP server

  Stratum 2: Secondary NTP servers (synchronised to Stratum 1)
  ├── Internal corporate NTP servers
  └── Core network switches acting as NTP servers for the organisation

  Stratum 3–15: Clients syncing down the hierarchy
  ├── Branch routers syncing to Stratum 2 corporate server
  ├── Switches, firewalls, servers
  └── Each hop adds a small amount of jitter and delay

  Stratum 16: UNSYNCHRONISED
  └── Device has no valid NTP source; clock is considered unreliable
      A Cisco device shows stratum 16 until it successfully syncs.
Stratum Description Example Accuracy
0 Physical reference clock — not on the network; connected directly to a Stratum 1 server GPS receiver, atomic clock, WWVB radio Nanoseconds
1 Primary time server; directly connected to a Stratum 0 source via hardware interface time.google.com, pool.ntp.org, corporate GPS-synced NTP appliance Microseconds to low milliseconds
2 Secondary server; synchronised to one or more Stratum 1 servers Internal corporate NTP server, core switch acting as NTP server Low milliseconds
3–15 Further downstream clients/servers; each level adds slight jitter from the hop above Branch routers, switches, servers, workstations Milliseconds to tens of milliseconds
16 Unsynchronised — the device has no valid NTP source; clock is not trusted Cisco device before ntp server is configured or before sync is achieved Unreliable — do not use

Important CCNA exam point: A Cisco router configured with ntp master 5 advertises itself as a Stratum 5 NTP server to other devices on the network. It uses its own internal clock (which may not be externally synchronised) as the source. This is used when no external NTP reference is available — for example, in a lab or isolated network. The ntp master command should always include a stratum number higher than the true stratum of the best available reference.

4. Cisco IOS NTP Configuration — Client

  ! ── Configure NTP server sources ──────────────────────────────────────
  Router(config)# ntp server pool.ntp.org prefer
  !                                         └─ "prefer" = use this server
  !                                            as the preferred source when
  !                                            multiple servers are configured.
  !                                            The router still polls all
  !                                            servers but weights this one higher.

  Router(config)# ntp server 192.168.1.100
  ! Add a second NTP source (internal corporate server).
  ! Using multiple servers provides redundancy and improves accuracy —
  ! NTP uses all configured servers and cross-checks them.

  ! ── Sync hardware clock (NVRAM-backed) ───────────────────────────────
  Router(config)# ntp update-calendar
  ! Synchronises the hardware clock (the battery-backed clock in NVRAM)
  ! with the NTP-corrected software clock.
  ! Why this matters: if the router reloads and has no NTP connectivity on
  ! boot, the hardware clock provides the initial time. Without this command,
  ! the hardware clock may drift and cause a brief period of wrong timestamps
  ! on reboot until NTP re-syncs.

  ! ── Verify the configuration ─────────────────────────────────────────
  Router# show ntp status
  Router# show ntp associations

5. Cisco IOS NTP Configuration — Server (ntp master)

  ! Configure this router as an NTP server for the local network:
  Router(config)# ntp master 5
  !                        └─ Stratum number this router advertises.
  !                           Set higher than the best external source.
  !                           Common values: 3 (if synced to public Stratum 1/2)
  !                           or 5 (if using internal clock only).
  !
  ! IMPORTANT: "ntp master" makes the router use its OWN INTERNAL CLOCK
  ! as the time source if it cannot reach any external NTP server.
  ! It does NOT mean the router is connected to an atomic clock.
  ! If the internal clock drifts, all clients will receive wrong time.
  !
  ! Best practice: always also configure ntp server [external] alongside
  ! ntp master so the router prefers the external source when available.

  ! ── Full recommended configuration for an internal NTP server ────────
  Router(config)# ntp server pool.ntp.org prefer      ! sync to public NTP
  Router(config)# ntp server time.google.com          ! secondary public NTP
  Router(config)# ntp master 3                        ! act as server to LAN
  Router(config)# ntp update-calendar                 ! keep hardware clock synced

  ! Client devices on the LAN then point to this router:
  BranchRouter(config)# ntp server 192.168.1.1        ! this router's LAN IP

6. NTP Authentication — MD5 Key-Based

Without authentication, any device can claim to be an NTP server and send false time updates to your routers. NTP authentication uses a shared key (MD5) to verify that time updates come from a trusted source. This prevents NTP spoofing attacks where an attacker sends crafted NTP responses to shift the clock on a target device. 

  ! ── On the NTP SERVER router ──────────────────────────────────────────
  Server(config)# ntp authenticate
  ! Enable NTP authentication globally (required on both client and server)

  Server(config)# ntp authentication-key 1 md5 MySecureKey
  !                                     │      └─ Shared secret (must match client)
  !                                     └─ Key ID number (1–65535)

  Server(config)# ntp trusted-key 1
  ! Mark key 1 as trusted — the server will only accept time from peers
  ! that present this key ID with the correct password

  ! ── On the NTP CLIENT router ──────────────────────────────────────────
  Client(config)# ntp authenticate
  Client(config)# ntp authentication-key 1 md5 MySecureKey
  Client(config)# ntp trusted-key 1
  Client(config)# ntp server 192.168.1.100 key 1
  !                                             └─ Associate key 1 with this server
  !                                                Client only accepts time from
  !                                                192.168.1.100 if it presents key 1

  ! ── Verify authentication is working ─────────────────────────────────
  Router# show ntp associations detail
  ! Look for "authenticated" in the output to confirm auth is active

  ! If authentication fails:
  ! "configured, no authentication" appears in show ntp associations detail
  ! Check that both sides have: same key ID, same password, ntp trusted-key set

7. NTP Configuration on Linux (chrony)

chrony is the recommended NTP implementation on modern Linux distributions (Ubuntu 18.04+, RHEL 8+, Debian 11+), replacing the older ntpd daemon. Chrony synchronises faster after boot or after network disruptions and handles intermittent connectivity better than ntpd. 

  ! ── Install and enable chrony ─────────────────────────────────────────
  sudo apt update
  sudo apt install chrony -y          # Ubuntu/Debian
  sudo dnf install chrony -y          # RHEL/CentOS/Rocky

  sudo systemctl enable chrony
  sudo systemctl start chrony

  ! ── Configure NTP sources in /etc/chrony/chrony.conf ─────────────────
  # Example chrony.conf:
  server pool.ntp.org iburst           # use NTP pool, burst on startup
  server time.google.com iburst        # secondary public NTP source
  server 192.168.1.100 iburst prefer   # internal NTP server (preferred)

  ! "iburst" sends 8 initial packets at 2s intervals for fast initial sync.
  ! Without iburst, initial sync can take 5–15 minutes; with iburst, ~10s.

  ! ── Configure as a server for local network ───────────────────────────
  # In /etc/chrony/chrony.conf, add:
  allow 192.168.1.0/24                 # allow clients in this subnet to sync
  local stratum 5                      # serve as stratum 5 if upstream unreachable

  sudo systemctl restart chrony

  ! ── Verify sync status ────────────────────────────────────────────────
  chronyc tracking
  chronyc sources -v

  ! ── NTP Client Configuration on Linux (legacy ntpd) ──────────────────
  # /etc/ntp.conf (older systems):
  server pool.ntp.org iburst
  server time.google.com iburst

  # Restart ntpd:
  sudo systemctl restart ntp

  # Check with:
  ntpq -p

Windows NTP Configuration

  ! Configure Windows NTP client (Command Prompt — run as Administrator):
  w32tm /config /syncfromflags:manual /manualpeerlist:"pool.ntp.org"
  w32tm /resync /force

  ! Force an immediate resync:
  w32tm /resync

  ! Check Windows time sync status:
  w32tm /query /status
  w32tm /query /peers

  ! Windows Domain environment:
  ! - Domain Controllers use w32time and sync from the PDC Emulator
  ! - Domain members sync from their authenticating Domain Controller
  ! - The PDC Emulator should sync from an external NTP source

8. Verification — show ntp status and show ntp associations

These two Cisco IOS commands together give a complete picture of NTP synchronisation state. Knowing how to read both outputs is a CCNA exam requirement.

show ntp status — Annotated

  Router# show ntp status

  Clock is synchronised, stratum 3, reference is 192.168.1.100
  │            │          │           │
  │            │          │           └─ IP address of the NTP server this
  │            │          │              router is currently syncing from
  │            │          └─ This router's stratum level (3 = synced to a
  │            │             Stratum 2 server at 192.168.1.100)
  │            └─ "synchronised" = clock is locked to a valid NTP source
  │               "unsynchronised" = no valid source; stratum will be 16
  └─ Overall sync state

  nominal freq is 250.0000 Hz, actual freq is 249.9999 Hz, precision is 2**18
  ntp uptime is 1800 (1/100 of seconds), resolution is 4000
  reference time is E1234567.89ABCDEF (14:03:12.000 UTC Thu Jul 10 2025)
  clock offset is +1.4560 msec, root delay is 5.1230 msec, root dispersion is 10.5400 msec
  │                │                  │                    │
  │                │                  └─ Total one-way delay from this  │
  │                │                     router to the Stratum 0 source │
  │                └─ Round-trip delay to the reference server          │
  └─ How far this router's clock                                         │
     currently differs from the server time                             │
     Positive = router clock is ahead   Negative = router clock is behind

  peer mode is client, leap indicator is 00
  ! leap indicator 00 = no leap second pending; 11 = clock not synchronised

  Key status checks:
  ✓ "synchronised" (not "unsynchronised") — clock is locked
  ✓ Stratum value matches expected hierarchy (not 16)
  ✓ offset is small (< 100ms for most networks; < 1ms for high-accuracy)
  ✓ root dispersion is small (indicates stable source)

show ntp associations — Annotated

  Router# show ntp associations

    address         ref clock       st   when   poll reach  delay  offset  disp
  *~192.168.1.100  .GPS.            2    45     64   377    5.123  +1.456  2.345
   ~pool.ntp.org   .INIT.          16    -      64     0    0.000   0.000 16000.

  Column meanings:
  Column 1 (symbols):
    *  = currently selected (synced) peer  ← this is the active time source
    +  = acceptable peer (could take over if * fails)
    -  = peer considered but rejected by the clock selection algorithm
    x  = peer declared a false ticker (outlier) — not used
    ~  = configured as server (static peer, not discovered via broadcast)
    #  = too many peers selected (rare)
    blank = not yet evaluated

  address   = IP or hostname of the NTP server
  ref clock = the server's own time reference (what it syncs to)
              .GPS. = GPS; .INIT. = initialising; .LOCL. = local clock
  st        = server's stratum level (2 = Stratum 2 server)
  when      = seconds since last packet received from this server
  poll      = current polling interval in seconds (64 = polling every 64s)
  reach     = octal reachability register (377 = all 8 recent polls successful)
              0   = no polls succeeded → NTP server not reachable
              377 = all recent polls succeeded → healthy connection
  delay     = round-trip delay to this server in milliseconds (5.123ms)
  offset    = clock offset in milliseconds (+1.456ms = router 1.456ms ahead)
  disp      = dispersion (clock error estimate) — lower is better
              16000 in second row = server not yet reachable

Linux — chronyc tracking and ntpq -p Annotated

  $ chronyc tracking

  Reference ID    : C0A80164 (192.168.1.100)   ← current NTP server (hex IP)
  Stratum         : 3                            ← this system's stratum
  Ref time (UTC)  : Thu Jul 10 14:03:12 2025    ← last update from server
  System time     : 0.001234567 seconds fast of NTP time
  Last offset     : +0.001234567 seconds        ← most recent correction
  RMS offset      : 0.000876543 seconds         ← average offset stability
  Frequency       : 12.345 ppm fast             ← clock frequency error
  Residual freq   : -0.001 ppm                  ← remaining frequency error
  Skew            : 0.876 ppm                   ← frequency estimation error
  Root delay      : 0.005123 seconds            ← delay to reference clock
  Root dispersion : 0.010543 seconds            ← dispersion from reference
  Update interval : 64.0 seconds                ← current polling interval

  "Leap status    : Normal" = no leap second adjustments needed

  $ ntpq -p

  remote           refid      st t when poll reach   delay   offset  jitter
  ==============================================================================
  *time.google.com  .GPS.      1 u   25   64  377    5.123   +1.456   0.234

  Column key (same as Cisco show ntp associations):
  * = active selected source
  refid .GPS. = Google's server syncs from GPS
  st=1 = Stratum 1 server
  reach=377 = all recent polls successful (octal 377 = binary 11111111)
  delay = 5.123ms  offset = +1.456ms (system clock 1.456ms ahead)
  jitter = 0.234ms (stability of recent offset measurements — lower is better)

9. Public vs Internal NTP Servers

Type Examples Pros Cons Best For
Public NTP pool pool.ntp.org, time.google.com, time.cloudflare.com, time.apple.com No setup required; highly available distributed pools; Stratum 1 accuracy; free to use Requires internet access from the device; adds network latency vs a local server; not suitable for air-gapped networks Internet-connected devices; small networks without internal NTP infrastructure
Internal NTP server Corporate NTP appliance with GPS disciplining; Cisco router with ntp master; Linux server with chrony Lower latency (LAN-local); works in air-gapped environments; full control over stratum and accuracy; one internet connection serves all internal devices Requires initial setup and maintenance; internal server must itself sync from an external reference for maximum accuracy Large enterprise networks; security-sensitive environments; networks without direct internet access from all devices

Recommended Enterprise NTP Hierarchy

  Stratum 1: GPS-disciplined NTP appliance or public pool servers
  (time.google.com, pool.ntp.org, time.cloudflare.com)
                │ sync to
  Stratum 2: Internal NTP server (Linux chrony or core Cisco router)
             configured: ntp server pool.ntp.org + ntp master 3
                │ sync to
  Stratum 3: All network devices (routers, switches, firewalls)
             configured: ntp server 192.168.1.100
             (all clients point to the internal server, not the internet)
                │ sync to
  Stratum 4: Servers, workstations, IoT devices

  This design: only ONE device (the internal NTP server) needs outbound
  access to the internet on UDP/123. All other devices sync internally.
  Centrally managed, audit-friendly, and secure.

10. NTP Security

NTP faces two main security threats: NTP spoofing (an attacker sends forged NTP responses to shift a device's clock) and NTP amplification DDoS (an attacker uses open NTP servers to amplify a flood). Authentication addresses the first; firewall controls address both. 

  ── Restrict UDP 123 to trusted sources (most important control) ──────

  ! Only allow NTP queries from the internal NTP server:
  Router(config)# access-list 10 permit 192.168.1.100
  Router(config)# ntp access-group peer 10
  ! "peer" = only IPs in ACL 10 can peer (sync) with this device

  ! On Linux — restrict which clients can query this server:
  # In /etc/chrony/chrony.conf:
  allow 192.168.1.0/24     # only allow this subnet to query
  deny all                 # deny all other sources

  ! UFW firewall — allow NTP only from internal network:
  sudo ufw allow from 192.168.1.0/24 to any port 123 proto udp
  sudo ufw deny from any to any port 123

  ── Disable NTP broadcast/multicast mode ─────────────────────────────
  Router(config)# no ntp broadcast
  Router(config)# no ntp multicast
  ! NTP broadcast mode sends time updates to all devices on a subnet
  ! without requiring them to authenticate. An attacker on the LAN can
  ! inject false broadcast time updates. Disable unless specifically needed.

  ── Enable MD5 authentication (reviewed in Section 6) ────────────────
  Router(config)# ntp authenticate
  Router(config)# ntp authentication-key 1 md5 MySecureKey
  Router(config)# ntp trusted-key 1
  Router(config)# ntp server 192.168.1.100 key 1

  ── Additional security controls ──────────────────────────────────────
  • Monitor: alert if system time suddenly changes by more than a threshold
  • Use NTPsec (NTP with cryptographic authentication) where supported
  • Do not run public-facing NTP servers unless necessary (DDoS risk)
  • Consider PTP (Precision Time Protocol, IEEE 1588) for sub-microsecond
    accuracy in financial trading or industrial control environments

See: ACLs | Named ACLs | ACL Overview

11. Troubleshooting NTP Issues

Symptom Likely Cause Diagnostic and Fix
show ntp status shows "Clock is unsynchronised" No NTP server reachable; UDP/123 blocked by firewall; NTP server IP misconfigured; NTP authentication mismatch ping [ntp-server-ip] — verify IP reachability; show ntp associations — check reach value (0 = no response); verify firewall allows UDP/123 outbound; verify ntp server command is present in running config
Stratum shown as 16 Device has no valid NTP source — same causes as "unsynchronised"; also seen immediately after boot before first sync completes Check NTP source configuration; verify reachability; allow 5–10 minutes after boot (or use iburst to accelerate); check show ntp associations for reach column
Large clock offset (hundreds of ms or more) NTP is functioning but the clock drifted significantly before sync; old hardware clock value loaded on boot Add iburst option for faster correction; run ntp update-calendar to sync hardware clock; on Linux: chronyc makestep forces an immediate step correction
Syslog messages still show wrong timestamps despite NTP synced service timestamps log datetime msec not configured; device showing uptime instead of real date/time in logs Router(config)# service timestamps log datetime msec; verify with show logging — asterisk (*) before timestamp means NTP not yet synced
NTP authentication fails — peers show "unauth" in show ntp associations detail Key ID mismatch; password mismatch; forgot ntp trusted-key; forgot ntp authenticate on one end Verify: both ends have ntp authenticate; same key ID and password; ntp trusted-key [n]; server is referenced with key [n] appended
reach column shows values like 377, 177, 077 (not all 377) Some NTP polls are failing — intermittent connectivity to NTP server; packet loss The reach column is an octal representation of the last 8 polls (1=success, 0=fail); 377 (binary 11111111) = all 8 successful; 377 dropping to 177 (11111111 → 01111111) means the most recent poll failed; investigate link quality or firewall

12. NTP vs SNTP vs PTP

Feature NTP (v4) SNTP PTP (IEEE 1588)
Precision ±1ms over LAN; ±50ms over WAN ±100ms or worse Sub-microsecond (nanoseconds with hardware timestamping)
Complexity Moderate — uses multiple servers, Marzullo's algorithm, clock filtering Simple — single server, basic request/response High — requires PTP-aware hardware and network switches
Algorithm Complex filtering, clock discipline, clock selection algorithm Basic: takes the server's time directly without filtering Hardware timestamping at the physical layer; best master clock algorithm
Transport UDP port 123 UDP port 123 UDP port 319 (event), 320 (general); also Ethernet multicast
Use case Standard for all network devices — routers, switches, servers, workstations IoT devices, embedded systems, simple clients where complexity is undesirable Financial trading, industrial automation, telecom (5G), power grid synchronisation
Cisco IOS support Full support — ntp server, ntp master, ntp authenticate Clients only (simplified mode) Supported on specific Cisco platforms with hardware timestamping

13. Complete Enterprise NTP Deployment Example

  Network: Corporate with HQ and branch offices.

  Design:
  HQ core router (192.168.1.1) = internal NTP server (Stratum 3)
  Branch routers                = NTP clients pointing to HQ router
  All servers and devices       = NTP clients

  ── HQ Core Router (NTP Server) ───────────────────────────────────────
  HQRouter(config)# ntp server pool.ntp.org prefer
  HQRouter(config)# ntp server time.google.com
  HQRouter(config)# ntp master 3
  HQRouter(config)# ntp update-calendar
  HQRouter(config)# ntp authenticate
  HQRouter(config)# ntp authentication-key 1 md5 Corp@NTP2025
  HQRouter(config)# ntp trusted-key 1
  HQRouter(config)# service timestamps log datetime msec

  ── Branch Routers (NTP Clients) ──────────────────────────────────────
  BranchRouter(config)# ntp server 192.168.1.1 key 1 prefer
  BranchRouter(config)# ntp server 192.168.1.2 key 1      ! secondary
  BranchRouter(config)# ntp authenticate
  BranchRouter(config)# ntp authentication-key 1 md5 Corp@NTP2025
  BranchRouter(config)# ntp trusted-key 1
  BranchRouter(config)# ntp update-calendar
  BranchRouter(config)# service timestamps log datetime msec

  ── Syslog server / Linux (NTP Client) ───────────────────────────────
  # /etc/chrony/chrony.conf:
  server 192.168.1.1 iburst prefer
  server 192.168.1.2 iburst

  ── Verification on all devices ───────────────────────────────────────
  Cisco: show ntp status        → confirm "synchronised", stratum 3 or 4
         show ntp associations  → confirm * on the HQ router entry, reach=377
  Linux: chronyc tracking       → confirm "System time: X seconds fast/slow"
         chronyc sources -v     → confirm * on the server entry

14. Exam Tips & Key Points

  • NTP uses UDP port 123 exclusively. It is connectionless for efficiency — time queries do not need the overhead of TCP connection establishment.
  • Know the stratum hierarchy: Stratum 0 = atomic clock/GPS (not on network); Stratum 1 = primary NTP servers directly connected to Stratum 0 (e.g., pool.ntp.org); Stratum 2 = syncs to Stratum 1; Stratum 16 = unsynchronised (clock is unreliable).
  • Cisco client command: ntp server [IP]. Cisco server command: ntp master [stratum]. Know the difference — ntp master makes the device serve time to others from its own clock.
  • ntp update-calendar synchronises the hardware (battery-backed NVRAM) clock with the software clock — important for correct time on reload before NTP re-syncs.
  • The prefer keyword on ntp server marks the preferred source when multiple servers are configured. The router still polls all servers but weights the preferred one higher.
  • iburst on client configuration sends a rapid burst of 8 packets on startup for fast initial synchronisation — reduces time to first sync from minutes to seconds.
  • NTP authentication uses MD5 shared keys: ntp authenticate → ntp authentication-key [n] md5 [key] → ntp trusted-key [n] → ntp server [IP] key [n]. All four commands required.
  • In show ntp associations: asterisk (*) = currently selected source; reach 377 = all recent polls successful; reach 0 = NTP server not reachable; stratum 16 = server is not synchronised.
  • In show ntp status: "synchronised" = good; "unsynchronised" = no valid source; stratum 16 = same problem; offset should be small (milliseconds).
  • Disable broadcast mode (no ntp broadcast) and restrict UDP/123 to trusted sources for NTP security. Enable MD5 authentication to prevent time spoofing.
  • NTP vs SNTP: NTP uses complex filtering and clock discipline algorithms for ±1ms accuracy; SNTP is simpler with ±100ms accuracy for IoT/embedded use. Both use UDP/123.

15. Summary Reference Table

Topic Key Detail
NTP transport UDP port 123
NTP accuracy ±1ms over LAN; ±50ms over WAN
Stratum 0 Physical reference (GPS, atomic) — not on network
Stratum 1 Primary NTP server (directly connected to Stratum 0)
Stratum 16 Unsynchronised — clock is unreliable
Cisco NTP client ntp server [IP] [prefer]
Cisco NTP server ntp master [stratum]
Sync hardware clock ntp update-calendar
Fast initial sync iburst option on ntp server line
NTP authentication ntp authenticate + ntp authentication-key + ntp trusted-key + ntp server [IP] key [n]
Verify Cisco NTP show ntp status + show ntp associations
Verify Linux NTP chronyc tracking + chronyc sources -v
reach=377 All 8 recent NTP polls successful — server reachable
Security: disable broadcast no ntp broadcast

NTP Quiz

1. What is the primary purpose of NTP, and why is accurate time critical for network security protocols like Kerberos?

Correct answer is B. NTP (Network Time Protocol) synchronises the clocks of computers and network devices to within milliseconds of a reference time source. This has several critical consequences beyond mere convenience. Security protocols: Kerberos (the authentication protocol used in Windows Active Directory) issues tickets with embedded timestamps and validates that the ticket is being used within an acceptable time window (default: 5 minutes from issuance). If a client's clock is more than 5 minutes off from the domain controller, authentication fails — users cannot log in, even with correct credentials. TLS certificates also have validity periods validated against the current time. Log correlation: syslog timestamps across devices must align for meaningful cross-device event correlation during incident response. Compliance: audit frameworks require accurate log timestamps. All of these requirements mean NTP is not optional in any production network.

2. What protocol and port does NTP use, and why is UDP chosen over TCP for time synchronisation?

Correct answer is A. NTP uses UDP port 123 exclusively. The choice of UDP over TCP is deliberate and important. TCP requires a three-way handshake (SYN → SYN-ACK → ACK) before any data is exchanged — this adds variable delay that is difficult to measure precisely. NTP's accuracy depends on measuring the exact round-trip time of its own packets to calculate clock offset; the TCP handshake would introduce additional delay that confounds this measurement. UDP's connectionless nature means NTP packets are sent and received with minimal overhead. NTP accounts for network delay explicitly in its four-timestamp algorithm (recording T1, T2, T3, T4 and calculating round-trip delay and offset from these values). UDP also means less per-packet overhead and better performance at scale when a single NTP server handles thousands of clients simultaneously.

3. In the NTP stratum hierarchy, which stratum represents the physical reference clock (GPS or atomic), and what does a device showing stratum 16 indicate?

Correct answer is C. The NTP stratum hierarchy defines trustworthiness and accuracy distance from an atomic reference. Stratum 0 is the physical reference clock — GPS satellites, caesium atomic clocks, rubidium oscillators, and WWVB radio signals. These are not network-connected directly; they connect to a Stratum 1 server via a hardware interface (RS-232 or PPS signal). Stratum 0 provides nanosecond accuracy. Stratum 1 servers are directly connected to Stratum 0 hardware — examples include time.google.com, pool.ntp.org, and corporate GPS-disciplined appliances. Stratum 2 servers synchronise from Stratum 1. Each subsequent stratum adds 1 and introduces a small amount of additional jitter. Stratum 16 is a special value meaning the device is unsynchronised — it has no valid NTP reference and its clock should not be trusted. A Cisco device shows stratum 16 in show ntp status before it successfully synchronises to an NTP source.

4. What is the typical time synchronisation precision NTP provides over a LAN, and how does this compare to SNTP?

Correct answer is D. NTP achieves its high precision through sophisticated algorithms: it polls multiple NTP servers simultaneously, applies Marzullo's clock selection algorithm to identify and discard outliers (servers reporting significantly different times from the majority), and uses a clock discipline algorithm to gradually adjust the local clock frequency as well as the time value. This discipline of the clock frequency (not just the time) prevents the clock from drifting again between updates. The result is ±1ms accuracy on a LAN and ±50ms on a WAN. SNTP (Simple Network Time Protocol) uses the same UDP/123 port and packet format but implements none of the filtering, selection, or frequency discipline — it simply takes the time from a single server and applies it directly. This gives SNTP ±100ms accuracy, which is adequate for IoT sensors and embedded devices that only need approximate time, but insufficient for security protocols, syslog correlation, or financial systems.

5. Which Cisco IOS command configures a router to act as an NTP server at stratum 5, and what is the important caveat about this command?

Correct answer is C. ntp master [stratum] configures a Cisco router to act as an authoritative NTP server for the network, advertising the specified stratum level to downstream NTP clients. The critical caveat: ntp master does NOT mean the router is connected to an atomic clock or GPS. It means the router will use its own internal software clock as the time source if no external NTP server is available. The internal clock can drift significantly over time (typically 20–100 ppm, meaning seconds per day). If the router's upstream NTP source fails and only ntp master is configured, all downstream clients will receive time from the drifting internal clock — which may be minutes or hours off from real time after days of operation. Best practice: always configure ntp server pool.ntp.org (or another external reference) alongside ntp master. When the external source is reachable, the router syncs from it and serves accurate time; when unreachable, it falls back to its internal clock (ntp master).

6. What does the iburst option do when added to an NTP server configuration, and when is it particularly useful?

Correct answer is B. By default, when an NTP client first contacts a server, it polls at the minimum polling interval (typically 64 seconds initially). It takes multiple successful polls — often 5 to 15 minutes — before the clock selection algorithm is confident enough in the measurements to actually apply a correction and achieve synchronisation. During this period, the device's clock may be significantly off. The iburst option changes this by sending a rapid burst of 8 NTP request packets at 2-second intervals when the connection is first established. This quickly builds up enough statistical measurements to estimate the offset and delay with confidence, reducing the time to first synchronisation to roughly 10 seconds. This is particularly valuable: after a device reboot (when the clock may be wrong for seconds or minutes); for devices with security protocols like Kerberos that immediately need accurate time; and for syslog accuracy where log messages generated in the first few minutes after boot should have correct timestamps.

7. Why is NTP critical for security protocols like Kerberos and two-factor authentication (TOTP), and what happens if the time difference is too large?

Correct answer is A. Several critical authentication mechanisms use time as a core component of their security model. Kerberos (used in Windows Active Directory): tickets contain a timestamp and have a short validity window. When a client presents a ticket, the domain controller checks that the ticket's timestamp is within an acceptable clock skew (default: 5 minutes) of the server's current time. If the client's clock is more than 5 minutes off from the DC's clock, the ticket is rejected with a KRB5KRB_AP_ERR_SKEW error — the user cannot log in, even with correct credentials. TOTP (Time-based One-Time Passwords) — used in authenticator apps like Google Authenticator: codes are calculated using the current time divided into 30-second windows. If the authenticating device's clock differs by more than 30 seconds from the server's clock, the generated code and the expected code are in different time windows and the authentication fails. TLS certificates have valid-from and valid-until dates — a client with a grossly wrong clock may reject valid certificates as "expired" or "not yet valid."

8. In the output of show ntp associations, what does an asterisk (*) prefix mean, and what does a reach value of 377 indicate?

Correct answer is C. The show ntp associations output uses symbol prefixes and octal reach values that must be decoded. Symbol prefixes: * (asterisk) = currently selected peer — this is the NTP source the router is actively synchronised to; + = acceptable peer that the algorithm considers valid but is not currently selected (would take over if the * peer fails); - = rejected by the clock selection algorithm; x = declared a false ticker (outlier). Reach column: this is an octal (base 8) shift register representing the last 8 NTP polls. Each poll that receives a response is a 1 bit; each failed poll is a 0 bit. The register shifts left with each poll. 377 in octal = 11111111 in binary = all 8 most recent polls succeeded — the server is consistently reachable. 177 octal = 01111111 = the most recent poll failed (1 miss out of 8). 0 = 00000000 = all recent polls failed — server is completely unreachable.

9. What is the most important firewall security control for NTP, and why should NTP broadcast mode be disabled?

Correct answer is D. Restricting UDP/123 to trusted source IPs is the most fundamental NTP security control. Without this: (1) NTP spoofing — an attacker can send crafted NTP responses from a rogue server, shifting the target device's clock. A shifted clock can cause Kerberos authentication failures, invalidate TLS certificates, make log correlation impossible, and potentially allow replay attacks against time-windowed tokens. Mitigation: firewall rules restricting UDP/123 inbound to only the IP of the trusted NTP server; plus MD5 authentication (so the device only accepts time from authenticated sources). (2) NTP amplification DDoS — open NTP servers can be abused to amplify traffic. Mitigation: restrict UDP/123 access. NTP broadcast mode (no ntp broadcast): broadcast NTP sends time updates to the entire subnet broadcast address without requiring client authentication. Any host on the same LAN segment can inject a forged NTP broadcast packet to shift the clocks of all listening devices simultaneously. This is a man-in-the-middle attack vector that is completely prevented by disabling broadcast mode and using unicast NTP with authentication instead.

10. What is the difference between NTP and SNTP, and in what contexts should each be used?

Correct answer is B. NTP and SNTP both use UDP port 123 and the same packet format — they are not distinguished by transport. The difference is in the implementation sophistication. NTP (RFC 5905) implements: clock selection algorithms that poll multiple servers and discard outliers; clock filtering that maintains a window of recent samples; clock discipline that adjusts both the time offset AND the clock frequency (preventing future drift); and Marzullo's algorithm for identifying the true time from multiple conflicting sources. This complexity achieves ±1ms accuracy on a LAN. SNTP (Simple NTP, RFC 4330) is a deliberate simplification: it uses the same packet format to query a single NTP server and applies the received time directly — no filtering, no frequency discipline, no multiple-server comparison. This makes SNTP code very small and suitable for microcontrollers and IoT devices where code space is limited and ±100ms accuracy is entirely adequate (temperature sensors, smart meters, simple logging). For Cisco routers, switches, Linux servers, and any device involved in security, syslog, or financial operations, full NTP is required.

← Back to Home