NTP on Cisco IOS: stratum, configuration, NTPv4, authentication and troubleshooting

Why time matters on a network

Clocks in routers and switches drift, and after a reload some devices start from a default date years in the past. Without a shared time source, three problems appear quickly: log messages from different devices cannot be lined up during an investigation, certificates look "not yet valid" or "expired" so VPNs and HTTPS management fail, and time-based features such as Kerberos authentication or time-based ACLs misbehave. The Network Time Protocol (NTP), on UDP port 123, fixes this by synchronising clocks to within milliseconds across a network.

Strata and associations

Accuracy starts at a reference clock (stratum 0) such as a GPS receiver. A server directly connected to it is stratum 1. Each device that learns time from another adds one. The stratum number shows distance from the source, not quality on its own, but lower is usually better.

An NTP association is a relationship with another time source. The common modes are:

• Client and server: the device asks a server for time and follows it. This is what you use most.
• Symmetric peers: two devices at a similar level back each other up.
• Broadcast or multicast: a server announces time to a whole segment; less common today.

A client polls several servers, filters out ones that disagree badly ("falsetickers") and picks the best as its system peer.

Configuring Cisco IOS

clock timezone GST 4 0
ntp authentication-key 1 hmac-sha2-256 Use-A-Long-Random-Key
ntp authenticate
ntp trusted-key 1
ntp source Loopback0
ntp server 10.0.100.1 key 1 prefer
ntp server 10.0.100.2 key 1
ntp update-calendar

• Use at least two servers, ideally three or four internal ones, which in turn use trusted external sources.
• Authentication stops a device from accepting time from an impostor. The key number, algorithm and value must match on both sides. Older IOS versions only offer MD5; use stronger options where available.
• ntp source makes requests come from a stable loopback address, which simplifies ACLs on the servers.
• ntp master 3 makes a router an authoritative source using its own clock. It is useful in an isolated lab but should not be used where a real time source is available.

show ntp status
show ntp associations
show clock detail

In show ntp associations, an asterisk marks the system peer the device is following. show ntp status should say "Clock is synchronized" and give the stratum and reference.

NTPv4 and secure time

NTP version 4 (RFC 5905) is the current standard. Compared with version 3 it adds full IPv6 support, more accurate algorithms, better handling of network delay and support for dynamic server discovery. On IOS you enable it simply by pointing at an IPv6 server, for example ntp server 2001:db8:100::1. Version 4 is backwards compatible, so v3 and v4 devices work together.

NTP's original security relied on shared symmetric keys. Network Time Security (NTS), defined in RFC 8915, uses TLS to set up keys automatically and is supported by many modern servers and operating systems; network operating system support varies, so check your platform.

Troubleshooting NTP

1. Be patient. NTP takes several minutes to trust a source. A device that has just been configured will not show synchronised straight away.
2. Check reachability. Ping the server from the source interface, and make sure ACLs and firewalls allow UDP 123 in both directions.
3. Check the server. A server that is itself unsynchronised advertises stratum 16, and clients will refuse it.
4. Check authentication. A mismatched key number, algorithm or value, or a missing ntp trusted-key, means the association never becomes valid.
5. Check the starting time. If the clock is wildly wrong, set it roughly by hand with clock set, then let NTP fine-tune.
6. Look at the packets. debug ntp packets (briefly) shows whether requests are sent and replies received.

Real-world example: logs that did not line up

After a suspected break-in attempt, the security team at a fictional university tried to follow an attacker's VPN session through the firewall, a core switch and a server. The firewall said the session started at 02:14, the switch at 01:51 and the server at 02:16. The switch had never been configured for NTP and had drifted 23 minutes since its last reload. The team rebuilt the timeline by hand, which took most of a day. Afterwards they deployed two internal NTP servers fed by GPS and an external pool, configured every device with authentication and a loopback source, and added a monitoring check that alerts on any device whose NTP status is not synchronised.