NTP Configuration

Every log message, security event, and diagnostic output on a Cisco device includes a timestamp. If device clocks are not synchronised, those timestamps are meaningless — a syslog message on R1 timestamped 09:00 and a related message on R2 timestamped 11:47 cannot be correlated even if both events happened simultaneously. Inaccurate time also breaks AAA authentication (Kerberos tickets), SSL/TLS certificate validation, and SSH session establishment.

NTP (Network Time Protocol) synchronises device clocks across a network to a common time reference with millisecond accuracy. One device acts as the authoritative time source — all others synchronise to it. NTP uses a hierarchical model called stratum — the closer a device is to the atomic reference clock, the lower (and more accurate) its stratum number. For a conceptual overview see NTP and NTP Synchronisation.

Before starting, ensure IP connectivity between devices is established — NTP uses UDP port 123 and requires a routed path to the NTP server. Complete OSPF Single-Area Configuration or Static Route Configuration for the routing prerequisite. For viewing timestamped logs after NTP is configured, see show logging.

1. NTP — Core Concepts

Why Accurate Time Matters

Function	Impact of Wrong Time	Impact of Correct Time
Syslog & logging	Log timestamps are wrong — events cannot be correlated across devices during incident response	All log entries across all devices share a common timeline — instant event correlation. See Syslog Configuration
SSH / TLS	Certificate validity checks fail — connections refused if device clock is outside the certificate validity window	Certificate dates validated correctly — secure connections established. See SSH Configuration
AAA / Kerberos	Authentication tickets rejected — device clock more than 5 minutes off causes Kerberos to fail	Ticket timestamps valid — seamless authentication. See AAA Overview
Debugging	Packet captures and debug outputs across multiple devices have mismatched times — root cause analysis is difficult	All devices share the same clock — debug sequences line up perfectly
Compliance	Audit logs with wrong timestamps fail regulatory requirements (PCI-DSS, HIPAA, ISO 27001)	Accurate audit trails satisfy compliance requirements

NTP Stratum Hierarchy

NTP uses a stratum number (1–15) to represent distance from the reference clock. Stratum 0 devices are the atomic or GPS clocks themselves — they are not network-accessible. Stratum 1 servers connect directly to a Stratum 0 device. Each hop away from the reference adds one to the stratum number:

  Stratum 0  ──  Atomic / GPS clock (not a network device)
       ↓
  Stratum 1  ──  Public NTP servers (time.google.com, pool.ntp.org)
       ↓               directly connected to atomic clock
  Stratum 2  ──  Your ISP's NTP server / enterprise NTP server
       ↓               synchronised to Stratum 1
  Stratum 3  ──  R1 configured as ntp master (Cisco IOS)
       ↓               synchronised to Stratum 2, serves internal network
  Stratum 4  ──  R2, R3, Switches — NTP clients of R1
                     synchronised to R1
  Stratum 16 ──  Unsynchronised (default until NTP sync achieved)

Stratum	Meaning	Accuracy
1	Directly connected to atomic/GPS reference clock	Microseconds
2–4	One to three hops from reference — typical enterprise range	Milliseconds
5–15	Further from reference — acceptable for most network devices	Tens of milliseconds
16	Unsynchronised — device has not yet synchronised or has lost its NTP source	Unreliable

NTP Modes — Client, Server, and Peer

Mode	IOS Command	Role	Direction
Client	`ntp server [IP]`	Synchronises its clock to the specified NTP server — the most common mode	Receives time only
Master	`ntp master [stratum]`	Acts as an authoritative NTP source for other devices — uses its own hardware clock as the reference. Used when no external NTP server is available	Provides time to clients
Peer	`ntp peer [IP]`	Bidirectional synchronisation — both devices can synchronise to each other. Used for redundancy between NTP servers	Both sends and receives

2. Lab Topology & Scenario

