Simple explanation
When connectivity exists but a specific SERVICE isn't working right, this lesson covers the usual suspects: DHCP, DNS, and routing.
Technical explanation
- DHCP issues: DHCP scope exhaustion (no addresses left to assign), rogue DHCP server (handing out incorrect/malicious configuration), APIPA addresses appearing (169.254.x.x, indicating DHCP failed entirely and the device self-assigned), DHCP relay misconfiguration (when clients are on a different subnet than the DHCP server, a relay agent is required to forward requests — if misconfigured, remote-subnet clients can't get an address).
- DNS issues: incorrect DNS server configured, DNS server unreachable, stale/cached DNS records causing outdated resolution, DNS forwarding misconfiguration, split-horizon DNS confusion (internal vs. external resolution returning different, sometimes conflicting, results).
- Routing issues: missing or incorrect static routes, dynamic routing protocol neighbor relationships failing to form, asymmetric routing (traffic taking a different path out than back, which can break stateful firewalls expecting to see both directions), incorrect default gateway configuration.
- NAT issues: incorrect NAT translation rules, port forwarding misconfiguration, NAT exhaustion (running out of available translated ports/addresses under heavy load).
Diagnostic approach: isolate which service layer is actually failing — can the device get an IP at all (DHCP)? Can it resolve names (DNS)? Can it reach an IP directly, bypassing DNS (routing)? Testing each independently narrows the fault quickly rather than treating "the internet doesn't work" as one undifferentiated problem.
Synonyms / related terms
| Term | Means | |---|---| | DHCP relay | Forwards DHCP requests across subnet boundaries to a remote DHCP server | | Asymmetric routing | Traffic taking different paths in each direction | | Split-horizon DNS | Different DNS responses depending on whether the query originates internally or externally |
Concept Check
"A user reports 'the internet is down.' Pinging 8.8.8.8 directly succeeds, but pinging google.com fails." This isolates the problem specifically to DNS — basic Layer 3 connectivity is clearly fine (the IP-based ping succeeded), ruling out a routing or physical problem; the failure only when using a domain name points directly at name resolution.
Interview-style Q&A
Q: Why test connectivity to a raw IP address before testing a domain name, as a troubleshooting habit? A: "It separates two independent failure domains in one step. If the IP ping works but the domain name doesn't, you've immediately ruled out routing/connectivity and isolated the issue to DNS — versus starting with a domain name test, which conflates both possibilities into a single ambiguous failure that requires a second test anyway to pull apart."
Memory trick
"Get an Address, Get a Name, Get There" — DHCP, DNS, routing — the three service layers, in the logical order a device actually needs them to fully communicate.