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 min read · Updated Sep 23, 2026

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.

Written & researched by Dr. Shahin Siami

Related Articles

Hands-On Lab: Configuring OSPF Virtual Links

This hands-on lab connects a disconnected area to the backbone using an OSPF virtual link, addressing a design violation where an area does not have a direct physical connection to Area 0, and verifies routes flow correctly once the virtual link is established.

Continue

Hands-On Lab: Configuring an OSPF NSSA Area

This hands-on lab configures Area 1 as an NSSA, redistributing a local external route directly from within that area and verifying it propagates as a Type 7 LSA before being translated to Type 5 at the ABR, while inter-area routes from elsewhere remain blocked exactly as in a standard stub area.

Continue

Hands-On Lab: Configuring OSPF Stub and Totally Stubby Areas

This hands-on lab configures a leaf area as a standard stub area, then upgrades it to a totally stubby area, comparing the routing table size at each stage and verifying only a default route remains once fully configured.

Continue

Hands-On Lab: Configuring Multi-Area OSPF with Route Summarization

This hands-on lab configures multi-area OSPF across three routers, designating an ABR that summarizes several subnets from a leaf area into a single route advertised toward the backbone, tying together the area design and summarization concepts covered earlier in this series.

Continue

Hands-On Lab: Configuring EIGRP for IPv6

This hands-on lab configures EIGRP for IPv6 between two routers, activating the protocol directly on each interface similar to OSPFv3's approach, and highlights the mandatory router ID requirement unique to EIGRPv6.

Continue

Hands-On Lab: Configuring OSPFv3 for IPv6

This hands-on lab configures OSPFv3 between two routers to dynamically route IPv6 traffic, comparing its configuration syntax against the OSPFv2 labs covered earlier in this series while highlighting the interface-level activation approach OSPFv3 uses.

Continue