NTP – Network Time Protocol Overview

1. What Is NTP and Why Does Time Synchronisation Matter?

NTP (Network Time Protocol), defined in RFC 5905, is the standard protocol used to synchronise the clocks of network devices — routers, switches, servers, firewalls, and workstations — to a common time source. NTP has been in continuous use since 1985, making it one of the oldest internet protocols still widely deployed.

Accurate time is not merely a convenience — it is a security and operational necessity. Many critical network functions break silently or become untrustworthy when device clocks drift apart by even a few minutes. The consequences of poor time synchronisation span security, compliance, troubleshooting, and authentication systems.

System / Function	Why It Needs Accurate Time	Consequence of Time Drift
Syslog / Event Logs	Every log message carries a timestamp. Correlation of events across multiple devices requires all timestamps to be from the same clock reference.	Log entries appear out of sequence. Security events are impossible to correlate. Forensic analysis is unreliable. Compliance audit trails fail.
PKI / TLS Certificates	Digital certificates have a `notBefore` and `notAfter` validity window. Certificate validation checks the current time against these fields.	A certificate may appear expired (or not yet valid) simply because the verifying device's clock is wrong — causing HTTPS, 802.1X, and VPN authentication failures.
Kerberos Authentication	Kerberos tickets include timestamps and are only valid within ±5 minutes of the issuing server's clock by default (the "skew" window).	If a client or server clock drifts beyond 5 minutes, Kerberos authentication fails entirely — locking users out of Active Directory, VPN, and all Kerberos-protected services.
Scheduled Tasks / Backups	Cron jobs, backup windows, and maintenance windows are all time-triggered.	Jobs run at wrong times or duplicate; backup windows overlap with production hours.
Network Troubleshooting	Correlating syslog messages, debug outputs, and SNMP traps from multiple devices requires consistent timestamps.	An error on Router A at 10:00:01 and a corresponding error on Switch B at 09:58:45 appear unrelated unless both devices share the same time reference.
Financial Transactions / MiFID II	Regulatory requirements mandate millisecond-accurate timestamps on financial trades.	Compliance violations; potential fines; inability to reconstruct trade sequences.
DNSSEC / RPKI	DNS Security Extensions and Route Origin Validation use signed records with validity windows.	Signature validation fails on devices with wrong clocks, breaking DNS and BGP security.

2. NTP Stratum Levels

NTP organises time sources into a hierarchy using a concept called stratum. The stratum number indicates how many hops a device is from a definitive time reference (an atomic clock or GPS receiver). Stratum values range from 0 to 15, where lower is better. A stratum value of 16 is special — it means the device is unsynchronised and its time should not be trusted.

  NTP stratum hierarchy:

  Stratum 0 — Reference Clock (not on the network)
  ┌──────────────────────────────────────────────────────────┐
  │  Atomic clocks, GPS receivers, CDMA/radio time signals   │
  │  These are the ultimate source of truth — never drifts   │
  │  Not an NTP device; connected directly to Stratum 1 via  │
  │  a hardware interface (GPS antenna, PPS signal, etc.)    │
  └──────────────────────────────────────────────────────────┘
                           │
                           ▼
  Stratum 1 — Primary Time Servers
  ┌──────────────────────────────────────────────────────────┐
  │  Servers directly connected to a Stratum 0 reference     │
  │  Examples: time.nist.gov, time.google.com, GPS-connected │
  │  enterprise NTP servers                                  │
  │  Accuracy: typically ≤ 1 microsecond from UTC            │
  └──────────────────────────────────────────────────────────┘
                           │
                           ▼
  Stratum 2 — Secondary Time Servers
  ┌──────────────────────────────────────────────────────────┐
  │  Servers that synchronise from Stratum 1 over the        │
  │  network. Enterprise NTP servers typically operate here. │
  │  Accuracy: a few milliseconds from UTC                   │
  └──────────────────────────────────────────────────────────┘
                           │
                           ▼
  Stratum 3 — Tertiary Servers / Client Devices
  ┌──────────────────────────────────────────────────────────┐
  │  Routers, switches, and servers that sync from Stratum 2 │
  │  These can also serve NTP to downstream clients          │
  └──────────────────────────────────────────────────────────┘
                    │               │
                    ▼               ▼
  Stratum 4+ — Edge Devices / End Clients
  (accuracy degrades slightly with each hop, but remains
   adequate for all practical network purposes up to Stratum 15)

