Cisco Certified Network Associate (CCNA) 200-301 · Free study guide

Objective 4.2 — Configure NTP clients and servers

Accurate shared time makes logs, authentication, certificates, automation, and incident reconstruction trustworthy. Network Time Protocol creates a hierarchy of clocks rather than asking every device to trust its own oscillator.

Client operation

An NTP client queries configured servers and evaluates their time quality and reachability. The device selects a suitable association and adjusts its clock. Configuration only names a candidate; synchronization state proves whether the candidate is currently usable.

Prefer multiple approved sources when the design supports them. Restrict who can query or influence time, and use platform protection or authentication features where required by policy.

Server mode

A synchronized network device can provide time to downstream clients. This builds a hierarchy that reduces external dependencies for internal devices. A device configured to act as a server should itself have a trustworthy reference. Making an unsynchronized clock authoritative creates consistent but wrong timestamps.

Stratum represents distance from a reference clock. Lower is closer, but selection also considers reachability and clock quality. Stratum is not a time zone.

Time zones and UTC

NTP distributes an absolute time reference; display time zones are a separate local presentation choice. Operations often record logs in UTC to simplify cross-site correlation. Correct timezone display with an unsynchronized clock is still incorrect, and synchronized UTC with a different display zone can still represent the same instant.

IOS command map

Configure a client association with an approved example such as ntp server 192.0.2.123. A downstream router can in turn point its own ntp server command at the synchronized device's reachable address. A lab-only ntp master 8 makes an IOS-style device advertise itself as an authoritative source at the selected stratum; use this command with extreme caution because it can override valid sources or distribute a wrong free-running clock.

Use show ntp associations to inspect candidates, reachability, and the selected peer, show ntp status to confirm synchronization and stratum, and show clock detail to inspect the device clock and source indication. Exact symbols and fields differ across releases, so interpret the legend in the displayed output.

Worked scenario

R1 synchronizes to two approved upstream sources. R2 and R3 use R1 as one source and a second internal server as another. Configure the associations and verify which peer is selected. If R1 loses upstream synchronization, downstream devices should not blindly treat its free-running clock as the best source.

Verification evidence

Inspect associations, selected peer, reachability, stratum, offset, and clock status. Compare log timestamps across devices after synchronization. Check routing and ACLs if requests fail. A ping to the server proves IP reachability, not that NTP responses are accepted or the clock is synchronized.

Common traps

• Treating a server command as proof of synchronization.
• Confusing stratum with timezone.
• Building a circular or unreferenced time hierarchy.
• Trusting one source without a failure plan.
• Changing the clock manually while ignoring the NTP fault.

Readiness checklist

• I can configure client and server roles.
• I can interpret selected and candidate associations.
• I separate absolute time from display zone.
• I verify synchronization, not merely reachability.