The office network is cabled and routing works — but the three core network services are missing. R1 needs to act as a DHCP server so clients get addresses automatically, a DNS forwarder so hostnames resolve, and an NTP client so all devices share accurate time. You will configure all three, verify them end-to-end, and diagnose a DHCP misconfiguration fault.
Objectives
#
Objective
1
Configure DHCP on R1 — pool, network, excluded addresses, gateway, DNS, lease time
2
Obtain DHCP leases on PC1 and PC2 — verify IPs, mask, gateway and DNS assigned automatically
3
Configure DNS forwarding on R1 — enable the DNS server process and set the upstream resolver
4
Verify DNS resolution — nslookup and ping by hostname from PC1 and PC2
5
Configure NTP on R1 — sync to pool.ntp.org, verify stratum and synchronisation status
6
Troubleshoot: PC2 cannot get a DHCP address — diagnose the wrong-network fault and fix it
Test connectivity — also tests DNS if hostname used
show dns
Show DNS server in use and cached entries
🌐 After DHCP is configured and the first client gets a lease, the Service Tracer appears — step through the DHCP DORA exchange, DNS resolution chain, and NTP stratum hierarchy with full field breakdowns.
🌐 Service Tracer
DHCP DORA · DNS Resolution Chain · NTP Stratum Hierarchy
The DHCP lease process always follows four steps — Discover → Offer → Request → Acknowledge (DORA). All four use UDP — Discover and Request are broadcasts; Offer and Ack are usually unicast.
D
Discover — Client broadcasts "I need an IP!"
PC1 has no IP yet. It sends a broadcast to 255.255.255.255, source IP 0.0.0.0 (unknown). Every DHCP server on the LAN receives this.
Offer — Server responds "Here is an address for you"
R1 picks an available IP from the pool (192.168.1.100), marks it as offered, and sends it to PC1's MAC. The offer includes IP, mask, gateway, DNS and lease time.
PC1 broadcasts its acceptance of the offered IP. Still a broadcast — so other DHCP servers (if any) see the PC has chosen R1's offer and withdraw their own offers.
R1 confirms the binding in its lease table and sends the final Ack. PC1 applies the IP, mask, gateway and DNS. The lease timer starts. After 50% of lease time, PC1 will try to renew directly with R1.
When PC1 runs nslookup google.com, the query travels through up to four servers before an answer is returned. In this lab, R1 acts as the recursive resolver — it does the heavy lifting so clients only talk to R1.
💻
1. Stub Resolver — PC1
PC1 asks its configured DNS server (R1 at 192.168.1.1): "What is the IP of google.com?" It waits for a complete answer — it doesn't do any recursion itself.
Query: google.com A → sends to 192.168.1.1
↓
🔀
2. Recursive Resolver — R1 (forwarded to 8.8.8.8)
R1 forwards the query to 8.8.8.8 (Google DNS). In production, a recursive resolver queries Root → TLD → Authoritative servers. Here 8.8.8.8 does all that and returns the answer.
Forwards to 8.8.8.8 Caches result
↓
🌍
3. Root Name Server (13 clusters, e.g. a.root-servers.net)
Knows where to find TLD servers. Responds: "I don't know google.com, but the .com TLD servers are at these addresses."
→ Refer to .com TLD
↓
📋
4. TLD Name Server — .com (Verisign)
Knows which servers are authoritative for google.com. Responds: "Google's authoritative servers are ns1.google.com, ns2.google.com, etc."
→ Refer to ns1.google.com
↓
✅
5. Authoritative Name Server — ns1.google.com
The definitive source. Returns the actual A record: "google.com → 142.250.x.x". This answer travels back up the chain to PC1.
Answer: 142.250.x.x TTL: 300 sec
Caching: R1 caches the result for the TTL (time-to-live) — typically 300 seconds. The second PC1 queries google.com, R1 answers instantly from cache without hitting the internet.
NTP uses a stratum hierarchy to indicate distance from an atomic reference clock. Lower stratum = more accurate. Stratum 16 means "unsynchronised". R1 will sync to a public stratum 2 server and become stratum 3 itself.
0
Stratum 0 — Reference Clock (not a network device)
Atomic clocks, GPS receivers, radio clocks. The ultimate time source — accurate to nanoseconds. These are NOT on the network; they connect directly to Stratum 1 servers.
Examples: Caesium-133 atomic clock, GPS signal
1
Stratum 1 — Primary Time Servers
Connected directly to a Stratum 0 source. Publicly accessible, but direct use is discouraged — use Stratum 2 pools instead to avoid overloading them.
Examples: time.nist.gov, nist1-ny2.ustiming.org
2
Stratum 2 — pool.ntp.org (R1's upstream)
Public NTP pool — hundreds of volunteer servers worldwide. R1 syncs here. Accuracy: within ~10ms of UTC. This is what ntp server pool.ntp.org reaches.
R1 config: ntp server pool.ntp.org
3
Stratum 3 — R1 (becomes a time server for clients)
After syncing, R1 is stratum 3 and can serve time to LAN clients. Cisco IOS routers automatically become NTP servers for clients on their interfaces once synced. Accuracy: within ~15ms of UTC — perfectly adequate for logging and security.
show ntp status → "Clock is synchronized, stratum 3"
Why NTP matters: Accurate time is critical for log correlation (which event happened first?), certificate validity (TLS checks notBefore/notAfter), Kerberos authentication (tickets expire), and syslog timestamps. A 5-minute clock skew can cause Kerberos to reject valid authentication entirely.