NetsTuts_R1 is the edge router with internet access. It synchronises to a public NTP server (time.google.com / 216.239.35.0) and also acts as the internal NTP master for the rest of the network. NetsTuts_R2 and NetsTuts_SW1 are NTP clients of R1. All devices use UTC timezone with timezone offsets configured locally:

          Public Internet
          216.239.35.0 (time.google.com — Stratum 1)
                 |
            NTP sync (UDP/123)
                 |
      ┌──────────────────────────┐
      │       NetsTuts_R1        │
      │  ntp server 216.239.35.0 │  ← NTP client to Google
      │  ntp master 3            │  ← Internal NTP server (Stratum 3)
      │  Stratum: 2 after sync   │
      └──────────────────────────┘
          |                  |
     NTP client         NTP client
     (UDP/123)          (UDP/123)
          |                  |
  ┌──────────────┐    ┌──────────────┐
  │ NetsTuts_R2  │    │ NetsTuts_SW1 │
  │ ntp server   │    │ ntp server   │
  │   10.0.12.1  │    │   10.0.12.1  │
  │ Stratum: 3   │    │ Stratum: 3   │
  └──────────────┘    └──────────────┘

  All devices: UTC timezone
  R1 also configured as NTP master (stratum 3) for lab fallback

Device	NTP Role	NTP Source	Expected Stratum
NetsTuts_R1	Client to Google + Master for internal	216.239.35.0 (external)	2 (after syncing to Stratum 1)
NetsTuts_R2	NTP Client	10.0.12.1 (R1)	3
NetsTuts_SW1	NTP Client	10.0.12.1 (R1)	3

3. Step 1 — Set Timezone and Configure Logging Timestamps

Before configuring NTP, set the timezone on every device. Without a timezone, all devices default to UTC — which is correct for centralised logging but may not match local display preferences. Also enable timestamp precision on log messages so every log entry carries full date and time detail after NTP synchronises:

NetsTuts_R1>en
NetsTuts_R1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.

! ── Set timezone — UTC+3 (Arabian Standard Time example) ─
NetsTuts_R1(config)#clock timezone AST 3

! ── Optional: Configure daylight saving time ─────────────
! NetsTuts_R1(config)#clock summer-time AST recurring

! ── Enable detailed timestamps on all log messages ───────
NetsTuts_R1(config)#service timestamps log datetime msec show-timezone
NetsTuts_R1(config)#service timestamps debug datetime msec show-timezone

service timestamps log datetime msec show-timezone adds full date, time with milliseconds, and timezone label to every syslog message. Without this, IOS log messages show only relative uptime (e.g., "00:15:32") which is useless for cross-device correlation. msec adds millisecond precision — valuable during incident response when events happen within the same second.

4. Step 2 — Configure R1 as NTP Client and Internal Master

R1 performs two NTP roles simultaneously: it is a client to the public NTP server (synchronising its own clock) and a master for internal devices (providing time to R2 and SW1). The ntp master command creates a fallback — if the external NTP server is unreachable, R1 uses its own hardware clock as the source at the configured stratum:

! ── Synchronise R1 to Google's public NTP server ─────────
NetsTuts_R1(config)#ntp server 216.239.35.0 prefer
NetsTuts_R1(config)#ntp server 216.239.35.4

! ── R1 acts as internal NTP master at stratum 3 ──────────
! ── (fallback if external NTP unreachable) ───────────────
NetsTuts_R1(config)#ntp master 3

! ── Use loopback as NTP source interface ─────────────────
NetsTuts_R1(config)#ntp source Loopback0

! ── Optional: Restrict who can query R1's NTP service ────
NetsTuts_R1(config)#ntp access-group serve-only 10
NetsTuts_R1(config)#access-list 10 permit 192.168.0.0 0.0.255.255
NetsTuts_R1(config)#access-list 10 permit 10.0.0.0 0.255.255.255

NetsTuts_R1(config)#end
NetsTuts_R1#wr
Building configuration...
[OK]
NetsTuts_R1#

Two public NTP servers are configured — prefer marks 216.239.35.0 as the primary choice. If it becomes unreachable, IOS automatically falls back to 216.239.35.4. The ntp source Loopback0 command ensures NTP packets sourced from R1 always use the loopback IP — a stable, always-up address that other devices use as the NTP server target. The ntp access-group serve-only restricts NTP service to only internal subnets, preventing external hosts from using R1 as a public NTP server.

ntp master — Stratum Selection

