NHPREP — Hands-On CCNA, CCNP, CCIE Labs & Networking Courses

Lab Objectives

Configure NTP on routers so they synchronize time to a central NTP server (10.10.101.230).
Verify NTP synchronization using show ntp status and show ntp associations.
Understand why correct time matters in production networks (logs, AAA, certificates).

Lab Tasks (Try It Yourself First!)

Complete these tasks WITHOUT looking at the solution below. Use ? and show commands to figure it out.

Task 1: Configure NTP on R1

Point R1 to the NTP server at 10.10.101.230 so the router will synchronize its clock.

Parameters:

NTP server: 10.10.101.230

Task 2: Configure NTP on R2, R3, and R4

On each of the remaining routers (R2, R3, R4) configure the same NTP server (10.10.101.230) as the time source.

Parameters:

NTP server: 10.10.101.230

Task 3: Verify time synchronization

On each router run verification commands to prove the device is synchronizing to 10.10.101.230. Capture show ntp status, show ntp associations, and check the running-config for the ntp server entry.

Think About It: If show ntp status reports "unsynchronized", what are the possible network-level and configuration-level causes? Which would you check first in a production environment and why?

Lab Solution

Toplogy (BASE LAB TOPOLOGY — exact IPs on every interface)

                [Internet]
               203.0.113.1
                    |
               R1 (Gateway)
              Gi0/0: 10.10.10.1
              Gi0/1: 10.10.20.1
              Gi0/2: 10.10.30.1
              /     |     \
           R2      R3      R4

Gi0/0: 10.10.10.2 | Gi0/0: 10.10.30.2 Gi0/1: 10.10.40.1 | / \ | S1 S2 S3 / \ | /
PC1 PC2 PC3 PC4 PC5

Note: The NTP server used in this lesson is 10.10.101.230 (management server). In many production networks the NTP server resides in a management VLAN or an external time service reachable via routing.

Task 1 Solution: Configure NTP on R1

What we are doing: Configure R1 as an NTP client that uses the management NTP server 10.10.101.230. This tells R1 to contact that address over UDP/123 and adjust its system clock to match the server. Accurate time ensures logs, AAA timestamps, and certificates are consistent.

R1# configure terminal
R1(config)# ntp server 10.10.101.230
R1(config)# end
R1# write memory

What just happened:

configure terminal — enter global configuration mode so we can make persistent changes.
ntp server 10.10.101.230 — registers 10.10.101.230 as a remote NTP server. The router will attempt to associate with it and synchronize time.
end — exit configuration mode.
write memory — save the running configuration to startup so the NTP setting persists across reloads.

Verify:

R1# show running-config | include ntp
ntp server 10.10.101.230

R1# show ntp associations
address         ref clock       st  when  poll  reach  delay  offset   disp
*~10.10.101.230  .INIT.          16    12    64    377   0.123  -0.002  0.056

R1# show ntp status
Clock is synchronized, stratum 2, reference is 10.10.101.230
nominal freq is 250.0000 Hz, actual freq is 250.0000 Hz, precision is 2**10
reference time: D1E4A2E4.12345678 (Tue Apr  2 12:34:12.000 2025)
root delay = 0.025 s, root dispersion = 0.034 s, peer dispersion = 0.002 s

Tip: The * before the server in show ntp associations indicates the currently selected synchronization source. A ~ or + symbol denotes candidate or pooled associations depending on platform/version.

Task 2 Solution: Configure NTP on R2, R3, R4

What we are doing: Repeat the NTP client configuration on the other routers so all devices point to the same authoritative time source (10.10.101.230). In production, using a single management NTP server centralizes time and avoids drift.

On each router (example shown for R2; repeat on R3 and R4):

R2# configure terminal
R2(config)# ntp server 10.10.101.230
R2(config)# end
R2# write memory

What just happened:

Each router now knows the address of the NTP server and will attempt to form an association and synchronize the local clock.
Centralized time reduces mismatches across logs and security events.

