Time synchronization is a silent hero in networking—without it, logs are useless, authentication fails, and certificate validation breaks. The Network Time Protocol (NTP) is the de facto standard for clock sync, and the CCNA 200-301 exam tests your ability to troubleshoot when a device refuses to synchronize. This chapter covers NTP operation, common failure modes, and a systematic diagnostic procedure that will save your production network and your exam score. Exam objective 4.4: Troubleshoot NTP issues.
Jump to a section
Imagine you are the stationmaster of a major railway hub. Your entire schedule—arrivals, departures, platform assignments—must be perfectly aligned with other stations across the continent. You have a master clock in your office (your local clock), but it drifts by seconds each day. To stay coordinated, you subscribe to a time service: every hour, a courier on a motorcycle arrives from the National Time Bureau (the NTP server) with a precisely synchronized pocket watch. You immediately set your office clock to match. But here's the catch: the courier's journey takes exactly 10 minutes, and you know this because the time bureau told you the distance and the motorcycle's speed. When the courier hands you the watch, you add those 10 minutes to the displayed time because the watch was correct when he left, not when he arrived. That's NTP's core mechanism: the client estimates the network round-trip delay and adjusts the server's timestamp accordingly. Now, what could go wrong? If the courier gets lost (network congestion), his arrival time becomes unpredictable, and you cannot trust his watch. If the time bureau's clock is itself wrong (a stratum-1 server with GPS failure), you inherit that error. If someone steals the courier's watch and sets it back an hour (a man-in-the-middle attack), you might accept a false time. In your network, NTP clients send timestamps in UDP packets, compute offset and delay from four timestamps, and then adjust their local clock. Troubleshooting NTP is like diagnosing why your train schedule is off: you check whether the courier is arriving at all (reachability), whether the journey time is consistent (delay jitter), and whether the bureau's time is authoritative (stratum).
What is NTP and Why Does It Matter?
Network Time Protocol (NTP) is defined in RFC 5905. It synchronizes clocks of network devices to a common time source, typically Coordinated Universal Time (UTC). On Cisco devices, NTP is critical for:
Accurate log timestamps for security audits and troubleshooting.
Kerberos authentication (e.g., for AAA) which requires clocks within 5 minutes of each other.
Certificate validation in PKI—a certificate's validity period is checked against the device clock.
Scheduled tasks like CRON jobs or interface state changes.
The CCNA 200-301 exam expects you to know how to configure NTP (client, server, and authentication) and how to diagnose synchronization failures using show commands.
How NTP Works: The Four-Timestamp Dance
NTP uses a client-server model over UDP port 123. The synchronization process involves four timestamps:
T1: Client sends a request packet with its current time.
T2: Server receives the request and records the time.
T3: Server sends a reply packet with its current time.
T4: Client receives the reply and records the time.
From these, the client computes:
Round-trip delay = (T4 - T1) - (T3 - T2)
Offset = ((T2 - T1) + (T3 - T4)) / 2
The client then adjusts its local clock by the offset, but does so gradually (slewing) to avoid abrupt time changes. If the offset exceeds 128 ms (default on Cisco), the clock is stepped (immediate correction). This can cause issues with routing protocols like OSPF that use timestamps for adjacency.
NTP Hierarchy: Strata
NTP organizes time sources into strata:
Stratum 0: Atomic clocks, GPS receivers (not directly on the network).
Stratum 1: Servers directly connected to stratum 0 (e.g., time.google.com).
Stratum 2: Servers synchronized to stratum 1, and so on.
Stratum 16: Unsynchronized (default on Cisco devices before any NTP configuration).
A client will prefer a lower stratum server (more accurate). If multiple servers have the same stratum, the client selects the one with the lowest synchronization distance (a metric combining delay and dispersion).
NTP Modes on Cisco IOS
Cisco devices can operate in several modes:
- Client mode: The device sends NTP requests to a configured server and synchronizes to it. Configured with ntp server <ip>.
- Server mode: The device provides time to other NTP clients. Enabled by default when the device has a valid time source.
- Peer mode: Two devices at the same stratum synchronize to each other (backup). Configured with ntp peer <ip>.
- Broadcast mode: Server sends unsolicited NTP messages to a subnet. Clients listen. Configured with ntp broadcast on interface.
NTP Authentication
NTP can use symmetric key authentication (MD5 or SHA) to prevent spoofing. Configured with:
- ntp authentication-key 1 md5 <key>
- ntp authenticate
- ntp trusted-key 1
Key Timers and Defaults
Poll interval: Default 64 seconds (min 16, max 1024). Cisco uses a dynamic poll interval between 64 and 1024 seconds depending on dispersion.
Sync interval: A client will attempt to synchronize every poll interval.
Stratum default: 16 (unsynchronized).
Reachability: A 8-bit shift register that tracks recent NTP responses. 0x01 = one good response, 0xFF = 8 consecutive good responses.
Offset limit for stepping: 128 ms (default). Can be changed with ntp max-associations? Actually, it's ntp step-threshold? No, on Cisco, the clock is stepped if offset > 128 ms. This is not directly configurable in IOS (it's hardcoded).
Verification Commands
#### show ntp associations
Displays all NTP associations (configured servers/peers) and their status.
Router# show ntp associations
address ref clock st when poll reach delay offset disp
*~192.168.1.10 .GPS. 1 23 64 377 1.234 0.123 0.456
+~10.0.0.1 .LOCL. 14 12 128 377 2.345 1.234 1.567* = current synchronization source
+ = candidate (synchronization possible)
~ = configured with ntp server
st = stratum
when = seconds since last packet received
poll = poll interval (seconds)
reach = reachability register (octal). 377 octal = 0xFF binary = all 8 recent polls successful
delay, offset, disp = round-trip delay, clock offset, dispersion (all in milliseconds)
#### show ntp status
Shows the device's own NTP status: clock is synchronized, stratum, reference clock ID, etc.
Router# show ntp status
Clock is synchronized, stratum 2, reference is 192.168.1.10
nominal freq is 250.0000 Hz, actual freq is 249.9995 Hz, precision is 2**10
reference time is D43E1A2C.00000000 (12:34:56.000 UTC Mon Jan 1 2024)
clock offset is 0.1234 msec, root delay is 1.234 msec
root dispersion is 0.456 msec, peer dispersion is 0.789 msecKey fields:
- Clock is synchronized vs unsynchronized
- stratum (should be >1 if client is stratum 2 or higher)
- reference is (IP of the server it's synced to)
- clock offset (should be small, typically < 100 ms)
#### debug ntp packets
Use with caution in production. Shows NTP packets sent/received.
Router# debug ntp packets
NTP message sent to 192.168.1.10, from interface GigabitEthernet0/0 (192.168.1.100)
NTP message received from 192.168.1.10Common Failure Modes
NTP server unreachable: No response due to ACL blocking UDP 123, routing issue, or server down.
Stratum too high: Server's stratum >= client's stratum (client won't sync to a server with stratum >= its own).
Authentication mismatch: Keys or trusted-key configuration wrong.
Clock offset too large: If offset > 128 ms, the clock is stepped, but if the step is too large (e.g., > 17 minutes?), NTP may reject? Actually, NTP can handle large offsets but Cisco IOS may not sync if offset is > 1000 seconds? The default ntp max-associations? No, there's a sanity check: if the offset exceeds 1000 seconds, the packet is ignored.
NTP disabled globally: no ntp enable? Actually, NTP is enabled by default if any ntp server command is configured. But there is ntp disable on an interface.
Interaction with Related Protocols
ACLs: Must permit UDP 123 to/from NTP servers.
Routing: NTP uses the routing table to reach the server; ensure reachability.
DNS: If using hostname, DNS must resolve.
Syslog: Accurate timestamps depend on NTP sync.
AAA/TACACS+: Authentication may fail if clocks are off by more than 5 minutes (Kerberos) or 1 minute (TACACS+ timestamp check).
Verify NTP Status with show ntp status
Start with `show ntp status`. The most important line is 'Clock is synchronized' or 'unsynchronized'. If synchronized, note the stratum and reference IP. If unsynchronized, proceed to the next step. This command tells you the big picture: whether the device has ever synced, the current stratum, and the reference clock. If the clock is synchronized but the time is wrong, the server might be misconfigured (e.g., using local clock with no stratum 1 source).
Check NTP Associations with show ntp associations
Run `show ntp associations`. Look for the `*` indicator on one of the configured servers. If no `*`, the device is not synced to any server. Check the reachability register (reach column). If reach is 0 (octal 0) or very low (e.g., 1), the server is not responding. Also check the stratum (st) of the server: if it's 16, the server itself is unsynchronized. If the server's stratum is higher than or equal to the client's current stratum (which starts at 16), the client won't sync. The `when` column shows seconds since last packet; if it's large (e.g., > 300), packets are being lost.
Verify Network Reachability to NTP Server
Ping the NTP server from the device: `ping <ntp-server-ip>`. If ping fails, check routing and ACLs. Use `traceroute` to see if packets are dropped mid-path. Also verify that UDP port 123 is not blocked by an ACL on the device or on intermediate firewalls. On Cisco, you can check interface ACLs with `show ip interface` and look for 'access list' lines. If the NTP server is on a different subnet, ensure the default route or a specific route exists. Use `show ip route <server-ip>` to confirm.
Confirm NTP Server Configuration on the Device
Run `show running-config | include ntp` to see all NTP-related commands. Look for `ntp server <ip>` or `ntp peer <ip>`. Ensure the IP is correct. If authentication is configured, check for `ntp authenticate`, `ntp authentication-key`, and `ntp trusted-key`. A common mistake is forgetting the `ntp trusted-key` command—without it, the key is not considered valid even if it matches. Also check if `ntp disable` is applied on the interface facing the server (that would block NTP packets on that interface).
Inspect NTP Authentication if Configured
If authentication is enabled, verify that the key number and key string match on both client and server. Use `show ntp associations detail` to see if authentication is failing. Look for 'authenticated' field. If it says 'no', the packet was not authenticated. Also check that the key is trusted: `show ntp authentication-keys`. If the key is not trusted, the client will reject the server. Another trap: the server must also have the same key and trust the key. On the server, run `show ntp associations detail` to see if the client is being served.
Check for Large Clock Offset or Step Threshold
If the device is receiving NTP packets but not syncing, the clock offset might be too large. By default, Cisco IOS will step the clock if the offset exceeds 128 ms, but if the offset is greater than 1000 seconds (about 17 minutes), the packet is ignored. Use `show ntp status` to see the current clock offset. If it's very large, you may need to manually set the clock close to the correct time first with `clock set`, then let NTP fine-tune. Alternatively, you can use the `ntp max-associations`? No, but you can adjust the step threshold with `ntp step-threshold`? Actually, on IOS, you can use `ntp max-distance`? Not exactly. The simplest fix is to set the clock manually: `clock set HH:MM:SS DD MONTH YYYY`.
Scenario 1: Enterprise Campus with Multiple NTP Servers
A large enterprise has two stratum-2 NTP servers in the data center, each synced to different stratum-1 sources (e.g., GPS and CDMA). All access switches and routers are configured as NTP clients to both servers. The network engineer uses ntp server 10.1.1.1 and ntp server 10.1.1.2. The device will automatically select the best server based on stratum (both stratum 2) and synchronization distance. If one server fails, the device switches to the other. In production, this provides redundancy. However, if both servers have the same stratum but one has high delay due to a congested link, the client may flap between them, causing frequent clock adjustments. The engineer can use ntp peer between the two servers to keep them in sync, reducing the offset between them. Common scale: hundreds of devices sending NTP requests every 64 seconds. The servers must handle the load; at 1000 clients, that's about 15 packets per second, which is trivial. But if the poll interval is set too low (e.g., 16 seconds), the load increases. Performance consideration: NTP uses very little bandwidth, but if the network has high jitter, the offset calculations become inaccurate.
Scenario 2: NTP Authentication for Security
In a financial institution, all network devices must use authenticated NTP to prevent time spoofing attacks. The engineer configures an MD5 key on the NTP server and distributes the same key to all clients. On the clients, they configure ntp authentication-key 1 md5 secretkey, ntp authenticate, ntp trusted-key 1, and ntp server 10.1.1.1 key 1. A common pitfall is forgetting the ntp trusted-key command—without it, the client will not accept the server's packets even if the key matches. Another issue: the server must have the same key configured and must trust the key as well. If the server does not have ntp trusted-key 1, it will not use the key for authentication, and the client will see 'authentication failed'. In production, the engineer must also ensure that the key is changed periodically. Misconfiguration: if the key string is wrong, the client will log 'NTP authentication failed' and the association will not sync. The engineer can verify with show ntp associations detail and look for 'authenticated: yes'.
Scenario 3: NTP over a Firewall
A branch office router needs to sync to a central NTP server across a WAN link with a firewall. The firewall must allow UDP port 123 from the router's public IP to the server's IP. Additionally, if the firewall performs stateful inspection, it must allow the return traffic. A common issue is that the firewall's ACL permits outbound NTP but blocks inbound responses because the router's source port is not 123 (NTP clients use ephemeral ports, typically >1023). The solution is to allow UDP 123 inbound from the server to the router's source port (any). Alternatively, configure the firewall to inspect NTP and allow return traffic based on state. Another issue: if the firewall uses NAT, the NTP server sees the NAT IP, not the real router IP. This is fine as long as the server can reach back. However, if the server has a restrict statement blocking the NAT IP, it will not respond. The engineer can verify with show ntp associations on the router: if reach is 0, the server is not responding. Traceroute from the router to the server will show where packets are dropped.
What the CCNA 200-301 Tests on NTP
The exam objective 4.4 (Troubleshoot NTP issues) expects you to:
Interpret the output of show ntp status and show ntp associations.
Identify why a device is not synchronizing (unreachable server, stratum too high, authentication failure, clock offset too large).
Understand the role of stratum, reachability, and authentication.
Know the default poll interval (64 seconds) and that the clock is stepped if offset > 128 ms.
Common Wrong Answers and Why Candidates Choose Them
1. Wrong: 'The NTP server is not configured.'
Many candidates see 'Clock is unsynchronized' and immediately think no NTP server is configured. But the real issue might be that the server is unreachable or authentication is failing. Always check show ntp associations first.
2. Wrong: 'The stratum of the client is too high.' Candidates confuse client stratum with server stratum. The client's stratum is 16 by default. It will sync to any server with stratum < 16. The problem is when the server's stratum is 16 (unsynchronized) or higher than the client's (impossible since client is 16). The correct check is the server's stratum.
3. Wrong: 'NTP authentication is not configured.'
If authentication is not configured, NTP works fine (no auth). The issue arises when authentication is configured but the key is not trusted or mismatched. Candidates see 'NTP authentication failed' and think they need to add ntp authenticate, but they already have it. The missing piece is often ntp trusted-key.
4. Wrong: 'The clock offset is too small.'
Some candidates think a small offset means everything is fine, but if the clock is unsynchronized, the offset displayed may be from a previous sync. The offset field in show ntp status is only meaningful if the clock is synchronized. If unsynchronized, the offset may be stale.
Specific Values and Commands
Default stratum on Cisco: 16 (unsynchronized).
Default poll interval: 64 seconds (dynamic range 16-1024).
Reachability: octal 377 (binary 11111111) means 8 consecutive successful polls.
show ntp associations: look for * (synced), + (candidate), ~ (configured).
show ntp status: 'Clock is synchronized' or 'unsynchronized'.
Decision Rule for Scenario Questions
If a question asks 'Why is the device not syncing to NTP?', follow this order: 1. Check if the server is reachable (ping, ACL). 2. Check the server's stratum (must be < 16). 3. Check authentication (if configured, ensure trusted key and matching keys). 4. Check if the clock offset is too large (> 1000 seconds). 5. Check if NTP is disabled on the interface (rare).
NTP uses UDP port 123; ACLs must permit it.
Default stratum on an unsynchronized Cisco device is 16.
show ntp status shows whether the clock is synchronized.
show ntp associations shows the * for the sync source and reachability in octal.
Reachability of 377 (octal) means 8 consecutive successful polls.
If the NTP server's stratum is 16, it is unsynchronized and will not sync clients.
NTP authentication requires both the key and the trusted-key configuration.
The clock is stepped if offset > 128 ms; ignored if offset > 1000 seconds.
Default poll interval is 64 seconds.
NTP can be authenticated with MD5 or SHA.
These come up on the exam all the time. Here's how to tell them apart.
NTP Client Mode
Client synchronizes to a server; server does not sync to client.
Client's stratum becomes server's stratum + 1.
Configured with `ntp server <ip>`.
Client does not provide time to the server.
Used for hierarchical time distribution.
NTP Peer Mode
Both devices synchronize to each other (symmetric active).
Both devices can have the same stratum (or one adjusts).
Configured with `ntp peer <ip>`.
Each peer can provide time to the other.
Used for redundancy between servers of same stratum.
Mistake
NTP uses TCP port 123 for reliable delivery.
Correct
NTP uses UDP port 123. It does not require reliable delivery because it sends periodic updates and can tolerate packet loss.
Many candidates assume time synchronization must be reliable, so they guess TCP.
Mistake
The client's stratum must be lower than the server's stratum.
Correct
The client's stratum is always one higher than the server's stratum after sync. The client will not sync to a server with stratum >= its own (client starts at 16).
Candidates invert the hierarchy: they think lower stratum is worse, but lower is better (closer to atomic clock).
Mistake
If authentication is configured, the client must have the same key, but the server does not need to trust the key.
Correct
Both client and server must have the same key configured and both must have the key trusted (or the server must trust the key for the client's association). On Cisco, the server also needs `ntp trusted-key` for the key to be used.
Candidates focus only on the client side, forgetting that NTP authentication is mutual.
Mistake
The reachability value 377 (octal) means the server is unreachable.
Correct
377 octal (255 decimal) means all 8 recent polls were successful (binary 11111111). A value of 0 means no successful polls.
Candidates misinterpret octal as decimal or think high numbers are bad.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
First, verify that the NTP server is reachable with ping. If ping succeeds, check `show ntp associations`. Look at the reachability column: if it's 0, the server is not responding. Possible causes: ACL blocking UDP 123, routing issue, or the server itself is not running NTP. If reachability is non-zero but no `*` appears, the server's stratum might be 16 (unsynchronized) or higher than the client's (which is 16 by default). Also, if authentication is configured, ensure you have `ntp authenticate` and `ntp trusted-key` commands. Finally, if the clock offset is too large (>1000 seconds), the client ignores the server. Manually set the clock close to the correct time with `clock set` and let NTP fine-tune. Exam tip: always check `show ntp status` first for synchronization state, then `show ntp associations` for details.
The reachability is an 8-bit shift register displayed in octal. Octal 377 (binary 11111111) means all 8 of the most recent NTP polls received a response. This indicates excellent reachability. A value of 0 means no responses. Values like 1 (octal 001), 3 (011), 7 (111), etc., indicate partial success. The register is updated each poll interval (default 64 seconds). Exam tip: you may see reachability in octal; convert mentally: 377 = all good, 0 = all bad.
First, confirm that both the client and server have the same authentication key configured with `ntp authentication-key <number> md5 <key>`. Then, ensure that NTP authentication is enabled globally with `ntp authenticate`. Finally, the key must be trusted: `ntp trusted-key <number>`. On the client, use `show ntp associations detail` to see if the association is authenticated. If it says 'authenticated: no', the packet was not authenticated. Check the server side similarly. Common mistake: forgetting `ntp trusted-key` on either side. Exam tip: the exam may show a configuration with the key but missing `ntp trusted-key`; that's the error.
Yes, you can use a hostname (e.g., `ntp server time.google.com`). However, the device must have DNS configured to resolve the name. Use `ip name-server <dns-ip>` and ensure the device can reach the DNS server. If DNS resolution fails, the NTP server will not be reachable. Exam tip: if the question shows a hostname and the device cannot ping the NTP server by name, check DNS configuration.
`ntp server` configures the device as a client of the specified server; the device will synchronize its clock to that server, but the server will not synchronize to the client. `ntp peer` configures symmetric active mode: both devices can synchronize to each other, providing mutual backup. Peers are typically used between servers of the same stratum. The client will prefer a server over a peer if both are available. Exam tip: you may see a scenario where two routers are configured as peers; they will sync to each other if one loses its upstream server.
NTP selects the sync source based on stratum first (lower is better). If two servers have the same stratum, it uses synchronization distance (a combination of delay and dispersion). If a higher-stratum server has a much lower distance, it might be selected? Actually, NTP will never select a higher stratum server over a lower stratum one if both are reachable. If your client selects a higher stratum, the lower stratum server might be unreachable or have a very high distance. Check reachability and delay/offset/dispersion in `show ntp associations`. Exam tip: the exam will not ask you to calculate distance, but you should know that stratum is the primary criterion.
By default, the poll interval starts at 64 seconds and can dynamically vary between 16 and 1024 seconds based on network conditions and dispersion. The client sends a request every poll interval. You can see the current poll interval in the `show ntp associations` output under the 'poll' column. Exam tip: the default poll interval is 64 seconds, but it can change; you don't need to memorize the exact algorithm.
You've just covered Troubleshoot: NTP Not Synchronizing — now see how well it sticks with free CCNA 200-301 practice questions. Full explanations included, no account needed.
Done with this chapter?