Command	Stratum Assigned	When to Use
`ntp master 1`	Stratum 1	Never — stratum 1 implies a directly connected atomic clock. Do not claim stratum 1 without a real reference.
`ntp master 2`	Stratum 2	Only if R1 synchronises to a verified Stratum 1 server and the accuracy is confirmed
`ntp master 3`	Stratum 3	✅ Standard internal NTP master — clients become Stratum 4. Accurate enough for all enterprise purposes
`ntp master 8`	Stratum 8	Lab-only fallback — high stratum signals low authority. Clients synchronise but treat it as a last-resort source

5. Step 3 — Configure R2 and SW1 as NTP Clients

Internal devices only need the ntp server command pointing to R1's IP. Using R1's loopback IP as the NTP server address is best practice — it remains reachable as long as R1 is running, regardless of which physical interface connects R2 to R1:

NetsTuts_R2

NetsTuts_R2>en
NetsTuts_R2#conf t
Enter configuration commands, one per line.  End with CNTL/Z.

NetsTuts_R2(config)#clock timezone AST 3
NetsTuts_R2(config)#service timestamps log datetime msec show-timezone
NetsTuts_R2(config)#service timestamps debug datetime msec show-timezone

! ── Point to R1's loopback as NTP server ─────────────────
NetsTuts_R2(config)#ntp server 1.1.1.1 prefer
NetsTuts_R2(config)#ntp server 10.0.12.1

NetsTuts_R2(config)#end
NetsTuts_R2#wr
Building configuration...
[OK]
NetsTuts_R2#

NetsTuts_SW1 (Layer 2 / Layer 3 Switch)

NetsTuts_SW1>en
NetsTuts_SW1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.

NetsTuts_SW1(config)#clock timezone AST 3
NetsTuts_SW1(config)#service timestamps log datetime msec show-timezone
NetsTuts_SW1(config)#service timestamps debug datetime msec show-timezone

! ── Use management VLAN IP to reach R1's NTP ─────────────
NetsTuts_SW1(config)#ntp server 1.1.1.1 prefer
NetsTuts_SW1(config)#ntp server 10.0.12.1

NetsTuts_SW1(config)#end
NetsTuts_SW1#wr
Building configuration...
[OK]
NetsTuts_SW1#

The switch uses the same commands as a router for NTP — NTP configuration is consistent across all IOS device types. Two NTP servers are configured for redundancy: R1's loopback (1.1.1.1) as primary, R1's physical interface (10.0.12.1) as fallback. If R1's loopback is unreachable (e.g., routing change), the switch falls back to the physical IP.

6. Step 4 — NTP Authentication (Security Hardening)

Without NTP authentication, any device that can reach the NTP port can send false time updates — an attacker who manipulates device clocks can invalidate certificates, corrupt audit logs, and break time-sensitive security mechanisms. NTP MD5 authentication ensures clients only accept time from verified servers:

Configure NTP Authentication on R1 (Server)

NetsTuts_R1(config)#ntp authenticate
NetsTuts_R1(config)#ntp authentication-key 1 md5 NetsTutsNTP2026
NetsTuts_R1(config)#ntp trusted-key 1

Configure NTP Authentication on R2 (Client)

NetsTuts_R2(config)#ntp authenticate
NetsTuts_R2(config)#ntp authentication-key 1 md5 NetsTutsNTP2026
NetsTuts_R2(config)#ntp trusted-key 1
NetsTuts_R2(config)#ntp server 1.1.1.1 key 1

Three commands are required on both server and client: ntp authenticate enables the authentication requirement, ntp authentication-key [id] md5 [password] defines the shared key, and ntp trusted-key [id] marks which key IDs are acceptable. On the client, the key [id] appended to the ntp server command tells IOS which key to use when communicating with that specific server. The key ID and password must match exactly on both devices.

NTP Authentication Command Summary

Command	Where	Purpose
`ntp authenticate`	Server + Client	Enables NTP authentication — without this, keys are defined but not enforced
`ntp authentication-key [id] md5 [pass]`	Server + Client	Defines the shared secret key identified by a number (1–4294967295)
`ntp trusted-key [id]`	Server + Client	Marks which key IDs are trusted — packets signed with untrusted keys are rejected
`ntp server [IP] key [id]`	Client only	Associates a specific key with a specific NTP server — client uses this key to authenticate with that server

7. Step 5 — Manual Clock (Lab / No External NTP)

