A Practical OSI Model for Diagnosis

Chapter 1's four scoping questions narrow a vague complaint down to a rough shape — one user or many, one destination or everywhere. They don't yet tell you which layer of the network is actually broken. That's this chapter's job: a version of the OSI model built specifically for triage, not for an exam — fewer layers, a deliberately practical starting point, and one honest deviation from the textbook order that matters more than it might seem.

Why Not Just Use the Textbook Seven Layers?

The full OSI model — Physical, Data Link, Network, Transport, Session, Presentation, Application — is precise and genuinely useful for understanding how networking software is built, which is exactly why Networking Fundamentals (net1) teaches it in full. But precision isn't what triage needs. In practice, Session and Presentation rarely come up as a distinct troubleshooting step, and Physical is often something you can't even check directly on a remote user's machine. Support diagnosis collapses the seven layers down to five practical categories, each tied to one concrete question and one or two tools you'll cover in depth over the next several chapters.

The One Honest Deviation: Why DNS Comes Before "Network"

Strictly by OSI layer number, DNS is an application-layer protocol (it runs over the network, same as any other service) — so a purist ordering would test raw network reachability before ever touching DNS. This course's practical ladder puts DNS second anyway, right after local connectivity, and it's worth being upfront about why: almost every later test in this ladder needs a correct IP address to test against. If DNS resolves a name to the wrong IP, every network-reachability, port, and application test that follows will faithfully test the wrong destination and produce confusing, misleading results — not because those layers are broken, but because the address itself was wrong from the start. Checking DNS early isn't about OSI purity; it's about not wasting the rest of the ladder on a bad starting address.

Working the Ladder: Where to Actually Start

A textbook bottom-up review starts at the physical layer — but as a support engineer, you usually can't see a user's cable or link light from where you're sitting, so that step is often not available to you at all. The practical starting point is one rung up: confirm local connectivity is basically sane (Chapter 3 covers exactly how, remotely), then work upward one rung at a time, stopping the moment you find the first rung that fails. The first failure you find is very often the actual problem — not always, but often enough that it's the right place to start looking closely before moving further up.

Working Example: Walking the Ladder on Chapter 1's Complaint

Chapter 1 left a ticket open: "I can't reach the app," with a ping that timed out. Suppose this time the ping actually succeeds — walking the ladder from the bottom:

Local connectivity: fine, since the ping left this machine and came back. DNS: fine, since the name resolved to the expected IP. Network reachability: fine, since the ping actually got a reply this time, unlike Chapter 1's example. The first rung that fails is port/service reachability — something on the far end is actively refusing the connection on port 443, rather than the packet simply going nowhere. That's a genuinely different, much narrower problem than the one in Chapter 1, and Chapter 6 covers exactly what "connection refused" does and doesn't tell you about what's happening on the other end.

What This Buys You

The practical ladder doesn't replace the four scoping questions from Chapter 1 — it comes after them. Scoping tells you roughly what kind of problem you're looking at (one user vs. many, new vs. persistent); the ladder tells you specifically which layer is responsible, by testing from the bottom and stopping at the first failure. Together they turn "I can't reach the app" into a precise, evidence-backed statement like "DNS and network reachability are both fine, but port 443 is refusing connections" — which is a genuinely different, far more actionable ticket than the one that came in.

Hands-On Exercises