11 hands-on NTP scenarios you build in your own Cisco Modeling Labs instance and grade against the answer key. NTP configuration and troubleshooting practice for CCNA and CCNP.
Included with a subscription
Deploy an authenticated NTP hierarchy with a router acting as the trusted NTP server and two network devices as clients. Validate reachability from user hosts and confirm that clients securely synchronize to the server.
Two-router /30 point-to-point lab. R1 is an authoritative UTC NTP master (stratum 3). Configure R2 as an NTP client to R1 and display local time in MST/MDT while remaining synchronized to UTC. Reinforces that NTP distributes UTC and the router applies timezone/daylight-saving only to presentation.
Create a deterministic three-tier NTP hierarchy on a single shared LAN. R1 is the authoritative clock (ntp master 2), R2 syncs to R1, and R3 syncs to R2. No routing or additional subnets — all devices share 10.0.0.0/24 via one L2 switch. Verify with show ntp status and show ntp associations.
Configure two Cisco IOS routers as symmetric-active NTP peers over a single /30 link. R1 is an authoritative clock (ntp master 4) and both routers form a symmetric peer relationship with ntp peer. Learn how peer mode differs from client/server, and how to verify and troubleshoot associations without relying on Internet sources.
Configure a Cisco IOS router as an authoritative NTP master at a chosen stratum and point a neighbor at it as a client. Understand how NTP stratum works and verify deterministically using show commands rather than waiting for live synchronization.
Build a small LAN with two IOS routers acting as NTP masters at different strata and a client that lists both as time sources, preferring one using the prefer keyword. All routers share a single broadcast domain via a Layer-2 switch, with no routing configured. You will deploy deterministic NTP, verify associations, and understand redundancy selection behavior.
Configure a deterministic NTP broadcast design on a single shared LAN. R1 acts as an authoritative clock (ntp master 3) and broadcasts time on its LAN interface. R2 and R3 act as broadcast clients to scale time distribution without per-client server statements. Verify broadcast associations on the clients and understand the tradeoffs vs. unicast client/server.
Advanced NTP capstone, run as a fault hunt. Two branch routers disagree about the time and neither will sync, despite both being configured for NTP and able to ping each other. You get symptoms and the required end state — no fault list. Faults sit on both devices, and two of them make NTP fail while the configuration reads as though it should work — including a restriction pointing at something that was never created.
Configure a Cisco IOS router as an authoritative NTP master and restrict which clients it will serve using an NTP access-group with a standard ACL. One shared LAN (no routing) connects three routers through a Layer-2 switch. Only R2 is authorized to receive time from R1; R3 is denied. Learners deploy, verify, and troubleshoot the access-group behavior.
Configure NTP MD5 authentication so a client (R2) synchronizes only to a trusted, authenticated master (R1). R1 is already an authoritative clock (ntp master 3). You will enable NTP authentication on both routers, define and trust key 1, and bind the key on R2's ntp server statement. Verification focuses on authenticated associations and status; actual time lock may take minutes and is not graded.
Beginner CCNA NTP lab. Two IOS routers share a single /30 link with no routing. Configure R1 as an authoritative NTP master at stratum 3 and point R2 to R1 as its NTP server. Verify using show ntp associations, show ntp status, and show clock. Emphasis: deterministic config — grading checks the presence of ntp master 3 on R1 and ntp server 10.0.0.1 on R2, not live convergence.
Free with an account
NTP looks like a housekeeping topic right up until you are correlating an outage across three routers and none of the timestamps line up. Synchronized clocks are what make logs comparable between devices, and they matter for certificate validation and for any authentication scheme with a time component. NTP is also an unusually good teacher of patience and diagnosis, because nothing about it fails loudly. A mismatched authentication key produces no error at all, and the client simply never trusts the server. An unreachable time source produces no error either; the router just sits at stratum 16 forever. And a config that is completely correct still looks broken for the first few minutes, because convergence takes several polling cycles. You cannot learn the difference between not synced yet and genuinely misconfigured by reading about it. You learn it by watching the reach counter climb.
These labs build the full hierarchy on real Cisco IOS in Cisco Modeling Labs. You make one router the authoritative source with ntp master, point clients at it with ntp server, and confirm the result with show ntp status and show ntp associations, checking that the client landed one stratum above the source, that the asterisk marks the peer actually selected, and that reach has climbed to 377. You then lock it down with ntp authenticate, ntp authentication-key, and ntp trusted-key, binding the key to the association on the client side. Presentation gets its own treatment: clock timezone and clock summer-time recurring for local time, and service timestamps log datetime msec localtime show-timezone so log messages carry wall-clock time instead of uptime. Troubleshooting labs give you the silent failures, a key mismatch, an unreachable source, and an ACL dropping UDP 123, and your export is graded requirement by requirement against the answer key.
Stratum 16 is the NTP reserved value for unsynchronized: the device has a config but has not locked onto a valid source. The usual causes are an unreachable server, a mismatched authentication key, or a source whose own clock has not stabilized, since a client cannot sync to a master that is not itself synchronized. Before assuming the config is wrong, give it several polling cycles and check show ntp associations. A reach value of 0 means you are sending and hearing nothing back, while a value climbing toward 377 means it is working and just has not settled.
No. NTP distributes time in UTC and never touches your local zone, so a fully synchronized router still shows UTC in show clock until you configure it. Set the offset with clock timezone and handle daylight saving with clock summer-time recurring. These are display settings applied on top of the synchronized clock, so changing them affects show clock and log timestamps but never the synchronization itself.
No physical routers are needed. Each lab is a YAML topology you import into your own Cisco Modeling Labs instance, built on the free-tier reference-platform images, so there are no paid node licenses either. NTP is a good fit for virtual practice because everything you verify, stratum, the reach counter, the selected peer, and authentication failures, behaves the same on the real IOS images CML boots as it does on hardware.
Study the theory behind these labs — the concept explainer and step-by-step guides.
Looking for something else? Browse the full lab archive, narrow it to self-standing labs, or see today's daily lab.