In lab environments where no internet access or external NTP server is available, the hardware clock can be set manually. A manually set clock has no automatic drift correction — use ntp master on at least one device to serve as the authoritative time source for all others:

! ── Set hardware clock manually (privileged EXEC) ────────
! ── Format: hh:mm:ss Day Month Year ──────────────────────
NetsTuts_R1#clock set 09:00:00 5 March 2026

! ── Verify immediately ───────────────────────────────────
NetsTuts_R1#show clock
09:00:03.214 AST Thu Mar 5 2026

! ── Sync hardware clock to NTP-sourced software clock ────
NetsTuts_R1#ntp update-calendar

clock set sets the software clock in RAM — it resets if the router loses power without a battery. ntp update-calendar writes the current software clock (sourced from NTP) to the hardware calendar (NVRAM-backed) — this persists across power cycles. In production, always run ntp update-calendar after NTP synchronises so rebooted devices start with a close-to-accurate time before NTP re-synchronises.

8. Verification

show ntp status — R1

NetsTuts_R1#show ntp status
Clock is synchronized, stratum 2, reference is 216.239.35.0
nominal freq is 250.0000 Hz, actual freq is 249.9991 Hz, precision is 2**18
ntp uptime is 3600 (1/100 of seconds), resolution is 4000
reference time is E8F3A201.B4E2C000 (09:00:01.706 AST Thu Mar 5 2026)
clock offset is 0.4573 msec, root delay is 14.23 msec
root dispersion is 7.88 msec, peer dispersion is 1.64 msec
loopfilter state is 'CTRL' (Normal Controlled Loop), drift is -0.000009138 s/s
system poll interval is 64, last update was 42 sec ago.

Key fields: Clock is synchronized — R1 has achieved NTP synchronisation (not just attempting). stratum 2 — R1's stratum after syncing to the Stratum 1 public server. reference is 216.239.35.0 — the NTP server R1 is currently synchronised to. clock offset is 0.4573 msec — the difference between R1's clock and the reference. Under 1ms is excellent. root delay is 14.23 msec — round-trip latency to the reference clock. "Clock is synchronized" is the single most important line — if it says "Clock is unsynchronized", NTP has not yet completed synchronisation.

show ntp status — R2 (Client)

NetsTuts_R2#show ntp status
Clock is synchronized, stratum 3, reference is 1.1.1.1
nominal freq is 250.0000 Hz, actual freq is 249.9993 Hz, precision is 2**18
reference time is E8F3A209.C1F40000 (09:00:09.757 AST Thu Mar 5 2026)
clock offset is 0.8821 msec, root delay is 22.15 msec
root dispersion is 12.42 msec, peer dispersion is 2.11 msec
loopfilter state is 'CTRL' (Normal Controlled Loop), drift is -0.000003241 s/s
system poll interval is 64, last update was 18 sec ago.

R2 shows stratum 3 — one hop further from the reference than R1. reference is 1.1.1.1 — R2 is synchronised to R1's loopback. The offset (0.8821 msec) is slightly larger than R1's because of the additional hop — still well under 1 second and acceptable for all enterprise purposes.

show ntp associations

NetsTuts_R1#show ntp associations

  address         ref clock       st   when  poll reach  delay  offset   disp
*~216.239.35.0    .GOOG.           1     41    64   377   14.23   0.457   1.64
+~216.239.35.4    .GOOG.           1    102    64   377   15.81   0.621   1.97
 * sys.peer, # selected, + candidate, - outlyer, x falseticker, ~ configured

The asterisk (*) marks the currently selected NTP peer — the server R1 is actively synchronising to (216.239.35.0). The plus sign (+) marks a candidate — it is reachable and valid but not the current selection (216.239.35.4, the fallback). Key columns: st = stratum of the server, reach = octal reachability register (377 = all 8 recent polls successful — fully reachable), delay = round-trip time in ms, offset = clock difference in ms. A reach of 000 means the server has not responded to any of the last 8 polls — it is unreachable.

show ntp associations — R2

NetsTuts_R2#show ntp associations

  address         ref clock       st   when  poll reach  delay  offset   disp
*~1.1.1.1         216.239.35.0     2     28    64   377    7.91   0.882   2.11
+~10.0.12.1       216.239.35.0     2     55    64   377    8.14   0.901   2.34
 * sys.peer, # selected, + candidate, - outlyer, x falseticker, ~ configured

