First, the essential ideas
- NTP
- Network Time Protocol exchanges timing information to estimate clock difference and discipline a local clock. It commonly uses UDP port 123; a successful ping does not test that service.
- Client and server
- An NTP client asks a configured server for time. A synchronized network device may also serve downstream clients. The command ntp server on the client names its upstream source.
- Stratum
- Stratum indicates distance in the time-reference hierarchy, not a quality score or timezone. A directly reference-connected server is normally stratum 1; 16 indicates unsynchronized state.
- Offset, delay and jitter
- Offset estimates clock difference, delay estimates path time and jitter describes variation among timing samples. These are measurements to interpret together, not interchangeable names for latency.
- Association and reach
- An association is NTP's relationship with a time source. IOS reach is an octal bit history of recent successful polls; 377 represents eight successful recent polls, not 377 milliseconds.
- UTC and timezone
- Coordinated Universal Time is the common reference scale. A timezone changes displayed local time; it does not make a clock synchronize or change the underlying source quality.
- Local reference and trust
- A router can serve its own clock in an isolated lab. Agreement with that clock proves relative synchronization only, not correct UTC, authenticated time or a production-quality reference.
- Console and observation
- Open the named GNS3 node's Console. > is user EXEC, # privileged EXEC, and (config)# configuration. Capture actual values and observation times; the lesson supplies predictions, not measured output.
The exercise has two claims to keep separate: whether Client1 follows Clock1, and whether Clock1 has accurate real-world time. Only the first can be explored here. The artificial clock is deliberately documented so a synchronized display is never mistaken for validated UTC.
See the idea
A clock display is not a verified time source
Check configuration, recent exchanges and selected state; then ask whether the reference is trustworthy.
Name the source
Client1 names Clock1 at 192.0.2.1. A configured association shows intent, not successful replies.
What this model leaves out: Conceptual evidence ladder, not packet wiring. Clock1's local reference is artificial; the exercise measures neither UTC accuracy nor authentication.
Full visual explanation and references
Three evidence levels compare a configured NTP source, recent poll replies and selected synchronization. Reference trust remains a separate question.
Conceptual evidence ladder, not packet wiring. Clock1's local reference is artificial; the exercise measures neither UTC accuracy nor authentication.
- Name the source
Client1 names Clock1 at 192.0.2.1. A configured association shows intent, not successful replies.
www.cisco.com - Inspect the exchanges
Read reach and timing fields over multiple polls. A successful ping is not evidence of successful NTP exchanges.
www.rfc-editor.orgwww.cisco.com - Verify and qualify
Check selected synchronization and clock detail. Agreement with this artificial local source does not prove correct UTC.
www.rfc-editor.orgwww.cisco.com
One idea at a time
Start with something familiar.
Think of a timestamp as a measurement with a source. Before comparing two logs, ask what each clock follows and whether it was synchronized at the time. You do not need to memorize NTP mathematics to distinguish a configured source from a selected working one.
Why learn this?
Incorrect time can reverse the apparent order of an incident, affect certificate validity checks and make records hard to correlate. Making two clocks agree is useful, but agreement with an incorrect source can reproduce the same error everywhere.
An everyday comparison
Two people can set their watches from the same wall clock. Their watches may agree even if that wall clock is five minutes wrong.
What happens in a network
The local-reference server is the wall clock, and its client adjusts toward it. Agreement supports consistent local timestamps but does not independently establish correct UTC.
Where the comparison stopsNTP estimates network delay and filters samples instead of visually reading a clock. A metaphor cannot predict synchronization time, offset accuracy or resistance to an untrusted source.
Follow one worked example
- Separate the displayed time from its source.
Read clock detail and NTP status before configuration. The display can contain a plausible date even when NTP has selected no source.
Why: A human-readable clock is not evidence that packets from a valid time source were accepted.
- Create one declared local reference.
Clock1 serves a manually set training time at stratum 8. Client1 names 192.0.2.1 as its upstream server.
Why: A deliberately high local stratum and full isolation keep the demonstration distinct from a trustworthy production design.
- Observe several samples.
Check associations and status over multiple polls. Record actual reach, selected source and offset as they evolve.
Why: An initial zero reach or lack of selection may be transient; a fixed promise of immediate convergence would be misleading.
- Restore the source after a bounded fault.
Client1 is pointed at unused .99, then restored to .1. Its displayed clock continues moving even when its new source cannot reply.
Why: Loss of fresh synchronization is not the same as a stopped clock or an immediate visible jump.
Your first small task
On paper, compare three statements: the clock displays 12:00; ping to the time server replies; NTP selected the intended source. Rank what each establishes and identify the remaining question about reference trust.
Show a hint
Ask which protocol and which source each statement actually tests.
Check the expected result
They establish displayed time, ICMP reachability and a selected NTP relationship respectively. None alone proves the selected source's UTC accuracy or authenticity.
Pause and explain it in your own words
Two routers agree within a small offset. Must their time be correct?
Show a hint
Both routers may be following the same manually incorrect source.
Show the explanation
No. Small relative offset shows agreement with the selected reference. The reference can still be wrong or untrusted, which this disconnected local-clock exercise deliberately does not resolve.
Short answer
What should you understand today?
NTP estimates clock offset using repeated exchanges with a time source. Configure the client to use an appropriate server, then verify associations, synchronization state and clock detail over time. A displayed clock, a successful ping or a low stratum alone does not prove trustworthy time. This disconnected lab synchronizes to an explicitly artificial local reference, not verified UTC.
Before you begin
Learning targets
- Recall Day 15 IOS modes and how to open a GNS3 Console independently of the data interface.
- Use two independently entitled C8000v IOS XE 17.12.1a nodes in GNS3 2.2.55.
- Keep the project disconnected; changing clock settings on production systems can disrupt logs and authentication.
- Explain client/server roles and read stratum, reach, offset and synchronization state.
- Configure one isolated local-reference server and one client.
- Observe acquisition across multiple polling intervals rather than promising instant synchronization.
- Repair one wrong upstream address and repeat the association checks.
- Explain why timezone, certificate validity and trustworthy reference selection are different concerns.
Words you will meet
Open a word when you need its meaning. You do not need to memorize the whole list before reading.
NTP
Network Time Protocol exchanges timing information to estimate clock difference and discipline a local clock. It commonly uses UDP port 123; a successful ping does not test that service.
Client and server
An NTP client asks a configured server for time. A synchronized network device may also serve downstream clients. The command ntp server on the client names its upstream source.
Stratum
Stratum indicates distance in the time-reference hierarchy, not a quality score or timezone. A directly reference-connected server is normally stratum 1; 16 indicates unsynchronized state.
Offset, delay and jitter
Offset estimates clock difference, delay estimates path time and jitter describes variation among timing samples. These are measurements to interpret together, not interchangeable names for latency.
Association and reach
An association is NTP's relationship with a time source. IOS reach is an octal bit history of recent successful polls; 377 represents eight successful recent polls, not 377 milliseconds.
UTC and timezone
Coordinated Universal Time is the common reference scale. A timezone changes displayed local time; it does not make a clock synchronize or change the underlying source quality.
Local reference and trust
A router can serve its own clock in an isolated lab. Agreement with that clock proves relative synchronization only, not correct UTC, authenticated time or a production-quality reference.
Console and observation
Open the named GNS3 node's Console. > is user EXEC, # privileged EXEC, and (config)# configuration. Capture actual values and observation times; the lesson supplies predictions, not measured output.
Time is operational evidence with a dependency
Network logs normally carry timestamps, but a timestamp is only as useful as its clock context. Record the source, synchronization state and timezone before combining events from several devices. A timestamp difference can reflect real event order, clock error or different display offsets. Do not silently adjust original evidence to make a preferred story fit.
- A plausible date is not proof of synchronization.
- Keep original timestamps and record any later normalization separately.
Client configuration names an upstream source
On IOS XE, ntp server followed by an address is entered on the device that will act as a client of that address. It does not mean the local device has suddenly become the named server. A device can provide time downstream as part of an NTP hierarchy, but its own upstream quality matters. NTP service reachability is separate from ICMP reachability.
- Roles describe relationships; a single device can have more than one role.
- The isolated exercise uses direct IP addresses, avoiding an additional DNS dependency.
Read stratum, reach and selection together
Stratum expresses reference hierarchy depth rather than a guarantee of accuracy. A lower advertised number is not sufficient proof of a better source. Reach summarizes recent polls in octal; 377 represents eight successful recent polls. Offset and delay describe timing observations with units that must be read from the actual platform display. Selection markers identify a chosen source but do not authenticate it.
- A reachable source can be unsuitable for synchronization.
- Record actual displayed units rather than guessing from a column name.
A local-reference server is a deliberate lab compromise
This lesson sets Clock1 manually and uses ntp master 8, the syntax on the selected older 17.12 reference image. Current generic Cisco documentation may use ntp primary terminology in newer releases. Verify release-specific help and do not paste a renamed command blindly. Serving a local clock is useful for this disconnected experiment but can override valid time if carelessly introduced into a real network.
- Never advertise this artificial source into an employer or public network.
- Do not set a low stratum to make an untrusted source appear more authoritative.
A failed source does not freeze the clock
The local clock continues running when fresh NTP samples are unavailable. Existing synchronization status and uncertainty evolve according to implementation and elapsed time. Repointing a client to an unused address need not immediately produce an obvious wall-clock jump. Observe associations across polling intervals, and record uncertainty instead of waiting for a preferred dramatic result.
- Missing replies, source selection and clock drift are related but distinct observations.
- Repair the configured address and verify recovery over time.
Use trustworthy time beyond this two-node exercise
Production time design includes approved sources, access restrictions, appropriate authentication where supported, monitoring and documented fallback. Timezone settings only change presentation. Certificate checks depend on validity periods, so wrong time can cause a valid credential to appear expired or not yet valid; NTP does not itself issue or validate those credentials.
- Small offset cannot independently prove source trust or UTC accuracy.
- Authentication and production-grade time resilience remain outside this lab.
Real-world walkthrough
A timeline looks reversed after a time-source change
In a fictional investigation, two devices disagree about whether a management login happened before a link failure. One device recently lost its configured time source. The operator must preserve the original logs, inspect clock state and explain uncertainty instead of editing timestamps to manufacture a clean chronology.
- Record each device's clock detail, timezone, NTP status and source association alongside its original log records.
- Separate observed event timestamps from the time at which you collected the logs. Do not pretend the collection time proves historical synchronization.
- Check the configured source address and network path, then inspect whether recent NTP polls succeeded and whether a source was selected.
- Restore the approved source and observe new synchronization without rewriting the old evidence.
- Build a qualified incident timeline using corroborating events and record any unresolved clock uncertainty explicitly.
Guided GNS3 lab
One local time server and one recovering client
Configure isolated server/client roles and observe source loss and restoration using NTP evidence. Authoring did not run IOS or measure convergence, offset, drift or UTC accuracy.
Addressing plan
| Device | Interface | Address | Purpose |
|---|---|---|---|
| Clock1 | GigabitEthernet1 | 192.0.2.1/24 | NTP server address. |
| Client1 | GigabitEthernet1 | 192.0.2.2/24 | NTP client address. |
| Fault target | No node | 192.0.2.99 | Deliberately unused source; do not create an endpoint. |
Set up the lab
- Create two fresh nodes and the single listed link; keep each Console open and record actual release and interface names.
- Capture prelab snapshots. The clock set value below is artificial; never execute it on production equipment or the host computer.
- The 17.12 reference uses ntp master. If the parser differs, record the release and use its official command reference before adapting; do not claim an unsupported command succeeded.
- Paper alternative: draw the hierarchy and annotate predicted reach and synchronization changes. Without entitled images, all timing and convergence observations remain unmeasured.
Inspect and address Clock1
In GNS3, right-click Clock1 and choose Console before typing. Start at > or # on the disposable node. Type each line without the prompt and press Enter. Stop on a syntax error; retain the console for recovery.
enable
show version
show clock detail
configure terminal
interface GigabitEthernet1
ip address 192.0.2.1 255.255.255.0
no shutdown
endWhat each command means
enable- Enter privileged EXEC (#) from user EXEC (>); use only your authorized lab credentials.
show version- Record the exact IOS XE image and verify the reference release.
show clock detail- Record initial clock display and source information before changing it.
configure terminal- Enter global configuration mode from privileged EXEC (#); accepted changes affect the running device.
interface GigabitEthernet1- Select the only cable toward Client1.
ip address 192.0.2.1 255.255.255.0- Assign the server's /24 lab address.
no shutdown- Enable the selected data interface.
end- Return to privileged EXEC (#). This neither saves the configuration nor reverses accepted changes.
- What you should see
- The planned address is configured; no reference accuracy is established.
- Why this step matters
- An initial record prevents confusing an inherited clock state with a result of this exercise.
Address Client1 and verify the link
In GNS3, right-click Client1 and choose Console before typing. Start at > or #; do not configure NTP until the link is checked. Type each line without the prompt and press Enter. Stop on a syntax error; retain the console for recovery.
enable
configure terminal
interface GigabitEthernet1
ip address 192.0.2.2 255.255.255.0
no shutdown
end
ping 192.0.2.1
show ntp statusWhat each command means
enable- Enter privileged EXEC (#) from user EXEC (>); use only your authorized lab credentials.
configure terminal- Enter global configuration mode from privileged EXEC (#); accepted changes affect the running device.
interface GigabitEthernet1- Select the port cabled to Clock1.
ip address 192.0.2.2 255.255.255.0- Assign a distinct host address on the same /24.
no shutdown- Enable Client1's interface.
end- Return to privileged EXEC (#). This neither saves the configuration nor reverses accepted changes.
ping 192.0.2.1- Test local IP reachability, not UDP 123 or synchronization.
show ntp status- Record the initial NTP state without assuming it is synchronized.
- What you should see
- Clock1 should reply to ping; NTP state remains separately observed.
- Why this step matters
- A working cable and address path are prerequisites, not proof of time service health.
Declare the artificial local reference
In GNS3, right-click Clock1 and choose Console before typing. Start at #. The date below is a synthetic training value, never current-time evidence. Type each line without the prompt and press Enter. Stop on a syntax error; retain the console for recovery.
clock set 12:00:00 20 October 2026
configure terminal
ntp master 8
end
show ntp status
show clock detailWhat each command means
clock set 12:00:00 20 October 2026- Set this disposable router to the declared artificial time: hours:minutes:seconds, day, month and year.
configure terminal- Enter global configuration mode from privileged EXEC (#); accepted changes affect the running device.
ntp master 8- Serve the local clock at stratum 8 on the selected 17.12 image; this is not an external UTC reference.
end- Return to privileged EXEC (#). This neither saves the configuration nor reverses accepted changes.
show ntp status- Inspect whether the local reference is operating and record its actual state.
show clock detail- Record the source description after the local-reference configuration.
- What you should see
- Clock1 should become a local-reference source, not a validated UTC source.
- Why this step matters
- The high local stratum and isolation are explicit teaching choices, not production recommendations.
Configure the upstream client association
In GNS3, right-click Client1 and choose Console before typing. Start at #. Name Clock1 as the source and leave the client's clock otherwise unchanged. Type each line without the prompt and press Enter. Stop on a syntax error; retain the console for recovery.
configure terminal
ntp server 192.0.2.1
end
show ntp associations
show ntp statusWhat each command means
configure terminal- Enter global configuration mode from privileged EXEC (#); accepted changes affect the running device.
ntp server 192.0.2.1- Create an NTP client association to Clock1's lab address.
end- Return to privileged EXEC (#). This neither saves the configuration nor reverses accepted changes.
show ntp associations- Inspect the new association, reach and selection markers.
show ntp status- Inspect synchronization state separately from the configured address.
- What you should see
- The association should appear; source selection may require several polls.
- Why this step matters
- Configuration acceptance does not guarantee immediate acquisition or a usable upstream source.
Record the synchronized baseline over time
In GNS3, right-click Client1 and choose Console before typing. Start at #. Repeat these inspections over several displayed poll intervals; do not claim a fixed convergence deadline. Type each line without the prompt and press Enter. Stop on a syntax error; retain the console for recovery.
show ntp associations detail
show ntp status
show clock detailWhat each command means
show ntp associations detail- Record source, reach, poll interval, offset and delay with their displayed units.
show ntp status- Check whether the intended source is selected and synchronization is reported.
show clock detail- Compare displayed time and source with Clock1 without treating agreement as UTC proof.
- What you should see
- Client1 should eventually follow Clock1 if the platform and path support the configuration. Record actual values and elapsed time.
- Why this step matters
- If no stable baseline forms, troubleshoot before creating the intentional source fault.
Point only the client at an unused source
In GNS3, right-click Client1 and choose Console before typing. Start at # after recording a working baseline. Keep the physical link and Clock1 untouched. Type each line without the prompt and press Enter. Stop on a syntax error; retain the console for recovery.
configure terminal
no ntp server 192.0.2.1
ntp server 192.0.2.99
end
ping 192.0.2.1
show ntp associations detail
show ntp statusWhat each command means
configure terminal- Enter global configuration mode from privileged EXEC (#); accepted changes affect the running device.
no ntp server 192.0.2.1- Remove only the known upstream client association.
ntp server 192.0.2.99- Create a deliberate wrong-source association to an unused address.
end- Return to privileged EXEC (#). This neither saves the configuration nor reverses accepted changes.
ping 192.0.2.1- Confirm the actual server's IP path still works.
show ntp associations detail- Observe the unused source's reply history over multiple polls.
show ntp status- Record current state without expecting an immediate clock freeze or jump.
- What you should see
- The wrong source should receive no valid NTP replies, while Clock1 remains pingable.
- Why this step matters
- This isolates a configuration dependency and teaches that a running local clock is not fresh synchronization.
Restore the intended upstream address
In GNS3, right-click Client1 and choose Console before typing. Start at #. Restore the previous association and repeat the same observation sequence. Type each line without the prompt and press Enter. Stop on a syntax error; retain the console for recovery.
configure terminal
no ntp server 192.0.2.99
ntp server 192.0.2.1
end
show ntp associations detail
show ntp status
show clock detailWhat each command means
configure terminal- Enter global configuration mode from privileged EXEC (#); accepted changes affect the running device.
no ntp server 192.0.2.99- Remove the deliberately unused source.
ntp server 192.0.2.1- Restore the original Clock1 association.
end- Return to privileged EXEC (#). This neither saves the configuration nor reverses accepted changes.
show ntp associations detail- Observe renewed polls and eventual source selection over time.
show ntp status- Check synchronization state after reacquisition.
show clock detail- Record final displayed time and source without asserting UTC accuracy.
- What you should see
- Successful polling and selection should recover; actual convergence time remains your observation.
- Why this step matters
- The exact inverse plus retest is the rollback, not manually forcing Client1 to show a desired clock value.
Preserve evidence and remove the training reference
Retain baseline, wrong-source and restored observations with collection times. Stop both GNS3 nodes and revert the prelab snapshots before reconnecting any future project. Keep the artificial-clock label with all notes.
- What you should see
- The final record distinguishes relative synchronization from trusted UTC and contains no invented offsets.
- Why this step matters
- Removing the entire disposable configuration prevents a synthetic source from being reused accidentally as an authoritative production clock.
Verify
- Confirm Client1's configured and selected source is Clock1, not merely any source.
- Record actual reach in octal, polling interval and displayed timing units across multiple observations.
- Compare successful ping to Clock1 with absent NTP replies from the intentional .99 source.
- After restoration verify the intended association and state again; label all UTC accuracy, drift and authentication claims unmeasured.
Troubleshoot
- Ping works but NTP does not select: inspect UDP 123 reachability, source synchronization, configured address and actual association details.
- Initial reach is zero: allow multiple poll intervals and observe whether it changes; do not promise an exact convergence time or immediately reset the router.
- Clock display differs by a fixed number of hours: inspect timezone presentation separately from synchronization before changing a source.
- Newer IOS rejects ntp master: stop and check release-specific ntp primary syntax; do not mix platforms or claim a parser error is successful configuration.
GNS3 does not provide Cisco software images. Use Cisco images only when the applicable license or entitlement permits this environment. Do not share or redistribute image files. Cisco Modeling Labs is an official alternative; its supplied reference images are licensed for CML, not automatically for export to GNS3. Use the labeled paper alternative when authorized software is unavailable. No emulator execution is claimed by this lesson.
- Stop both isolated nodes and revert their prelab snapshots before any reuse outside this project.
- Retain synthetic-clock notes separately from real incident timestamps; never present the example date as measured UTC.
Practice set
Answer before you reveal
01What does ntp server 192.0.2.1 do on Client1?
The command establishes the client relationship to the remote address; it does not make that address belong to Client1.
02What does reach 377 represent?
It is not a millisecond measurement, a timezone or the stratum. Other association fields describe timing and hierarchy.
03Does stratum 8 mean eight milliseconds of error?
Source quality and observed timing need separate evaluation. A manually served clock can advertise a stratum while being wrong about UTC.
04Why can the clock keep moving after source loss?
Loss of synchronization changes confidence and future correction behavior; it is not necessarily an immediate frozen or visibly reset clock.
05Why not correct historical logs after synchronization recovers?
Preserve original records and document uncertainty. Rewriting times can destroy evidence of what the device actually recorded.
06What does this lab prove about time authentication?
The isolated client/server exchange is a bounded synchronization exercise, not evidence that the source is cryptographically trustworthy.
Knowledge check
Quiz: prove the reasoning
Keep these
Technical takeaways
- Clock display, IP reachability and NTP synchronization are separate evidence.
- Stratum is hierarchy depth, not an accuracy guarantee.
- Read reach as octal poll history and preserve timing units.
- A local-reference lab demonstrates agreement, not trustworthy UTC.
- Recover the source and document historical uncertainty honestly.