Stratum	Meaning	Examples
0	Reference clock — directly connected hardware time source	GPS receiver, atomic clock, CDMA signal
1	Primary NTP server — directly connected to stratum 0	NIST time servers, Google Public NTP, enterprise GPS NTP appliances
2	Synchronised from a stratum 1 server	Enterprise NTP distribution servers, ISP NTP servers
3–14	Each level synchronised from the level above	Routers, switches, internal servers, workstations
15	Lowest valid stratum — technically synchronised but very far from reference	Rarely used in practice — devices typically not permitted to sync from stratum 15
16	Unsynchronised — clock is not trusted	A device that has lost its NTP sync or has never synchronised

CCNA exam tip: Stratum 0 devices are reference clocks, not network devices — they have no IP address and do not participate in NTP directly. A Cisco router configured with ntp master operates at stratum 8 by default (configurable) and acts as an authoritative NTP server for the network even without a connection to an external time source. The stratum number represents proximity to an authoritative reference — lower is better, 16 means unsynchronised.

3. NTP Roles — Server, Client, and Peer

NTP defines three operational roles that a device can play in a time-synchronisation topology. Understanding these roles — and how they differ — is important for both the CCNA exam and real-world NTP design.

3.1 NTP Server

An NTP server provides time to NTP clients. It responds to client requests with its current time. The server's time may itself be synchronised from an upstream NTP server (a higher-stratum source) or derived from a local reference clock. An NTP server does not synchronise its own clock from its clients.

  NTP server role:

  [External NTP Server — Stratum 2] ──NTP sync──► [Enterprise Core Router — Stratum 3]
                                                          │
                                              serves NTP to clients
                                                          │
                              ┌───────────────────────────┤
                              ▼                           ▼
                       [Branch Router — Stratum 4]  [Server — Stratum 4]
                              │
                              ▼
                       [PC / Workstation — Stratum 5]

  The Enterprise Core Router is simultaneously a CLIENT of the external
  server AND a SERVER to its downstream devices.

3.2 NTP Client

An NTP client requests time from one or more NTP servers and adjusts its local clock to match. A pure NTP client does not serve time to any other device. Most end-user devices (PCs, printers) and network devices that only need to synchronise (not redistribute) time operate as NTP clients.

3.3 NTP Peer