R2 shows both of its configured NTP servers. The primary (1.1.1.1 — R1's loopback) is the current peer (*). The fallback (10.0.12.1 — R1's physical IP) is a candidate (+). Both show ref clock 216.239.35.0 — confirming that R2 can trace its time back to Google's NTP server through R1.

show clock detail

NetsTuts_R1#show clock detail
09:05:42.318 AST Thu Mar 5 2026
Time source is NTP

show clock detail adds the Time source line — confirming where the current time came from. Possible values: NTP (synchronised — correct), user configuration (manually set with clock set — not NTP-synchronised), or

hardware
    calendar

(read from NVRAM calendar at boot — not yet NTP-synced). Only NTP confirms active synchronisation.

Verification Command Summary

Command	What It Shows	Key Indicator
`show ntp status`	Synchronisation state, stratum, reference server, offset, delay	"Clock is synchronized" = NTP working. "Clock is unsynchronized" = NTP not yet complete or failed
`show ntp associations`	All configured NTP servers — reachability (reach), selected peer (*), stratum, offset, delay	* = current peer, reach 377 = fully reachable, reach 000 = unreachable
`show clock detail`	Current time, timezone, and time source	"Time source is NTP" = actively synchronised. Any other source = not NTP-synchronised
`show clock`	Current time and date — quick check	Verify time is correct after synchronisation
`show logging`	Log messages with timestamps — verify timestamps show correct date/time format after NTP sync	Log entries should show full datetime (not uptime) after `service timestamps log datetime`
`show ip sockets`	UDP/123 listening socket — confirms NTP process is active and listening	UDP/123 entry present = NTP service running

9. Troubleshooting NTP Issues

Problem	Symptom	Cause	Fix
"Clock is unsynchronized" persists	`show ntp status` keeps showing "Clock is unsynchronized" even after 10+ minutes	NTP server unreachable — routing or ACL blocking UDP/123, wrong server IP, or NTP server is down	Ping the NTP server IP from the router. Verify UDP/123 is not blocked by an ACL. Check `show ntp associations` — if reach shows 000 the server is not responding. Try a different NTP server.
reach shows 000 in associations	`show ntp associations` shows reach = 000 for all configured servers	No NTP responses received — UDP/123 blocked, no route to server, or server IP is wrong	Verify routing to the NTP server IP with `ping [NTP-server-IP] source [interface]`. Check for ACLs blocking UDP/123 with `show ip access-lists`. Confirm the correct NTP server IP in config.
NTP authentication failure	Associations show status "x" (falseticker) or client does not sync despite reaching server	Authentication key or key ID mismatch between server and client — the server sends a different key or key ID than the client trusts	Verify both devices use identical key ID and password: `show running-config \| include ntp auth`. The key ID number and MD5 password must match exactly. Also confirm `ntp trusted-key [id]` is configured on both.
Wrong timezone displayed	`show clock` shows correct UTC time but wrong local time	`clock timezone` not configured or set to wrong offset	Configure the correct offset: `clock timezone [NAME] [hours] [minutes]`. For UTC+3: `clock timezone AST 3`. NTP itself always works in UTC — the timezone setting only affects display.
Log timestamps still showing uptime format	Syslog messages show "00:15:32" instead of "09:05:42 Mar 5 2026"	`service timestamps log datetime` not configured — default is uptime format	Add `service timestamps log datetime msec show-timezone` in global config. Existing log entries in the buffer will not be updated — only new messages use the new format.
R1 NTP master not serving clients	R2 and SW1 show "Clock is unsynchronized" even though R1 is configured as master	`ntp master` configured on R1 but `ntp source` interface is down, or the NTP access-group ACL is blocking client IPs	Verify R1's loopback or source interface is up. Check `ntp access-group` ACL permits the client IPs. Verify R2 can reach R1's IP on UDP/123.

Key Points & Exam Tips

