Configure and verify NTP operating in a client and server mode

Why accurate time matters

Every router and switch has a clock. Left alone, those clocks drift by seconds per day, and a device that reboots without a battery-backed calendar may start at midnight on a date decades in the past. That would not matter much except that almost everything you do to troubleshoot or secure a network depends on time:

• Log correlation. When a link flaps, you want to line up the syslog messages from the switch on one end, the router on the other, and the monitoring server. If their clocks differ by three minutes, you cannot tell which event caused which.
• Digital certificates. Certificates used by HTTPS, SSH, and VPNs have a “valid from” and “valid to” date. A device whose clock says 1993 will reject every certificate as “not yet valid.”
• Authentication and security. Kerberos, one-time passwords, and many logging and forensic tools require time to be in sync within a few minutes or they fail outright.
• Scheduled tasks and time-based ACLs. A time-based access list that opens at 08:00 is useless if the router thinks it is 03:00.

Network Time Protocol (NTP) solves this by letting devices synchronize their clocks to a reference over the network. NTP runs over UDP port 123. It can typically keep devices within a few milliseconds of each other on a LAN and within tens of milliseconds across the Internet.

Stratum: how far from the truth

NTP organizes time sources in a hierarchy called stratum levels, numbered 0 to 15:

• Stratum 0 is the reference clock itself: an atomic clock, a GPS receiver, or a radio clock. Stratum 0 devices are not on the network; they plug directly into a server.
• Stratum 1 is a server connected directly to a stratum 0 clock. These are the most accurate network time sources.
• Stratum 2 is a device that gets time from a stratum 1 server. Stratum 3 gets time from stratum 2, and so on.
• Stratum 15 is the lowest usable level.
• Stratum 16 means “not synchronized.” A device reporting stratum 16 has no valid time source and other devices will not trust it.

Each hop down adds a small amount of error, so a lower stratum number means a more trustworthy source. When a client has several servers configured, it prefers the one with the lowest stratum (all else being equal). A device’s own stratum is always one more than the server it synchronizes to.

Client and server modes

A Cisco router can play three NTP roles:

• Client: it synchronizes its clock to a server. Configured with ntp server <address>.
• Server: it answers time requests from clients. Any Cisco device that is itself synchronized (as a client) automatically also acts as a server for other devices; you do not need a separate command. Its stratum is one higher than its source.
• Master: a device that uses its own internal clock as the authoritative source, even with no upstream server. Configured with ntp master [stratum]. The default stratum for ntp master is 8. Use this on an isolated network with no Internet access, or as a fallback so the LAN stays in sync among itself even if the Internet link fails.

The usual design is: one or two core routers are clients of public or ISP NTP servers (for example pool.ntp.org addresses or a company stratum 1 appliance), and every other device is a client of those core routers. This keeps NTP traffic off the Internet link and gives one point of control.

Configuring the clock, time zone, and NTP

Before NTP, understand the two clocks in a Cisco device. The software clock is what show clock displays and what NTP updates. Routers with a battery-backed hardware calendar keep time across reboots; the software clock is loaded from the calendar at boot. NTP normally updates only the software clock, so after a reboot the device would start from the old calendar time until it resynchronizes. The command ntp update-calendar tells the router to periodically write NTP-derived time into the hardware calendar as well.

The time zone must be set manually; NTP distributes UTC (Coordinated Universal Time) only, and the device applies your local offset for display.

! Set the time zone: name, hours offset from UTC (and optional minutes)
R1(config)# clock timezone EST -5
! Optional: daylight saving time, US rules
R1(config)# clock summer-time EDT recurring
! Point at two external NTP servers; prefer the first
R1(config)# ntp server 192.0.2.10 prefer
R1(config)# ntp server 192.0.2.11
! Copy NTP time into the hardware calendar periodically
R1(config)# ntp update-calendar
! Fallback: if the servers die, be a stratum-10 master from own clock
R1(config)# ntp master 10

To set the clock manually (privileged EXEC, not config mode; useful before NTP syncs, since NTP will refuse to sync if the local clock is wildly off, more than about 1000 seconds):

R1# clock set 14:30:00 8 Sep 2026

The format is hh:mm:ss day month year. Note that clock set is an EXEC command while clock timezone is a global configuration command.

A downstream switch simply points at R1:

SW1(config)# clock timezone EST -5
SW1(config)# ntp server 192.168.1.1

Verifying NTP

R1# show ntp status
Clock is synchronized, stratum 3, reference is 192.0.2.10
nominal freq is 250.0000 Hz, actual freq is 249.9999 Hz, precision is 2**10
ntp uptime is 1234500 (1/100 of seconds), resolution is 4000
reference time is E6A3B2C1.8F5C28F6 (14:31:45.560 EST Tue Sep 8 2026)
clock offset is 0.4521 msec, root delay is 21.34 msec
root dispersion is 45.12 msec, peer dispersion is 1.02 msec
loopfilter state is 'CTRL' (Normal Controlled Loop), drift is 0.000000155 s/s
system poll interval is 64, last update was 112 sec ago.

The first line tells you everything important: synchronized or not, the device’s own stratum (3 here, so the server was stratum 2), and the reference address. An unsynchronized device shows Clock is unsynchronized, stratum 16, no reference clock.

R1# show ntp associations
  address         ref clock       st   when   poll reach  delay  offset   disp
*~192.0.2.10      198.51.100.7     2    112     64   377  21.34   0.452  1.02
+~192.0.2.11      10.0.0.5         2     50     64   377  25.10   1.180  1.55
 * sys.peer, # selected, + candidate, - outlyer, x falseticker, ~ configured

The symbols on the left matter: * marks the server the device is currently synchronized to (the “sys.peer”), + marks a valid candidate, ~ means the server was statically configured. st is that server’s stratum. reach is an octal bit field of the last eight polls; 377 means all eight succeeded. when is seconds since the last reply; poll is the polling interval in seconds.

On the switch, show ntp associations shows 192.168.1.1 with st 3, and show ntp status reports stratum 4.

NTP authentication (brief)

Because a fake NTP server could push a wrong time and break certificates or logs, NTP supports authentication with MD5 (and on newer IOS, SHA) keys. Both sides must share the key. On the client:

R1(config)# ntp authenticate
R1(config)# ntp authentication-key 1 md5 MyNtpKey
R1(config)# ntp trusted-key 1
R1(config)# ntp server 192.0.2.10 key 1

ntp authenticate turns the feature on, ntp authentication-key defines a key, ntp trusted-key says which keys are acceptable, and the key option on ntp server binds the key to that server. The server needs the same key definition. The CCNA expects you to know that NTP authentication exists and that it verifies the identity of the time source; it does not encrypt the time data.