NTP configuration

A real-life situation

At 02:14 a link between R1 and R2 flapped and users lost the file server for a few seconds. You open the logs. R1 says the link went down at 09:47 on 1 March 1993. R2 says 02:15 today. SRV1 has its own idea. You can't line the events up, so you can't tell what failed first. Every Cisco device has its own clock, and unless something keeps them in step they drift apart or start from a default date after a reload.

The fix is the Network Time Protocol (NTP). The idea of NTP is covered in NTP: keeping time. This lesson is about configuring and checking it on Cisco IOS.

What NTP is

NTP lets a device ask another device for the time, measure how long the question took to travel, and correct its own clock. It runs over UDP port 123. On a Cisco device it can play three roles:

• Client: takes time from a server (ntp server). It never gives time back to that server.
• Server: gives time to others. A Cisco device that is synchronised automatically answers NTP clients; you don't need an extra command. ntp master makes it a server even with no outside source.
• Symmetric peer: two devices that can correct each other (ntp peer).

Stratum is the distance from a real reference clock, such as a GPS receiver or an atomic clock. The reference clock itself is stratum 0. A server wired to it is stratum 1. A device that learns time from a stratum 1 server is stratum 2, and so on. A lower stratum means closer to the source. Stratum 16 means "not synchronised".

Why it works that way

Time can't be copied like a file, because the answer is already old when it arrives. NTP solves this by recording four timestamps for each exchange: when the client sent the request, when the server received it, when the server replied, and when the client got the reply. From these the client works out the delay (time on the wire) and the offset (how far its own clock is wrong). It then adjusts its clock gradually instead of jumping, so logs don't suddenly go backwards.

Stratum exists so devices can avoid loops and choose wisely. A client with several servers prefers the one with the lowest stratum and the most stable answers. A device won't take time from a source with a higher stratum than its own.

How it works step by step

In the lab, R1 takes time from an internet server and shares it with R2 and SW1.

How to configure it on Cisco IOS

1. Time zone and a manual starting point

NTP always carries UTC. The time zone only changes how the device shows the time. Setting the clock by hand first gets it close, so NTP doesn't have a huge gap to close.

2. R1 as client of the internet server

3. R2 and SW1 as clients of R1

R1 needs no extra command to serve them. Once it is synchronised, it answers NTP requests.

4. Other modes

5. Authentication

Without authentication, a client believes any device that answers from the server address. NTP authentication adds a hash made with a shared secret key. The client checks it before using the time.

⚠️ Commands are based on Cisco IOS / IOS XE documentation and haven't been run in a lab here. Newer releases also accept stronger key types (for example hmac-sha2-256); MD5 is what the CCNA uses.

Full example

How to verify it

R1#show ntp associations
  address         ref clock       st   when   poll reach  delay  offset   disp
*~198.51.100.10   192.0.2.123      2     33     64   377 14.210  -0.612   1.937
+~203.0.113.1     198.51.100.10    3     51     64   377  2.105   0.144   1.802
 * sys.peer, # selected, + candidate, - outlyer, x falseticker, ~ configured

R1#show ntp status
Clock is synchronized, stratum 3, reference is 198.51.100.10
nominal freq is 250.0000 Hz, actual freq is 250.0003 Hz, precision is 2**10
...
clock offset is -0.6120 msec, root delay is 14.21 msec
...

R2#show clock detail
14:06:10.512 CET Tue Oct 6 2026
Time source is NTP

What goes wrong and how to troubleshoot it

• Reach stays at 0. No replies arrive. Ping the server, check routing in both directions, and check that no ACL blocks UDP 123.
• The server is listed but never gets a *. It can take several minutes to synchronise; NTP needs a few good samples first. If it never happens, the server itself may be unsynchronised (stratum 16) or the offset is huge. Set the clock close by hand with clock set and wait.
• Works without authentication, fails with it. The key number or text differs, ntp trusted-key is missing, or key 1 was left off the ntp server line.
• Time is right but shown wrong. The time zone offset is wrong, or summer time is missing. NTP itself is fine.

Common mistakes

• Typing clock set in configuration mode. It is a privileged EXEC command.
• Expecting ntp server to make the device a server. It makes it a client of that address.
• Using ntp master on a router that also has a good outside source, which can hand out a less accurate time.
• Turning on ntp authenticate on the server only. The command makes the device check the time it receives, so it belongs on the client.
• Thinking the time zone is sent by NTP. Configure clock timezone on every device.

💡 Exam tip: know the difference between ntp server (client mode), ntp peer (symmetric) and ntp master (own clock, default stratum 8). Expect to read show ntp associations: find the * line and its stratum, and add one to get the local stratum. Remember UDP 123, and that clock set is an EXEC command.

Key takeaways

• NTP keeps device clocks in step so logs, certificates and authentication work. It uses UDP 123 and carries UTC.
• Stratum is the hop count from a reference clock; a client is one higher than its server.
• ntp server = client mode, ntp peer = symmetric mode, ntp master = serve from the local clock.
• Authentication needs ntp authenticate, a key, ntp trusted-key and key on the server line.
• Verify with show ntp associations, show ntp status and show clock detail.

Accurate time matters most for logs: see SNMP and Syslog configuration.

Check yourself