NTP synchronises device clocks to a common time source using UDP port 123. Accurate time is essential for log correlation, SSH/TLS certificate validation, AAA authentication, and compliance audit trails.
Stratum represents distance from the atomic reference clock. Stratum 1 = directly connected to atomic/GPS. Each hop adds 1. Stratum 16 = unsynchronised. Lower stratum = more accurate and more trusted.
ntp server [IP] configures a device as an NTP client. ntp master [stratum] makes a device an authoritative NTP source for other devices. ntp peer [IP] creates bidirectional synchronisation between two NTP servers.
ntp master 3 is the standard internal NTP master configuration — use stratum 3 so clients become stratum 4. Never configure stratum 1 unless a real atomic clock is connected.
Use R1's loopback IP as the NTP source and as the NTP server address on clients — loopbacks are always up, making NTP resilient to physical interface failures.
service timestamps log datetime msec show-timezone must be configured on every device to add accurate date/time to log messages. Without it, logs show relative uptime — useless for multi-device correlation.
NTP authentication (ntp authenticate, ntp authentication-key, ntp trusted-key) prevents rogue time sources from injecting false timestamps. The key ID and MD5 password must match exactly on server and client.
In show ntp associations: the asterisk (*) marks the active synchronisation peer, reach 377 (octal) means all 8 recent polls were successful, reach 000 means the server is unreachable.
show ntp status is the primary verification command — "Clock is synchronized" confirms NTP is working. show clock detail adds the time source — "Time source is NTP" is the expected value.
On the CCNA exam: know the difference between ntp server (client mode), ntp master (server mode), and ntp peer (bidirectional), what stratum numbers mean, and how to read show ntp status and show ntp associations output.

Next Steps: With accurate timestamps on all devices, log analysis becomes reliable. Review log output with timestamped entries in show logging and configure centralised syslog forwarding for all devices with Syslog Configuration. For securing management access to the devices whose clocks are now synchronised, revisit SSH Configuration and AAA Authentication Methods.

TEST WHAT YOU LEARNED

1. R1 is configured with `ntp master 3` and `ntp server 216.239.35.0`. When R1 successfully synchronises to the public server, what is R1's stratum and what stratum do its clients (R2, SW1) become?

A. R1 stays at stratum 3 (from ntp master) and clients become stratum 4 B. R1 becomes stratum 1 (it syncs to a Stratum 1 server) and clients become stratum 2 C. R1 becomes stratum 3 and clients also become stratum 3 (same tier as master) D. R1 becomes stratum 2 (one hop from the Stratum 1 public server) — the ntp master 3 fallback stratum is superseded by the better external reference. Clients synchronising to R1 become stratum 3

Correct answer is D. When R1 synchronises to an external Stratum 1 server (216.239.35.0), R1's own stratum becomes 2 — one hop from the reference, regardless of the ntp master 3 configuration. The ntp master stratum only applies when R1 has no external synchronisation source — it is a fallback. When the external source is available and R1 is synchronised, R1 advertises itself at the externally-derived stratum (2). Clients that synchronise to R1 then become Stratum 3. The ntp master 3 fallback only activates when the external server (216.239.35.0) becomes unreachable.

2. `show ntp associations` on R2 shows `reach = 000` for the configured NTP server. What does this mean and what is the first troubleshooting step?

A. reach 000 means R2 has just started and is still polling — wait 64 seconds for the first response B. reach 000 means none of the last 8 NTP polls received a response — the NTP server is unreachable from R2. First step: ping the NTP server IP from R2 to confirm basic IP reachability, then check for ACLs blocking UDP/123 C. reach 000 is normal — it resets to 000 every time the poll interval restarts D. reach 000 means the NTP server is at stratum 0 — R2 should use a different server

Correct answer is B. The reach field is an 8-bit octal register where each bit represents the result of one poll — 1 for success, 0 for failure. Octal 377 = binary 11111111 = all 8 recent polls successful. Octal 000 = binary 00000000 = all 8 recent polls failed — the server has not responded to any NTP query. This always indicates a connectivity problem: no route to the server, ACL blocking UDP/123, wrong server IP, or the server is down. The first troubleshooting step is to ping the NTP server IP from R2 to verify basic IP reachability. If ping works but reach is still 000, the issue is specifically UDP/123 — check ACLs and verify the NTP service is running on the server.

3. Why is it recommended to point internal NTP clients to R1's loopback IP rather than R1's physical interface IP as the NTP server address?

