Hands-On Lab: Configuring NTP

This hands-on lab configures one router as an NTP server with a manually set clock and a second router as an NTP client synchronizing to it, verifying the client's clock converges to match the server over the network.

NTP Server ConfigurationNTP Client SynchronizationClock Stratum

~3 دقیقه مطالعه · آخرین به‌روزرسانی ۱ مهر ۱۴۰۵

Lab Objective

Manually set the clock on one router and configure it as an NTP server, configure a second router as an NTP client pointing to the first, and verify the client's clock synchronizes to match the server.

Lab Purpose

Accurate, synchronized time across every network device is essential for correlating log timestamps during troubleshooting and for certain security features like certificate validation. NTP is the standard protocol that keeps every device's clock aligned automatically rather than relying on manual clock-setting on each device individually.

Lab Topology

R1 (NTP server) ---- Serial0/0/0 ------ Serial0/0/0 ---- R2 (NTP client)

R1: 10.15.15.1/30
R2: 10.15.15.2/30

Task 1: Manually Set R1's Clock

Set R1's clock to a specific known date and time.

Task 2: Configure R1 as an NTP Master

Configure R1 to act as an authoritative NTP time source.

Task 3: Verify R2's Clock Is Different Before Syncing

Check R2's current clock and confirm it does not match R1's, since no synchronization has occurred yet.

Task 4: Configure R2 as an NTP Client

Point R2 to R1 as its NTP time source.

Task 5: Verify Synchronization

Confirm R2's clock converges to match R1's, and check the NTP association status.

Solution and Verification

R1# clock set 14:00:00 15 June 2026

R1(config)# ntp master 3

-- The "3" sets R1's stratum level -- stratum
-- indicates distance from an authoritative
-- reference clock, with lower numbers being
-- more authoritative; "ntp master" makes R1
-- itself the authoritative source for this lab

R2# show clock

*10:42:18.123 UTC Mon Jan 12 2026
-- R2's clock is completely different from
-- R1's manually set time, confirming no
-- synchronization has occurred yet

R2(config)# ntp server 10.15.15.1

R2# show ntp associations

address         ref clock    st  when  poll  reach  delay  offset
*~10.15.15.1     127.127.1.1   3    12    64    17   4.2    0.891
-- The asterisk (*) indicates R2 has selected
-- this as its synchronized time source

R2# show clock

14:03:22.456 UTC Mon Jun 15 2026
-- R2's clock now matches R1's, confirmed
-- synchronized rather than in a free-running
-- state (shown without the leading asterisk
-- that indicates an unsynchronized clock)

Key Takeaway

The asterisk in show ntp associations output is the definitive confirmation that synchronization has actually succeeded — a configured NTP server with no asterisk next to it means the client has not yet synced with that source, which is the first thing to check when device clocks remain mismatched despite NTP appearing to be configured correctly.

نوشته و پژوهش‌شده توسط دکتر شاهین صیامی

مقالات مرتبط

Hands-On Lab: Final Comprehensive CCNP Troubleshooting Challenge (BGP, DMVPN, and QoS Integration)

This hands-on lab presents a complex multi-layer failure across an integrated BGP-over-DMVPN topology combined with QoS marking, requiring systematic diagnosis of a route reflector misconfiguration, an NHRP registration failure, and an incorrectly applied QoS policy simultaneously affecting the same network.

ادامه

Hands-On Lab: Configuring BGP over DMVPN

This hands-on lab runs iBGP as the routing protocol across the same DMVPN hub-and-spoke topology used in the two previous labs, configuring the hub as a route reflector so spokes learn each other's routes without a full iBGP mesh, combining two previously separate concepts into one integrated design.

ادامه

Hands-On Lab: Configuring OSPF over DMVPN

This hands-on lab runs OSPF as the dynamic routing protocol across the same DMVPN hub-and-spoke topology, configuring the tunnel interface as an OSPF point-to-multipoint network type to correctly handle the hub-and-spoke adjacency pattern without requiring the broadcast network type's DR/BDR election.

ادامه

Hands-On Lab: Configuring EIGRP over DMVPN

This hands-on lab runs EIGRP as the dynamic routing protocol across the DMVPN hub-and-spoke topology built in earlier labs, verifying neighbor relationships form correctly across the multipoint tunnel and routes propagate without requiring per-spoke static configuration on the hub.

ادامه

Hands-On Lab: Configuring HSRP MD5 Authentication

This hands-on lab configures MD5 authentication on an HSRP group, verifying two routers with matching authentication strings form a normal active/standby relationship while a router with a mismatched string is excluded from the group entirely.

ادامه

Hands-On Lab: Configuring Cisco Umbrella-Style DNS Security via DNS Forwarding Redirection

This hands-on lab configures a router to redirect all client DNS queries toward a security-focused DNS resolver using DNS forwarding interception, approximating cloud-delivered DNS security enforcement without requiring per-client configuration changes.

ادامه