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.

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 Polling Intervals

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	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.

Windows NTP Configuration

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

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

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

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

A. To encrypt network communications — NTP establishes shared session keys between network devices for secure data transmission B. To synchronise clocks across network devices to within milliseconds — Kerberos and TLS embed timestamps in authentication tokens and actively reject connections if the time difference between client and server exceeds a threshold (Kerberos default: 5 minutes), making clock accuracy a functional security requirement C. To manage IP address assignments — NTP ensures DHCP leases align with accurate time to prevent address conflicts D. To block unauthorised devices — NTP validates device identity before granting network access

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.

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

A. UDP port 123 — UDP is chosen because it is connectionless with no handshake overhead; TCP connection setup delay would itself introduce time measurement error, undermining the accuracy NTP is trying to achieve B. TCP port 123 — TCP is used because guaranteed delivery ensures time packets never arrive out of order or be lost C. UDP port 514 — port 514 is shared between NTP and syslog to reduce firewall configuration complexity D. TCP port 514 — NTP uses the same secure connection mechanism as syslog for reliable time delivery

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.

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

A. Stratum 1 is the physical reference; stratum 16 means the device is at the maximum network distance from the reference clock B. Stratum 2 is the GPS/atomic reference; stratum 16 indicates the device is configured as a server only and not a client C. Stratum 0 is the physical reference clock (GPS, atomic, radio signal) — not on the network, connected directly to a Stratum 1 server; stratum 16 means the device has no valid NTP source and its clock is considered unsynchronised and unreliable D. Stratum 3 is the atomic clock level; stratum 16 indicates maximum NTP precision is being achieved

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.

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

A. NTP provides ±100 millisecond precision — the same as SNTP; the two protocols use identical algorithms but different port numbers B. NTP provides ±1 second precision; SNTP provides better ±100 millisecond precision by using a simpler, faster algorithm C. NTP provides ±10 second precision; SNTP is identical but limited to embedded devices D. NTP provides ±1 millisecond precision over a LAN using complex clock filtering and discipline algorithms; SNTP provides ±100 millisecond or worse accuracy using a simpler single-server basic request/response — NTP is for enterprise use; SNTP for IoT and embedded devices

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.

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?

A. ntp server 192.168.1.1 — this points to the upstream NTP server and automatically makes the router a Stratum 5 server to downstream clients B. ntp authenticate — enabling authentication promotes the router to act as a trusted NTP server at the next available stratum C. ntp master 5 — the caveat is that this command makes the router use its own internal clock if it cannot reach any external NTP server, so if the internal clock drifts, all clients receive wrong time; best practice is to also configure ntp server [external] so the router prefers the external source when available D. ntp update-calendar — this synchronises the router's hardware clock and simultaneously designates it as the primary NTP reference for the network

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).

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

A. iburst controls the stratum level that the NTP server advertises — setting iburst=5 is equivalent to ntp master 5 B. iburst sends a burst of 8 packets at 2-second intervals when first connecting to an NTP server instead of waiting for the standard polling interval — it reduces the time to achieve initial synchronisation from 5–15 minutes down to approximately 10 seconds, making it especially useful after a device reboot C. iburst increases the NTP polling interval from 64 seconds to 1024 seconds to reduce network traffic during stable sync periods D. iburst enables broadcast mode where the NTP server pushes time updates to all clients automatically without waiting for client requests

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.

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

A. These protocols embed timestamps in authentication tokens and validate them against the current time — Kerberos tickets become invalid if the client-server clock skew exceeds 5 minutes (default), causing authentication failure; TOTP codes are time-based and fail immediately if clocks are out of sync by more than 30 seconds B. NTP encrypts authentication messages — it provides the encryption layer that protects Kerberos and TOTP packets in transit C. NTP blocks unauthorised access by verifying device identity before authentication tokens are issued D. NTP manages user passwords — it synchronises password hash databases across domain controllers to ensure consistent authentication

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."

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

A. Asterisk (*) means the server is rejecting this router's requests; reach 377 indicates 377 failed attempts to contact the server B. ntpstat command on Linux is the equivalent — it replaces show ntp associations on modern Cisco devices running IOS-XE C. Asterisk (*) means this is the currently selected (synced) NTP peer — the active time source; reach 377 is an octal value representing the last 8 polls as binary bits (11111111) meaning all 8 recent polls succeeded; reach 0 means no polls succeeded (server unreachable) D. chronyc tracking command on Linux — this Linux command provides identical output to Cisco's show ntp associations and should be cross-referenced for troubleshooting

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.

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

A. Allow NTP broadcast mode — this ensures all devices receive time updates simultaneously without unicast polling overhead B. Disable authentication — simpler configurations are less likely to fail and cause time sync outages C. Use only public NTP servers — public servers are more secure than internal servers because they are managed by large organisations with dedicated security teams D. Restrict UDP 123 access to trusted hosts only — prevents NTP spoofing attacks (where an attacker sends false time to shift clocks) and NTP amplification DDoS attacks (where open NTP servers are used to amplify traffic); disable broadcast mode because unauthenticated broadcast time updates can be injected by any device on the LAN segment

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.

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

A. NTP is less accurate than SNTP — NTP's complex algorithms introduce processing delay that reduces its accuracy compared to SNTP's simpler direct approach B. NTP uses complex clock filtering, selection algorithms, and frequency discipline for ±1ms precision — use for enterprise devices, security protocols, syslog; SNTP is simplified (single-server, no filtering) achieving ±100ms — appropriate for IoT and embedded devices where code size and complexity must be minimal C. NTP uses TCP; SNTP uses UDP — the transport protocol difference determines the use case, with SNTP suitable for time-critical real-time systems due to UDP's lower overhead D. NTP is deprecated in modern networks; SNTP is the modern replacement with improved security through built-in TLS encryption and digital certificate-based server authentication

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.