Lab 4: DHCP, DNS, and Default Gateway Symptoms
Key Takeaways
- DHCP failures show as missing, APIPA (169.254.x.x), wrong-subnet, duplicate, or incomplete address settings.
- DNS failures show when IP connectivity works (ping by address succeeds) but names fail to resolve.
- A wrong default gateway breaks off-subnet/Internet access while same-subnet local access can still work via ARP.
- Choose the next test by the symptom pattern, not a memorized command order; isolate with minimum disruption.
Scenario: Three Users, Three Different Failures
The approved plan: employee clients use 172.16.8.0/24, gateway 172.16.8.1, DHCP range 172.16.8.100-172.16.8.220, DNS server 172.16.8.10, printer 172.16.8.25. Three users all say 'the network is down.' Your job is to read each client's settings and pick the next step.
Symptom-to-Cause Map
| Observed | Likely failed service | Diagnostic that confirms it |
|---|---|---|
| 169.254.x.x, no gateway/DNS | DHCP not reached | ipconfig /release+/renew, check VLAN/relay |
| Correct IP+gw, pings 8.8.8.8, names fail | DNS | nslookup name, compare DNS server |
| Correct IP+DNS, gateway off-subnet | Wrong default gateway | Ping gateway, check DHCP option/manual entry |
| Duplicate IP warning | Address conflict / rogue DHCP | Check for second DHCP server |
User A - DHCP Failure
User A: 169.254.44.12, no gateway, no DNS, link up. This is APIPA: no usable DHCP lease. DHCP uses a four-step exchange - Discover, Offer, Request, Acknowledge (DORA) - of broadcast and unicast packets; if any step fails, the client falls back to a self-assigned 169.254 address. Next steps are local: verify cable and switch port, confirm the right wired network/SSID, release and renew the lease (ipconfig /release then /renew), compare to another device on the same port, and check whether others on the same VLAN also fail.
If several clients in one VLAN fail to get DHCP, escalate with scope and ports, because the cause may be DHCP server availability, a missing DHCP relay (ip helper-address) on a routed segment, or a wrong VLAN that has no path to the server. A single isolated client is usually local; a whole VLAN failing points to shared infrastructure.
User B - DNS Failure
User B: 172.16.8.144/24, gateway 172.16.8.1, but DNS 192.168.1.1. Pings to 172.16.8.1 and 8.8.8.8 succeed, yet intranet.company.local and external names fail. IP forwarding works, so the gateway is fine - this is the textbook DNS signature where everything works by address but nothing works by name. The wrong DNS server may come from a bad DHCP scope option, a manual override left on the NIC, VPN software that pushed its own resolver, or a rogue DHCP server.
Test with nslookup intranet.company.local and watch which server answers; if it is 192.168.1.1 instead of the approved 172.16.8.10, the resolver itself is the problem. Compare DNS settings to a healthy client and confirm whether correcting DNS is authorized or requires escalation.
User C - Wrong Default Gateway
User C: 172.16.8.160/24, DNS 172.16.8.10, but gateway 172.16.80.1 (note the extra digit - 8 became 80). The user can print to 172.16.8.25 yet cannot reach the Internet. Same-subnet traffic works because the host recognizes the destination is local, resolves the destination MAC via ARP (Address Resolution Protocol), and sends the frame directly without involving the gateway. Off-subnet traffic fails because the host tries to forward it to 172.16.80.1, which is not even in its own 172.16.8.0/24 subnet, so the host cannot ARP for it and the packet is dropped.
Likely causes: bad DHCP option, manual gateway typo, or a wrong network profile. Compare to a known-good client and capture the DHCP lease before changing shared infrastructure.
The Core Lesson
One complaint, 'network is down,' maps to three different causes. DHCP failure can stop the client joining IP entirely. DNS failure leaves IP intact but breaks normal app use. Gateway failure preserves local access while killing remote access. The right next step is the one that narrows the pattern with the least disruption. If an engineer asks for a Wireshark capture, capture during DHCP renewal or DNS lookup and save the file; do not interpret beyond your training without noting assumptions.
A Quick Decision Workflow
When a 'no network' ticket arrives, run this fast triage in order and let the first failure tell you which service to chase:
- Does the client have an IP in the expected subnet? No -> DHCP path (User A pattern).
- Can it ping its own gateway? No, and the gateway is off-subnet -> wrong gateway (User C pattern).
- Can it ping an external IP such as
8.8.8.8? No -> routing, firewall, NAT, or ISP. - Can it ping an external IP but not resolve names? -> DNS (User B pattern).
This ordering matches the layered model: addressing before reachability, reachability before name resolution. Skipping ahead - say, blaming DNS while the client actually has an APIPA address - sends you down the wrong path entirely, because a client with no lease has no working DNS configuration to begin with.
Finally, weigh disruption before acting. Renewing one client's lease is low-risk and reversible. Editing a DHCP scope option, changing the DNS server pushed to a whole subnet, or correcting a gateway in a shared scope affects every client and belongs to the team that owns that scope. Match the size of your action to the size of the evidence: a single-client symptom rarely justifies a network-wide change, and a network-wide symptom rarely justifies poking at one laptop.
Common Traps
- Calling User C a 'DNS problem' when the gateway is the fault.
- Renewing a lease before confirming the client is on the right VLAN.
- Overlooking a one-digit gateway typo (
172.16.80.1vs172.16.8.1). - Editing a shared DHCP scope to fix a single client's symptom.
A client has 169.254.44.12 with no gateway. Which service or path should be investigated first?
A client can ping the default gateway and an external IP address, but names do not resolve. What is the most likely issue?
User C can print to a same-subnet printer but cannot reach the Internet, and the configured gateway 172.16.80.1 is outside the client's 172.16.8.0/24 subnet. What is the best interpretation?