A. Loopback interfaces are always up as long as the router is running — if R1's physical interface toward R2 fails but R2 can still reach R1 via an alternate path, NTP continues to work because the loopback destination is reachable via any route. A physical interface IP becomes unreachable if that specific interface fails B. Loopback interfaces have lower latency — NTP synchronises faster when targeting a loopback C. Physical interface IPs are blocked by NTP access-group by default — loopbacks bypass this restriction D. IOS requires a loopback as the NTP source — physical interfaces cannot serve NTP requests

Correct answer is A. This is the same resilience principle used for DHCP relay, OSPF router IDs, and BGP peering — loopback interfaces never go down while the router is operating, regardless of physical link state. If R1's Gi0/1 (the link to R2) fails but R2 can reach R1 via an alternate path (e.g., through R3 via OSPF), the NTP session to R1's loopback continues uninterrupted. If R2 pointed to R1's Gi0/1 IP (10.0.12.1), a failure of that specific interface would break NTP even though R1 itself is fully operational. Using ntp source Loopback0 on R1 and ntp server [loopback-IP] on clients maximises NTP availability.

4. What is the purpose of `service timestamps log datetime msec show-timezone` and what happens to log messages without it?

A. It enables NTP — without this command, NTP cannot synchronise the clock B. It sets the timezone for display — without it, all times are shown in UTC regardless of the clock timezone setting C. It adds full date, time (with milliseconds), and timezone to every syslog message. Without it, log messages show only relative device uptime (e.g., "00:15:32") — making multi-device log correlation impossible since different devices started at different times D. It synchronises the logging buffer to the NTP server directly — without it, log events are buffered without timing information

Correct answer is C. By default, Cisco IOS log messages use "uptime" format — timestamps showing how long the device has been running (e.g., "1d02h" or "00:15:32"). This is meaningless for multi-device correlation because each device started at a different time. service timestamps log datetime msec show-timezone switches to absolute timestamp format (e.g., "09:05:42.318 AST Mar 5 2026") which is usable only after NTP synchronises the clock. The msec option adds millisecond precision and show-timezone appends the timezone label. This command is one of the most important baseline configurations alongside NTP itself.

5. An engineer configures NTP authentication on R1 (server) with key ID 1 and password "NetworkTime". R2 (client) is configured with key ID 1 and password "networktime" (lowercase). What happens?

A. NTP works — key IDs match so authentication passes regardless of password case B. NTP works with a warning — IOS normalises passwords to lowercase before comparison C. NTP works only for the first synchronisation then breaks after the key rotates D. Authentication fails — NTP MD5 key comparison is case-sensitive. "NetworkTime" and "networktime" produce different MD5 hashes. R2 marks the server as a falseticker (x in show ntp associations) and does not synchronise. The key and password must match exactly on both devices

Correct answer is D. NTP authentication uses MD5 — the password string is hashed with MD5 before being sent. MD5 is case-sensitive: "NetworkTime" and "networktime" produce completely different hashes. When R2 sends its authentication token using "networktime" and R1 expects "NetworkTime", the hash values do not match. R1 rejects R2's queries and R2 marks R1 as a falseticker (indicated by "x" in show ntp associations). R2 will not synchronise until the password is corrected to match exactly. Always copy-paste NTP authentication keys in production to avoid case and typo mismatches.

6. What is the difference between `show clock` and `show clock detail`?

A. show clock displays only the current time and date. show clock detail adds the "Time source" line — showing whether the clock is NTP-synchronised ("Time source is NTP"), manually set ("user configuration"), or read from the hardware calendar at boot. Only show clock detail confirms active NTP synchronisation B. show clock detail shows the clock in UTC while show clock shows local time C. show clock detail shows milliseconds while show clock shows seconds only D. They show identical output — detail is a deprecated keyword with no function

Correct answer is A. The critical difference is the "Time source" line added by the detail keyword. "Time source is NTP" confirms the clock is actively synchronised via NTP — this is the definitive indicator of NTP operation from the clock perspective. "Time source is user configuration" means someone ran clock set manually — NTP is not controlling the clock. "Time source is hardware calendar" means the time was read from the battery-backed calendar at boot but NTP has not yet synchronised. For quick verification that NTP is actually controlling the clock (not just that the time happens to look correct), always use show clock detail.

7. A device shows `show ntp status` reporting "Clock is unsynchronized, stratum 16." What does stratum 16 specifically indicate?