Verify (example output for R2):

R2# show running-config | include ntp
ntp server 10.10.101.230

R2# show ntp associations
address         ref clock       st  when  poll  reach  delay  offset   disp
+ 10.10.101.230  .INIT.          16    10    64    377   0.130  -0.003  0.060

R2# show ntp status
Clock is synchronized, stratum 2, reference is 10.10.101.230
nominal freq is 250.0000 Hz, actual freq is 250.0000 Hz, precision is 2**10
reference time: D1E4A2F0.22334455 (Tue Apr  2 12:34:56.000 2025)
root delay = 0.027 s, root dispersion = 0.039 s, peer dispersion = 0.003 s

Real-world note: In production you may have multiple upstream NTP servers for redundancy and use ntp server lines for each. You can also use ntp peer or authentication for secure time sync when necessary.

Task 3 Solution: Verify time synchronization for all routers

What we are doing: Confirm synchronization and that the router is actively using the server as its reference clock.

R3# show ntp associations
address         ref clock       st  when  poll  reach  delay  offset   disp
*~10.10.101.230  .INIT.          16    11    64    377   0.128  -0.002  0.058

R3# show ntp status
Clock is synchronized, stratum 2, reference is 10.10.101.230
reference time: D1E4A300.99887766 (Tue Apr  2 12:35:00.000 2025)
root delay = 0.026 s, root dispersion = 0.035 s

show ntp associations — lists NTP peers/servers and the selection status. Look for * to show the chosen server.
show ntp status — summarizes whether the local clock is synchronized and which reference is being used.

Troubleshooting Scenario

Scenario: NTP shows "unsynchronized"

Symptom: show ntp status on R4 returns "Clock is unsynchronized" and show ntp associations shows no * or shows the server with reachability 0.

Your task: Find and fix the issue.

Hint: First verify basic IP reachability to 10.10.101.230 (ICMP) and ensure UDP/123 is not blocked by an ACL.

Solution:

Ping the server from R4:

R4# ping 10.10.101.230
Protocol [ip]:
Sending 5, 100-byte ICMP Echos to 10.10.101.230, timeout is 2 seconds:
!!!!! (or .!!!! if intermittent)

If pings fail, fix routing (add static routes or enable routing protocol) so R4 can reach 10.10.101.230.

If pings succeed, verify there is no ACL blocking UDP/123 on the path and that the server is actually running NTP.
After fixing reachability or ACL, wait a minute and re-check:

R4# show ntp associations
R4# show ntp status

When reach becomes non-zero and * appears, the device is synchronizing.

Important: In production, firewalls commonly block NTP. Confirm UDP 123 is permitted between devices and the NTP server, and consider using authenticated NTP if server trust is a concern.

Verification Checklist

ntp server 10.10.101.230 present in running-config on R1, R2, R3, R4
show ntp associations shows an association to 10.10.101.230 (look for * on at least one device)
show ntp status indicates "Clock is synchronized" on each router (or on most devices if hierarchical)

Common Mistakes

Symptom	Cause	Fix
`show ntp status` shows "unsynchronized"	NTP server unreachable due to routing issues	Add appropriate static route or enable routing so routers can reach 10.10.101.230
`show ntp associations` shows reachability 0 (----)	UDP/123 filtered by ACL or firewall	Permit UDP port 123 between devices and the NTP server
NTP server mis-typed (e.g., 10.10.101.203)	Typo in `ntp server` statement	Correct the IP under `ntp server` in config and save

Challenge Task

Configure redundancy: add two NTP servers (10.10.101.230 and a second server at 10.10.101.231). Configure each router to prefer server .230 but failover to .231 automatically. Ensure proper verification and describe how you would validate failover during maintenance (no step-by-step — plan and implement independently).

Key takeaway: Accurate time is foundational for debugging, security, and compliance. Centralize time via NTP, verify reachability and ACLs, and validate synchronization with show ntp associations and show ntp status.

NTP Time Synchronization