Two devices configured as NTP peers synchronise with each other bidirectionally. Both devices exchange time information and can use each other as references. Peering is typically used between NTP servers at the same stratum level for redundancy — if one loses its upstream reference, the other can continue to provide synchronised time, and the two devices will agree on a common time between themselves.

  NTP peering for redundancy:

  [Stratum 1 External Server A] ──► [Core Router 1 — Stratum 2]
  [Stratum 1 External Server B] ──► [Core Router 2 — Stratum 2]
                                             │
                              NTP Peer relationship ←──────────►
                                             │
  Core Router 1 ◄────────────── peer ──────────────────► Core Router 2

  If the upstream server for Router 1 fails:
  → Router 1 is no longer synchronised to an external source
  → Router 1 and Router 2 peer with each other
  → Router 2 (still sync'd to Stratum 1) shares its time with Router 1
  → Both routers maintain accurate time via peering

Role	Sends Time	Receives Time	Cisco IOS Command	Typical Use
Server	Yes — to clients	Yes — from upstream (or local ref)	`ntp master <stratum>`	Core router or dedicated NTP appliance serving the enterprise
Client	No	Yes — from configured server(s)	`ntp server <IP>`	Branch routers, switches, servers, end devices
Peer	Yes — bidirectional	Yes — bidirectional	`ntp peer <IP>`	Redundant NTP distribution servers at the same level

4. How NTP Works — The Synchronisation Process

NTP uses UDP port 123 (see Common Port Numbers) for all communications. The client sends a query to the server, which responds with its current timestamp. The client uses a statistical algorithm to calculate the offset between its clock and the server's, and gradually slews (adjusts) its clock to match — rather than jumping abruptly, which could cause problems for time-sensitive applications.

  NTP timestamp exchange — four timestamps per query:

  Client                             Server
  ──────                             ──────
  T1: Client sends request at T1
  ──── NTP Query (T1 timestamp) ────►
                                     T2: Server receives at T2
                                     T3: Server sends response at T3
  ◄─── NTP Response (T2, T3) ────────
  T4: Client receives at T4

  Calculations:
  Round-trip delay = (T4 – T1) – (T3 – T2)
  Clock offset     = [(T2 – T1) + (T3 – T4)] / 2

  The client uses the offset to adjust its clock:
  → If offset is small (< ~128 ms): clock is slewed (gradually adjusted)
  → If offset is large (> ~128 ms): clock is stepped (jumped immediately)
    (only done at startup or if drift becomes very large)

  NTP continuously repeats this process, typically every 64–1024
  seconds, and maintains a statistical model of clock drift to
  predict and compensate for the local oscillator's tendency to
  drift over time.

NTP Accuracy and Polling

Parameter	Default / Typical Value	Description
Polling interval	64 seconds (initial) to 1024 seconds (steady state)	How often the client queries the server. NTP adapts the interval — more frequent when drift is detected, less frequent when stable
UDP port	123	Both source and destination port for NTP
Typical accuracy	1–50 ms over internet; <1 ms over LAN	Depends on network latency and stability of the path to the NTP server
Clock slew rate	~0.5 ms/second (500 ppm)	Maximum rate at which NTP adjusts the clock — prevents sudden time jumps that would break applications
Panic threshold	1000 seconds (default)	If offset exceeds this, ntpd exits rather than making a huge correction — requires manual intervention or `-g` flag override

5. NTP Authentication

Without authentication, an NTP client has no way to verify that the time it is receiving comes from a legitimate and trusted source. An attacker on the network could send spoofed NTP responses to a device, causing it to adopt a completely wrong time — breaking certificates, Kerberos, and log correlation while potentially hiding attack activity by moving timestamps. NTP authentication prevents this by requiring NTP messages to be signed with a shared key.

Cisco IOS supports MD5-based NTP authentication. Both the server and the client must be configured with the same key number and key value, and must both trust that key. When authentication is enabled, the client will only accept time from servers that can prove they know the shared key.

  NTP MD5 authentication — how it works:

  Shared secret key: key-id 1, key-string "Sup3rS3cr3t!"

  Server sends NTP packet with:
  → Time value
  → Key-id: 1
  → MD5 hash of (time value + key string)

  Client receives NTP packet:
  → Client looks up key-id 1 in its local key table
  → Client computes MD5(time value + its local key string)
  → If computed hash matches received hash: time is TRUSTED → accepted
  → If hash does not match: packet is REJECTED → no time update

  An attacker without the key cannot forge a valid MD5 hash.
  Even if the attacker intercepts a legitimate packet, modifying
  the time value will invalidate the hash.

NTP Authentication Configuration — Cisco IOS

  ! ── NTP SERVER configuration (authenticating) ──────────────────
  Router-Server(config)# ntp authenticate
  ! Enables NTP authentication globally

  Router-Server(config)# ntp authentication-key 1 md5 Sup3rS3cr3t
  ! Creates key-id 1 with MD5 hash of "Sup3rS3cr3t"
  ! Key string is stored encrypted in the running config

  Router-Server(config)# ntp trusted-key 1
  ! Marks key 1 as trusted — server will use this key to sign responses

  Router-Server(config)# ntp master 3
  ! Configures this router as an NTP master at stratum 3
  ! (Optional if router syncs from upstream — ntp master is for
  !  operating as an authoritative source with no upstream server)


  ! ── NTP CLIENT configuration (authenticating) ──────────────────
  Router-Client(config)# ntp authenticate
  Router-Client(config)# ntp authentication-key 1 md5 Sup3rS3cr3t
  Router-Client(config)# ntp trusted-key 1
  Router-Client(config)# ntp server 10.0.0.1 key 1
  ! Sync from 10.0.0.1 using key-id 1 for authentication
  ! Client will ONLY accept time from 10.0.0.1 if it uses key 1

NTPsec and NTP version 4: MD5 authentication is supported in NTP version 3 and 4. For higher security, NTPsec (a hardened NTP implementation) and some platforms support stronger MAC algorithms (SHA-256, AES-CMAC). In CCNA scope, MD5 authentication is the primary method to know.

6. Cisco IOS NTP Configuration

The following section covers the full range of Cisco IOS NTP configuration commands — from basic client sync to acting as a master server, configuring peers, and restricting which devices can query the router's NTP service.

6.1 Basic NTP Client — Synchronise from an External Server

  ! Configure the router to synchronise its clock from a public NTP server:
  Router(config)# ntp server 216.239.35.0
  ! Google Public NTP — stratum 1/2 server

  ! Configure a second NTP server for redundancy (prefer the first):
  Router(config)# ntp server 216.239.35.4 prefer
  ! 'prefer' tells the router to use this server first if reachable

  ! (Optional) Set the timezone and daylight saving time:
  Router(config)# clock timezone GST 4
  ! GST = Gulf Standard Time, UTC+4
  Router(config)# clock summer-time GST recurring
  ! Enables automatic DST adjustment

  ! Verify synchronisation:
  Router# show ntp status
  Router# show ntp associations

6.2 NTP Master — Router Acts as Authoritative NTP Server

  ! Configure the router as a local NTP master (internal authoritative server):
  Router(config)# ntp master 3
  ! Stratum 3 — this router serves time to clients at stratum 4+
  ! Use this when the router has no upstream NTP server but must
  ! serve as the time reference for internal devices.

  ! WARNING: ntp master means the router uses its own hardware clock
  ! as the time reference. If the hardware clock drifts (and it will),
  ! all downstream devices will drift with it. Always prefer syncing
  ! to an external authoritative source if internet access is available.

  ! Best practice: sync the router from an external server AND use
  ! ntp master as a fallback:
  Router(config)# ntp server 216.239.35.0
  Router(config)# ntp master 7
  ! If the external server is unreachable, fall back to internal clock
  ! at stratum 7 (high stratum discourages clients from using this
  ! as primary unless no better source is available)

6.3 NTP Peer Configuration

  ! Configure a symmetric peer relationship for redundancy:
  ! (Both routers run this config pointing to each other)

  Router-1(config)# ntp server 203.0.113.10          (upstream Stratum 2)
  Router-1(config)# ntp peer   10.0.0.2              (peer with Router-2)

  Router-2(config)# ntp server 203.0.113.20          (upstream Stratum 2)
  Router-2(config)# ntp peer   10.0.0.1              (peer with Router-1)

  ! Both routers sync from their respective upstream sources.
  ! They also peer with each other — if one upstream fails, the
  ! other can maintain sync via the peer relationship.

6.4 Source Interface — Ensuring Consistent NTP Identity

  ! Lock NTP packets to a specific source interface (loopback recommended):
  Router(config)# ntp source Loopback0
  ! NTP packets originate from the loopback address regardless of
  ! which physical interface routes the packet.
  ! Using a loopback ensures NTP works even if a physical WAN link fails.
  ! NTP servers/peers must allow this source IP in their access control.

6.5 NTP Access Control — Restricting Who Can Query

  ! Restrict NTP access using access-groups (see ACL Overview):
  Router(config)# access-list 10 permit 192.168.0.0 0.0.255.255
  ! ACL 10 permits the corporate network

  Router(config)# ntp access-group serve 10
  ! Only devices matching ACL 10 can query this router's NTP service.
  ! Prevents external parties from using your router as a public NTP server.

  ! NTP access-group options:
  ! peer    — allows full NTP associations (peer + serve + query)
  ! serve   — allows time synchronisation queries only
  ! query-only — allows ntpq/ntpdc queries but not time sync
  ! serve-only — time sync allowed, peer associations not allowed

7. NTP Verification Commands

  ! Show the current NTP synchronisation status:
  Router# show ntp status

  Clock is synchronized, stratum 3, reference is 216.239.35.0
  nominal freq is 250.0000 Hz, actual freq is 250.0002 Hz, precision is 2**18
  ntp uptime is 86400 (1/100 of seconds), resolution is 4000
  reference time is E3B8A7D2.1A2B3C4D (12:00:00.102 UTC Tue Mar 17 2026)
  clock offset is 0.5523 msec, root delay is 8.7500 msec
  root dispersion is 48.8281 msec, peer dispersion is 1.3750 msec
  loopfilter state is 'CTRL' (Normal Controlled Loop), drift is 0.0001234567 s/s
  system poll interval is 64, last update was 42 sec ago.

  Key output fields:
  "synchronized"   → The router's clock IS synchronised to NTP ✔
  "stratum 3"      → This router is 3 hops from an atomic clock
  "reference is"   → IP address of the NTP server it is syncing from
  "clock offset"   → How far off the local clock is from the server
                     (0.5523 ms in this example — excellent)
  "root delay"     → Round-trip delay to the primary reference source

  ! Show all configured NTP associations:
  Router# show ntp associations

  address         ref clock       st   when   poll reach  delay  offset  disp
  *~216.239.35.0  .GOOG.           1     27     64   377   8.75   0.552   1.37
   ~216.239.35.4  .GOOG.           1    100     64   377   9.20   0.891   1.42

  Column meanings:
  *  = currently selected (synced) source — primary
  +  = valid candidate (good, not currently selected)
  ~  = configured server (not peer)
  x  = false ticker (rejected — unreliable)
  -  = outlier (not used)

  ref clock = the server's own reference (e.g., .GOOG. = GPS via Google)
  st        = stratum of the server
  when      = seconds since last packet received
  poll      = current polling interval (seconds)
  reach     = octal bitmask — 377 = all 8 last polls received (perfect)
  delay     = round-trip delay to server (ms)
  offset    = clock offset vs server (ms) — lower is better
  disp      = dispersion / uncertainty (ms)

  ! Show the hardware clock (independent of NTP software clock):
  Router# show clock detail

  12:00:42.731 UTC Tue Mar 17 2026
  Time source is NTP
  .12:00:42.731 UTC Tue Mar 17 2026

  ! Show NTP configuration summary:
  Router# show running-config | include ntp

  ntp authenticate
  ntp authentication-key 1 md5 070C285F4D06 7  (key shown encrypted)
  ntp trusted-key 1
  ntp server 216.239.35.0 prefer
  ntp server 216.239.35.4
  ntp source Loopback0
  ntp master 7

Reach field — 377 is good: The reach field in show ntp associations is an octal bitmask of the last 8 poll results. A value of 377 (octal) means all 8 of the last 8 polls received a valid response — perfect reachability. Lower values indicate dropped packets. A value of 0 means no recent responses received.

8. NTP Design — Enterprise Best Practices

A well-designed NTP hierarchy ensures that all network devices share an accurate, consistent time reference, even if individual servers or network links fail. The following guidelines reflect enterprise best practices for NTP deployment.

  Recommended enterprise NTP hierarchy:

  ┌─────────────────────────────────────────────────────────────────┐
  │  External Sources (Stratum 1)                                   │
  │  time.cloudflare.com, time.google.com, pool.ntp.org             │
  └─────────────────┬───────────────────────────────────────────────┘
                    │  (2–4 external Stratum 1/2 sources for redundancy)
                    ▼
  ┌─────────────────────────────────────────────────────────────────┐
  │  Internal NTP Distribution Servers (Stratum 2–3)                │
  │  Typically 2–4 dedicated servers or core routers                │
  │  • Peer with each other for redundancy                          │
  │  • Source: Loopback interfaces                                  │
  │  • Authentication: MD5 keys shared with all clients             │
  └─────────────────┬───────────────────────────────────────────────┘
                    │  (serve all internal devices)
                    ▼
  ┌─────────────────────────────────────────────────────────────────┐
  │  Internal Clients (Stratum 3–5)                                 │
  │  Routers, switches, firewalls, servers, workstations            │
  │  • Configure 2 NTP servers for redundancy                       │
  │  • Enable authentication (ntp server x.x.x.x key 1)            │
  └─────────────────────────────────────────────────────────────────┘

Best Practice	Reason
Configure at least 2 NTP servers on every device	Redundancy — if one server is unreachable, the device continues synchronising from the other
Use a loopback interface as the NTP source	Loopback interfaces are always up as long as the router is running — NTP identity remains consistent even if a physical WAN link fails
Enable NTP authentication on all internal servers and clients	Prevents rogue NTP servers or man-in-the-middle attacks from poisoning device clocks
Use pool.ntp.org or vendor public NTP servers as external sources	Free, anycast-based, and highly redundant — Google (time.google.com), Cloudflare (time.cloudflare.com), and NIST (time.nist.gov) are common enterprise choices
Restrict NTP queries with access-groups	Prevents external devices from using internal infrastructure as a public NTP service; protects against NTP amplification DDoS attacks
Set timezone and DST on all devices	Log messages are far more readable in local time; ensures scheduled tasks run at correct local times
Configure `ntp master` at high stratum as fallback only	Internal master is better than unsynchronised but worse than external reference; high stratum (e.g., 7–8) discourages clients from preferring it over proper external servers

9. NTP Troubleshooting

9.1 Common NTP Problems and Solutions

Symptom	Likely Cause	Diagnostic / Fix
`show ntp status` shows "Clock is unsynchronised"	NTP server not reachable; wrong server IP; UDP 123 blocked by firewall; authentication mismatch	Ping the NTP server from the router; check firewall rules for UDP 123; verify authentication keys match; check `show ntp associations` for status
`reach` shows 0 in `show ntp associations`	No NTP responses received from the server — network connectivity issue or server is down	Verify routing to NTP server; check UDP 123 is permitted; try `debug ntp packets`
NTP sync appears in `show ntp status` but logs still have wrong timestamps	Timezone or summer-time not configured; router synced to correct UTC but logs displaying UTC not local time	Configure `clock timezone` and optionally `clock summer-time`; reload syslog service
NTP authentication fails — association shows "x" (rejected)	Key mismatch between server and client — different key-id, different key string, or one side has `ntp trusted-key` the other does not	Verify both sides have identical `ntp authentication-key <id> md5 <string>` and matching `ntp trusted-key <id>`; ensure `ntp authenticate` is on both sides
Device was synchronised but lost sync after network change	NTP server IP changed; routing to server lost; ACL now blocking UDP 123	Check `show ntp associations` for * marker; verify reachability to configured NTP servers
Large clock offset — device time is minutes or hours wrong	Device was never synchronised; hardware clock drifted significantly while NTP was down	Set hardware clock manually: `clock set HH:MM:SS DD Month YYYY`; ensure NTP is configured and reachable; NTP will slew the clock gradually to correct time

9.2 NTP Debug Commands

  ! Enable NTP packet debug (shows NTP messages in real time):
  Router# debug ntp packets
  ! WARNING: Can be verbose on busy networks. Use only for
  ! brief targeted troubleshooting.

  ! Enable NTP event debug (shows state changes — less verbose):
  Router# debug ntp events

  ! Disable all debugging:
  Router# no debug all
  ! or:
  Router# undebug all

  ! Manually set the clock (before NTP synchronises):
  Router# clock set 12:00:00 17 March 2026
  ! Sets the software clock — NTP will correct it further

  ! Manually synchronise hardware clock from software clock:
  Router# clock update-calendar
  ! Useful after setting software clock manually to persist across reboot

  ! Read hardware calendar into software clock:
  Router# clock read-calendar

10. NTP vs SNTP — Simplified NTP for Small Devices

SNTP (Simple Network Time Protocol), defined in RFC 4330, is a simplified version of NTP designed for devices that do not require the full complexity and accuracy of the complete NTP algorithm. SNTP uses the same packet format as NTP but implements a simpler client-only model without the sophisticated clock discipline algorithms.

Feature	NTP (Full)	SNTP (Simple)
Protocol version	NTPv4 (RFC 5905)	SNTPv4 (RFC 4330) — same packet format as NTP
Clock discipline algorithm	Full statistical algorithm — tracks drift, jitter, and offset; calculates slew rate	Simplified — typically just applies the offset directly without drift compensation
Server capability	Can act as server, client, or peer	Client only — cannot serve time to other devices
Accuracy	±1 ms (LAN); ±10–50 ms (internet)	±1 second typically — adequate for most IoT and embedded devices
Typical use	Network routers, servers, enterprise devices	Embedded systems, IoT sensors, simple appliances, some layer 2 switches
Interoperability	Full NTP client can sync from NTP or SNTP servers	SNTP can sync from any NTP server — compatible

CCNA exam tip: SNTP is occasionally mentioned but is not the primary focus. Know that SNTP is a simplified, client-only subset of NTP, uses the same packet format, and is used for devices that do not need millisecond accuracy. Full NTP is what Cisco routers and switches implement with the commands covered in this guide.

Test Your Knowledge — NTP Quiz

1. A network administrator notices that syslog messages from different routers appear out of sequence during a security incident investigation. What is the most likely root cause?

A. The syslog server is running out of disk space B. The routers are using different syslog severity levels C. The routers are not synchronised to the same NTP source — each device's clock has drifted independently, so timestamps are inconsistent and events appear out of order D. The syslog protocol does not support timestamps on UDP messages

Correct answer is C. This is one of the most important operational consequences of poor NTP configuration. When routers have independently drifting clocks, their syslog timestamps are meaningless for correlation. An event at Router A timestamped 10:05:00 and a related event at Router B timestamped 09:58:30 appear to be 6.5 minutes apart — when they may have occurred within milliseconds of each other. Consistent NTP synchronisation is the foundation of reliable forensic and operational log analysis. See: Syslog Overview

2. What does NTP stratum 16 indicate about a device?

A. The device is unsynchronised — its clock is not trusted and it should not be used as an NTP time source B. The device is 16 hops from a stratum 0 atomic clock — still valid but the lowest quality C. The device is a stratum 0 GPS reference clock that does not participate in the NTP hierarchy D. Stratum 16 indicates the highest accuracy NTP server

Correct answer is A. Stratum 16 is a special sentinel value in NTP that means the device is unsynchronised. A device at stratum 16 has not been able to establish or maintain sync with any NTP server, and its clock should not be trusted or used as a time source. Other devices will reject time from a stratum 16 source. Valid stratum values are 1 through 15, where lower numbers indicate closer proximity to an authoritative time reference (stratum 0).

3. Why does Kerberos authentication have a strict ±5 minute clock skew requirement, and what happens if devices exceed it?

A. Kerberos uses timestamps to calculate encryption key strength; wider skew weakens the keys B. Kerberos uses timestamps only for logging, so skew just causes inaccurate audit logs C. The 5-minute window is a performance optimisation to reduce ticket validation overhead D. Kerberos tickets contain timestamps and are valid for a limited window to prevent replay attacks. If the client or server clock differs by more than 5 minutes from the KDC, tickets are rejected and authentication fails entirely — locking users out of Active Directory and all Kerberos-protected services

Correct answer is D. Kerberos uses time-stamped tickets as a replay attack defence — a captured ticket can only be replayed within the validity window. If the clock skew between the client, server, and KDC (Key Distribution Centre) exceeds 5 minutes (the default maximum tolerance), the KDC rejects tickets as potentially replayed and returns a KRB_AP_ERR_SKEW error. This immediately prevents all domain logins, access to shared drives, and any other Kerberos-protected service — making NTP synchronisation critical for Active Directory environments.

4. What is the difference between configuring `ntp server` and `ntp peer` on a Cisco router?

A. ntp server is used for IPv6 and ntp peer is used for IPv4 NTP B. ntp server configures the router as a client of the specified server — it only receives time from that server. ntp peer configures a bidirectional symmetric relationship — both devices synchronise with each other and can back each other up if one loses its upstream source C. ntp server configures the router to serve time to a downstream device; ntp peer makes the router a stratum 1 reference D. They are interchangeable — both configure the same NTP association type

Correct answer is B.

ntp server
                  <IP>

configures a client-server (unidirectional) relationship: the router only receives time from the specified server and never sends time to it. ntp peer <IP> configures a symmetric (bidirectional) relationship: both devices exchange time information and can synchronise from each other. Peering is typically used between redundant NTP distribution servers at the same stratum level to maintain consistent time even if one loses its upstream source. See: NTP Configuration Lab

5. What is the purpose of the `ntp master` command on a Cisco router?

A. It designates the router as the primary client that receives time before all other devices on the network B. It configures the router to synchronise from multiple NTP servers simultaneously for redundancy C. It configures the router as an authoritative NTP server that uses its own internal hardware clock as the time reference, allowing it to serve NTP to downstream clients even without an upstream external NTP server D. It forces the router to use stratum 1 regardless of its actual reference source

Correct answer is C. The

ntp master
                  <stratum>

command tells a Cisco router to treat its own hardware clock as an authoritative reference and serve NTP to downstream clients at the specified stratum level (default: 8). This is useful in isolated environments with no internet access, or as a fallback if all external NTP servers become unreachable. The limitation is that the router's hardware clock drifts over time without an external reference, so all downstream devices will drift with it. Always prefer external NTP sources when available.

6. In the output of `show ntp associations`, what does a `reach` value of 377 indicate?

A. All 8 of the last 8 NTP poll responses were received successfully — perfect reachability to that NTP server B. The NTP server is 377 milliseconds away in round-trip time C. 377 is the stratum level of the reference clock D. The router has polled the server 377 times since boot

Correct answer is A. The reach field is an octal bitmask representing the last 8 NTP polls. Each bit is set to 1 if that poll received a valid response, and 0 if it timed out. An octal value of 377 = binary 11111111 — all 8 of the last 8 polls succeeded. A value of 0 means no successful polls recently. A value of 376 (binary 11111110) means the most recent poll failed but the previous 7 succeeded. Always look for 377 to confirm healthy NTP reachability.

7. Why does an NTP client gradually slew its clock instead of jumping immediately to the correct time?

A. Slewing is required by the NTP standard to prevent packet loss B. Jumping the clock would require a router reload to take effect C. Slewing reduces NTP bandwidth consumption D. A sudden clock jump could break time-sensitive applications — TLS sessions, Kerberos tickets, scheduled jobs, and database transactions all depend on monotonically increasing time. Slewing (gradual adjustment at up to ~0.5 ms/second) corrects the clock without disrupting running applications

Correct answer is D. NTP's clock discipline algorithm slews the clock — adjusting it gradually rather than jumping. Suddenly moving the clock backward could cause TLS sessions to appear expired, Kerberos tickets to become invalid, database records to have impossible timestamps, and scheduled jobs to either run twice or not at all. NTP limits the slew rate to approximately 500 parts-per-million (0.5 ms/second). Only when the offset is extremely large (over ~128 ms by default, or at startup) does NTP perform a step (immediate jump).

8. An engineer configures NTP authentication on a client router but the server association shows "x" (false ticker / rejected) in `show ntp associations`. What is the most likely cause?

A. The NTP server is unreachable at the network level B. The NTP authentication key or key string does not match between the server and client — the client receives NTP packets but rejects them because the MD5 hash does not validate against the locally configured key C. The NTP server is at a higher stratum than the client D. The router needs to be reloaded after enabling NTP authentication

Correct answer is B. When NTP authentication is enabled with ntp authenticate and a key is configured with ntp trusted-key, the client verifies the MD5 hash in every received NTP packet. If the key-id or key string doesn't match between the server and client, the hash validation fails and the packet is rejected — shown as "x" in show ntp associations. Check that both sides have identical ntp authentication-key <id> md5 <string> and matching ntp trusted-key <id> entries, and that the server is configured with ntp server <IP> key <id>.

9. A router is configured as an NTP client pointing to an external NTP server. The `show ntp status` output shows the clock is synchronised at stratum 4. What is the stratum of the NTP server the router is syncing from?

A. Stratum 4 — same as the router B. Stratum 5 — one level below the router C. Stratum 3 — the router is always one stratum higher than its reference server D. Stratum 0 — all clients sync from stratum 0 regardless of hops

Correct answer is C. A fundamental NTP rule: a device always operates at one stratum higher than its reference server. If the router shows stratum 4, it is synchronising from a stratum 3 server. If a stratum 2 server synchronises from a stratum 1, and so on up to stratum 0 (the physical reference clock). This additive property means each hop in the NTP hierarchy increases the stratum by 1, reflecting the additional uncertainty introduced by network delay at each level.

10. Which set of commands correctly configures a Cisco router to synchronise from an NTP server at 10.1.1.1 using MD5 authentication with key-id 5 and key string "NTPkey99"?

A. ntp server 10.1.1.1 and ntp key 5 md5 NTPkey99 B. ntp server 10.1.1.1 auth-key 5 and ntp authenticate md5 NTPkey99 C. ntp authentication-key 5 NTPkey99, ntp server 10.1.1.1, and ntp trusted 5 D. ntp authenticate, ntp authentication-key 5 md5 NTPkey99, ntp trusted-key 5, and ntp server 10.1.1.1 key 5

Correct answer is D. All four commands are required for NTP authentication to work correctly: (1) ntp authenticate — globally enables authentication enforcement, (2) ntp authentication-key 5 md5 NTPkey99 — defines key-id 5 with MD5 hash of "NTPkey99", (3) ntp trusted-key 5 — marks key 5 as trusted (without this, even a matching key is not accepted), (4) ntp server 10.1.1.1 key 5 — tells the router to use key 5 when communicating with 10.1.1.1. Omitting any one of these four commands will cause authentication to fail. See: NTP Configuration Lab

← Back to Home

NTP – Network Time Protocol Overview

1. What Is NTP and Why Does Time Synchronisation Matter?

2. NTP Stratum Levels

3. NTP Roles — Server, Client, and Peer

3.1 NTP Server

3.2 NTP Client

3.3 NTP Peer

4. How NTP Works — The Synchronisation Process

NTP Accuracy and Polling

5. NTP Authentication

NTP Authentication Configuration — Cisco IOS

6. Cisco IOS NTP Configuration

6.1 Basic NTP Client — Synchronise from an External Server

6.2 NTP Master — Router Acts as Authoritative NTP Server

6.3 NTP Peer Configuration

6.4 Source Interface — Ensuring Consistent NTP Identity

6.5 NTP Access Control — Restricting Who Can Query

7. NTP Verification Commands

8. NTP Design — Enterprise Best Practices

9. NTP Troubleshooting

9.1 Common NTP Problems and Solutions

9.2 NTP Debug Commands

10. NTP vs SNTP — Simplified NTP for Small Devices

Test Your Knowledge — NTP Quiz

1. A network administrator notices that syslog messages from different routers appear out of sequence during a security incident investigation. What is the most likely root cause?

2. What does NTP stratum 16 indicate about a device?

3. Why does Kerberos authentication have a strict ±5 minute clock skew requirement, and what happens if devices exceed it?

4. What is the difference between configuring ntp server and ntp peer on a Cisco router?

5. What is the purpose of the ntp master command on a Cisco router?

6. In the output of show ntp associations, what does a reach value of 377 indicate?

7. Why does an NTP client gradually slew its clock instead of jumping immediately to the correct time?

8. An engineer configures NTP authentication on a client router but the server association shows "x" (false ticker / rejected) in show ntp associations. What is the most likely cause?

9. A router is configured as an NTP client pointing to an external NTP server. The show ntp status output shows the clock is synchronised at stratum 4. What is the stratum of the NTP server the router is syncing from?

10. Which set of commands correctly configures a Cisco router to synchronise from an NTP server at 10.1.1.1 using MD5 authentication with key-id 5 and key string "NTPkey99"?

4. What is the difference between configuring `ntp server` and `ntp peer` on a Cisco router?

5. What is the purpose of the `ntp master` command on a Cisco router?

6. In the output of `show ntp associations`, what does a `reach` value of 377 indicate?

8. An engineer configures NTP authentication on a client router but the server association shows "x" (false ticker / rejected) in `show ntp associations`. What is the most likely cause?

9. A router is configured as an NTP client pointing to an external NTP server. The `show ntp status` output shows the clock is synchronised at stratum 4. What is the stratum of the NTP server the router is syncing from?