A. The device is 16 router hops away from the NTP reference clock B. The device has the lowest possible NTP priority — it will never synchronise C. Stratum 16 is the reserved value meaning "unsynchronised" in NTP — the device has no valid time reference. It is the default state of all devices before NTP synchronisation is achieved, or after a device loses its NTP source D. The device's hardware clock has failed — stratum 16 indicates a hardware fault

Correct answer is C. In the NTP standard, stratum 16 is a special reserved value meaning "unreachable" or "unsynchronised" — it is not an actual valid time stratum. Every Cisco device starts at stratum 16 before its first successful NTP synchronisation. If a device loses its NTP source (server unreachable, authentication failure, network outage), it returns to stratum 16 after the hold-off period. NTP clients treat stratum 16 sources as invalid and will not synchronise to them. It is the NTP equivalent of "I don't know what time it is" — the device's clock is running but has no trusted reference to confirm its accuracy.

8. What is the purpose of `ntp update-calendar` and when should it be run?

A. It forces an immediate NTP poll without waiting for the next scheduled poll interval B. It writes the current NTP-synchronised software clock to the hardware calendar (NVRAM-backed). After a power cycle, the router reads the hardware calendar at boot — if it was updated before the outage, the router starts with an approximate time instead of the factory default (Jan 1, 2002). NTP then corrects the small drift since the last update C. It updates the NTP server's calendar entry with this router's current time — used for peer synchronisation D. It configures NTP to automatically update the system clock every 24 hours

Correct answer is B. Cisco routers and switches have two separate clocks: the software clock (in RAM, volatile — resets on power loss) and the hardware calendar (battery-backed NVRAM, persistent). NTP synchronises the software clock. ntp update-calendar copies the NTP-accurate software clock value to the hardware calendar. After a power cycle, the router boots and reads the hardware calendar — if recently updated, it shows close-to-accurate time immediately. NTP then fine-tunes the remaining drift within minutes. Without running ntp update-calendar periodically, a rebooted router starts with an old hardware calendar time until NTP resynchronises, which can cause brief logging and authentication issues.

9. In `show ntp associations`, what does the symbol * next to an NTP server address mean, and how does it differ from +?

A. * = the server is using NTP version 3, + = the server is using NTP version 4 B. * = authentication passed, + = authentication not required for this server C. * = the server has the lowest latency, + = the server has the highest stratum D. * = the currently selected synchronisation peer — the device is actively synchronising its clock to this server. + = a candidate server that is reachable and valid but not currently selected — it serves as a standby if the * server becomes unavailable

Correct answer is D. NTP association symbols: * (sys.peer) = the single server currently being used for clock synchronisation — there can only be one at a time. + (candidate) = a valid, reachable server that passed sanity checks and is available as a fallback. - (outlyer) = a valid server but not selected because it differs significantly from the majority. x (falseticker) = a server that failed sanity checks or authentication — its time is considered unreliable. ~ = configured in the router's config. If the * server becomes unreachable, IOS automatically promotes a + candidate to * — providing automatic NTP failover without any manual intervention.

10. An engineer checks `show logging` after configuring NTP and finds all old log entries still show uptime format (e.g., "1d02h:15:32") while new entries show the correct date/time. Why?

A. NTP retroactively updates only the last 10 log entries — older entries remain in uptime format B. The logging buffer needs to be cleared and refilled — run clear logging to reset all timestamps C. Log entries are stored in the buffer with the timestamp format active at the time they were generated. Entries created before service timestamps log datetime was configured retain their original uptime format. Only new log entries after the configuration change use the datetime format — existing buffer entries cannot be retroactively reformatted D. The logging buffer is read-only — all entries always show uptime. The datetime format only applies to syslog messages forwarded to an external server

Correct answer is C. The logging buffer stores messages exactly as they were formatted when generated. Entries created before service timestamps log datetime msec show-timezone was configured used the default uptime format — those stored strings cannot be changed after the fact. Once the timestamp command is applied, all subsequently generated log messages use the new format. This is expected and normal behaviour — the mixed timestamps in the buffer simply reflect the configuration state at the time each message was generated. If a clean slate is needed, clear logging empties the buffer (but this discards all previous log history).

Back to Home