Lab 4: DHCP, DNS, and Default Gateway Symptoms
Key Takeaways
- DHCP problems often appear as missing, APIPA, wrong-subnet, duplicate, or incomplete address settings.
- DNS problems often appear when IP connectivity works but names fail.
- A wrong default gateway usually breaks off-subnet access while local same-subnet access may still work.
- The best next step depends on the symptom pattern, not on a memorized command order.
Scenario: Three Users, Three Different Failures
In this lab, three users report connectivity problems in the same small network. The addressing plan says employee clients should use 172.16.8.0/24, default gateway 172.16.8.1, DHCP-assigned addresses from 172.16.8.100 through 172.16.8.220, and DNS server 172.16.8.10. The printer is 172.16.8.25. Your task is to identify the likely service failure from the observed settings and choose the next step.
User A has address 169.254.44.12, no default gateway, and no DNS server. The Ethernet link is up. This points toward DHCP failure or inability to reach the DHCP service. The next steps are local and practical: verify the cable and switch port, confirm the user is on the expected wired network or SSID, try renewing the lease, compare with another device on the same port if allowed, and check whether other users on the same switch or VLAN are affected.
If multiple clients in the same VLAN fail to get DHCP, escalate with the scope and port information because the issue may involve DHCP server availability, DHCP relay, switch VLAN assignment, or an access point mapping.
User B has address 172.16.8.144/24, gateway 172.16.8.1, and DNS server 192.168.1.1. The user can ping 172.16.8.1 and 8.8.8.8, but cannot open intranet.company.local or external sites by name. This looks like a DNS configuration issue. IP forwarding works because the gateway and external IP are reachable. The wrong DNS server may have come from an incorrect DHCP scope, a manual setting, VPN software, or a rogue DHCP server.
The next step is to test name resolution with a tool such as nslookup or dig where appropriate, compare DNS settings with a healthy client, and document whether changing to the approved DNS server is authorized or requires escalation.
User C has address 172.16.8.160/24, DNS server 172.16.8.10, but default gateway 172.16.80.1. The user can print to 172.16.8.25 but cannot reach the Internet. This is the default gateway pattern. Same-subnet local resources can work because the host sends directly to local MAC addresses after ARP. Off-subnet traffic fails because the gateway is wrong or unreachable from the client's subnet. The likely causes include a bad DHCP option, manual gateway entry, or a wrong network profile. Compare with a known-good client and gather DHCP lease details before changing shared infrastructure.
Notice how the same user complaint, 'network is down,' maps to different causes. DHCP failure may prevent the client from joining the IP network at all. DNS failure may leave IP connectivity intact but make normal application use fail. Gateway failure may preserve local access while breaking remote access. The correct technician next step is the one that narrows the pattern with minimum disruption.
Escalation should be precise. For DHCP, include whether the client has APIPA, wrong subnet, no lease, or duplicate address symptoms. For DNS, include whether direct IP tests work and which DNS server the client is using. For gateway issues, include local versus remote test results. If packet capture is requested by an engineer, capture on the affected client during DHCP renewal or DNS lookup and save the file, but do not interpret beyond your training without documenting assumptions.
Study Checkpoint
- Topic: Lab 4: DHCP, DNS, and Default Gateway Symptoms.
- Verify the official Cisco concept before memorizing a shortcut.
- Practice the technician action: observe, document, test, fix when supported, or escalate.
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?
A client can print to a same-subnet printer but cannot reach the Internet, and its gateway is outside the client subnet. What is the best interpretation?