The "User Can't Reach X" Mindset
Network Troubleshooting
Chapter 1 · The "User Can't Reach X" Mindset
A ticket comes in: "I can't get to the app." One support engineer opens a terminal and starts working up from the bottom — check the network interface, check the cable, check the switch port, check the router — methodically confirming every layer is healthy before moving to the next. The other starts from the complaint itself: what exactly can't this person reach, and what's actually different about their situation right now compared to everyone else's? Both engineers might get to the right answer eventually. Only one of them gets there before the ticket queue backs up. This course is about becoming the second engineer.
Two Ways to Approach a Network
If you've worked through Networking Fundamentals (net1) on this site, you've already spent real time with the OSI model, IP addressing, routing, and how a network gets built and configured from the ground up. That knowledge is genuinely useful here — but it's not the same job as the one this course teaches.
Networking Fundamentals (net1) | Network Troubleshooting (this course) |
|---|---|
| Starts from | A blank network that needs designing and building |
| Starts from | A working network that has just stopped working for someone |
| Direction | Bottom-up — physical layer, then link, then network, then up |
| Direction | Symptom-out — start at the reported complaint, narrow from there |
| Goal | Understand every layer well enough to configure it correctly |
| Goal | Find which single layer is broken, as fast as the evidence allows |
Neither approach is "better" in the abstract — they're built for different jobs. A network engineer designing a new office deliberately works bottom-up, because getting a layer wrong early causes problems in everything built on top of it. A support engineer staring at a single broken connection doesn't have that luxury: the network already works for almost everyone else, and starting a full bottom-up review of every layer for one user's complaint would be enormously wasteful. The faster path is narrowing down which layer is actually the problem this time, and ruling out everything else without checking it in full.
The Shape of a Connectivity Complaint
"I can't reach the app" is not one problem — it's a category that covers several genuinely different problems, each with a different fix. Before touching any diagnostic tool, the first job is narrowing down which shape this particular complaint actually has.
| Question to ask | Why it matters |
|---|---|
| One user, or many? | One user points toward that user's own machine, credentials, or local network; many users pointing toward a shared cause — the server, a shared firewall rule, or DNS |
| One destination, or everywhere? | Can't reach one specific site/app but everything else works fine narrows the search dramatically compared to "the internet doesn't work at all" |
| Total failure, or degraded? | "Nothing loads at all" and "it loads, just very slowly" point at different layers — a total failure often means routing/DNS/firewall; slowness often means something further up the stack |
| Just started, or always broken? | Something that worked yesterday and doesn't today means something changed — a config push, an expired certificate, a new firewall rule — which is a genuinely different search than something that's simply never worked |
These four questions alone often narrow a vague "it's broken" complaint down to one or two plausible causes before a single diagnostic command has been run — which is the entire point of asking them first.
A Concrete Example: One Symptom, Several Different Causes
Take the exact same complaint — "I can't reach the app" — and see how differently it resolves depending on what the scoping questions reveal:
- One user, everywhere else fine, just started: often a local DNS cache issue, a VPN misconfiguration, or a stale cached credential — see Chapter 4
- Many users, one destination, just started: often points at the server itself being down, or a firewall/routing change that just went live — see Chapters 3 and 7
- One user, total failure, always broken for them: often a routing or gateway misconfiguration on that user's own segment — see Chapter 3
- Many users, degraded rather than total, no recent change: often a proxy, VPN, or NAT path introducing latency rather than blocking traffic outright — see Chapter 8
- One destination reachable by IP but not by name: a DNS resolution problem specifically, not a connectivity problem at all — see Chapter 4
Five genuinely different root causes, all hiding behind the same three words. The scoping questions from the previous section are what separate them — and every later chapter in this course builds out one of these branches in real depth.
Here's a first, deliberately small piece of evidence — you'll learn to run and properly interpret this in Chapter 5, but even without the tool knowledge yet, notice how much a single line already narrows things down:
This alone tells you the name resolved to an IP address (so DNS isn't the immediate problem) but no reply came back. It does not yet tell you whether the server is down, a firewall is silently dropping the traffic, or the path is simply congested — three different causes that all produce this exact same output. Chapter 5 covers exactly why ping can't distinguish between them on its own, and what to check next.
What This Course Covers
A practical, layer-by-layer diagnostic toolkit built around real support tickets rather than protocol theory for its own sake: a triage-oriented way of thinking about the OSI model, checking local connectivity and IP configuration, DNS resolution troubleshooting, reading ping and traceroute correctly, port and service-level checks, diagnosing firewalls you can't see the rules for, proxies/VPNs/NAT complicating the picture, and application-layer symptoms that look like a network problem but aren't. The capstone applies all of it to three realistic connectivity tickets, start to finish.
Hands-On Exercises
Explain, in your own words, why this chapter argues that a support engineer's "symptom-out" approach is a genuinely different job from a networking course's "bottom-up" approach, rather than just a faster version of the same thing.
📄 View solutionA ticket says "the app is down." List the four scoping questions from this chapter, and explain what a "yes" or "no" answer to each one would point you toward.
📄 View solutionA colleague sees the ping output in this chapter's example and says "the server must be down." Explain why this chapter says that conclusion is unsafe on its own, and name at least two other causes that would produce the exact same output.
Chapter 1 Quick Reference
- Symptom-out, not bottom-up — start from the reported complaint and narrow down, rather than reviewing every network layer from the physical wire up
- Distinct from Networking Fundamentals (
net1), which builds and configures a network; this course diagnoses one that's already built and already broken - Scope every complaint with four questions: one user or many? one destination or everywhere? total failure or degraded? just started or always broken?
- Don't name a likely cause before scoping the complaint — that's a guess wearing a diagnosis's clothes
- The same three words ("can't reach it") can hide genuinely different root causes — DNS, routing, firewall, server, or a slow path — that each need a different fix
- Next chapter: A Practical OSI Model for Diagnosis