How to Configure NTP on a Cisco Router (Step by Step)

Step 1 — Make one router the time source

Every NTP hierarchy needs a root. If your lab has no reachable Internet time source, designate one router as authoritative with ntp master, followed by a stratum number. Stratum 3 is a reasonable default — it says "I'm 3 hops from a real reference clock," and anything that syncs to it will settle one stratum higher (further from the reference).

Only configure this on the router acting as the source. Do it on more than one and you'll end up with multiple routers claiming to be authoritative and no clear hierarchy.

R1# configure terminal
R1(config)# ntp master 3
R1(config)# end

Step 2 — Point clients at the source

On every other router, tell it where to get the time. ntp server takes the IP address of the time source and starts the client polling it in the background — there's nothing else you need to do to trigger the exchange.

The client doesn't just copy the server's stratum, it adds one. A client pointed at your stratum-3 master will show up as stratum 4 once it syncs.

R2# configure terminal
R2(config)# ntp server 10.0.0.1
R2(config)# end

Step 3 — Lock it down with MD5 authentication

By default, any device that can reach the server on UDP 123 can sync to it — fine in a closed lab, not fine in production. NTP authentication makes the client verify a keyed hash before it trusts the server's time.

Configure the same key number and key string on both ends, mark it trusted with ntp trusted-key, then reference the key on the client's ntp server line. Mismatch the key number or the string on either side and the client simply never syncs — there's no error message, it just stays unsynchronized.

R1(config)# ntp authenticate
R1(config)# ntp authentication-key 1 md5 CCNAKEY
R1(config)# ntp trusted-key 1
R2(config)# ntp authenticate
R2(config)# ntp authentication-key 1 md5 CCNAKEY
R2(config)# ntp trusted-key 1
R2(config)# ntp server 10.0.0.1 key 1

Step 4 — Verify the sync

show ntp associations lists every configured NTP peer and marks the one currently selected as the time source with an asterisk. show ntp status confirms whether the clock is actually synchronized and which stratum it landed on.

Give it a few minutes. NTP doesn't lock in instantly — a router can show as configured but not yet synchronized right after you apply the config, and that's normal, not a failure. Recheck show ntp associations before you assume something's wrong.

R2# show ntp associations
R2# show ntp status
R2# show clock

A complete worked example: two routers with authenticated NTP

Putting the pieces together on real addresses makes the flow concrete. Here R1 is the authoritative source on 10.0.0.1/24 at stratum 3, and R2 (10.0.0.2/24) is a client that both points at R1 and requires the MD5 key before it will trust the answer. Notice that on the client the key is bound directly to the server line with key 1 — declaring and trusting the key alone does nothing until it is referenced on the association.

Once both sides are applied, R2 does not sync instantly. Watch the reach counter in show ntp associations: it is an 8-bit octal shift register, so it climbs 1, 3, 7, 17, 37 ... and reaches 377 only after eight consecutive successful polls. A value of 377 is the sign that every recent exchange succeeded; a value stuck at 0 means the client is sending but hearing nothing back — reachability, ACL, or authentication.

When it converges, the asterisk in show ntp associations marks the peer that was actually selected as the system clock, and show ntp status confirms the router settled at stratum 4 (one above R1's stratum 3). The ref clock 127.127.1.1 on R1's own association is normal — that is the internal software clock a router synchronizes to when you configure ntp master.

! ----- R1 (authoritative source) -----
R1(config)# ntp authentication-key 1 md5 CCNAKEY
R1(config)# ntp authenticate
R1(config)# ntp trusted-key 1
R1(config)# ntp master 3

! ----- R2 (authenticated client) -----
R2(config)# ntp authentication-key 1 md5 CCNAKEY
R2(config)# ntp authenticate
R2(config)# ntp trusted-key 1
R2(config)# ntp server 10.0.0.1 key 1
R2(config)# end

! ----- Verify on R2 after a few polling cycles -----
R2# show ntp associations
      address         ref clock     st  when  poll reach  delay  offset   disp
 *~10.0.0.1       127.127.1.1       3    18    64   377    1.5    0.50    0.1
 * sys.peer, # selected, + candidate, - outlyer, x falseticker, ~ configured

R2# show ntp status
Clock is synchronized, stratum 4, reference is 10.0.0.1
reference time is E1A2B3C4.7F000000
clock offset is 0.50 msec, root delay is 1.50 msec

Make your logs actually benefit from NTP: timestamps and time zones

Synchronizing the clock is only half the payoff — the reason you did it was so logs and debugs correlate across devices, and that requires one more command. By default IOS timestamps log messages with uptime (for example *00:04:12:*), which is useless for correlating an event across three routers. service timestamps log datetime replaces that with the actual wall-clock time, and msec localtime show-timezone adds millisecond precision and the zone so a message reads Jul 2 14:03:07.221 EDT instead of a meaningless uptime counter.

Pair the timestamps with the time-zone settings so the displayed time matches everyone's expectation. clock timezone applies the UTC offset and clock summer-time recurring handles daylight saving automatically, so you are not manually shifting an hour twice a year. Because NTP itself runs in UTC, these commands change only how the router presents time in show clock and in logs — they never affect the synchronization.

One more command matters on hardware that has a separate battery-backed calendar chip (many routers and multilayer switches): ntp update-calendar tells NTP to periodically write the disciplined software time back into that hardware calendar. Without it, the accurate NTP time is lost across a reload and the box boots on whatever the drifted calendar says until NTP re-converges.

R1(config)# clock timezone EST -5
R1(config)# clock summer-time EDT recurring
R1(config)# service timestamps log datetime msec localtime show-timezone
R1(config)# service timestamps debug datetime msec localtime show-timezone
R1(config)# ntp update-calendar
R1(config)# end

R1# show clock
14:03:07.221 EDT Thu Jul 2 2026

Common problems (and the fix)

No ntp master anywhere. If every router in the topology is just running ntp server pointed at each other, there's no root — nobody actually has a reliable clock to sync from. One device has to be authoritative.

Client pointed at an unreachable IP. ntp server accepts any address whether or not it's reachable; if there's no route to the source or something's blocking UDP 123, the client sits there unsynchronized indefinitely.

Authentication key mismatch. The key number, the key string, and the trusted-key statement all have to match on both ends. Get any one of them wrong and the client rejects the server silently.

Expecting instant results. Convergence takes a few minutes. Check show ntp associations and show ntp status — a fresh config that hasn't synced yet isn't necessarily broken.