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.

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.

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

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

Chapter 2 named local connectivity as the practical starting rung of the ladder — the one closest to physical, but the first one you can actually check remotely. This chapter is entirely about that one rung: reading a machine's own IP configuration, recognizing the signature of a machine that never got a proper address at all, and understanding exactly what the default gateway is and why so many "nothing works" complaints trace back to it.

What "Local Connectivity" Actually Confirms

This rung isn't about the cable or the Wi-Fi signal itself — as Chapter 2 noted, that's rarely something you can check remotely. It's about everything the operating system's own network stack can report: whether the interface is up, whether it has a valid IP address and subnet mask, and whether it has a default gateway configured at all. Three commands cover almost every case you'll see:

Reading a Healthy Configuration

Three fields matter most here: a real IP address in the range the local network actually uses, a subnet mask consistent with that network, and — critically — a default gateway that's actually populated. All three present and sensible-looking is a good sign, but "sensible-looking" isn't the same as "confirmed working" — the next section covers the one extra step that turns this from a good sign into an actual confirmation.

The Telltale Sign of a Broken Configuration: Link-Local Addresses

When a machine can't reach a DHCP server to be assigned a real address, most operating systems fall back to self-assigning one from the 169.254.0.0/16 range — commonly called a link-local or APIPA (Automatic Private IP Addressing) address. It's designed to let machines on the same broken segment still talk to each other, but it means the machine has no real address, no gateway, and no way to reach anything outside its own local segment:

Seeing a 169.254.x.x address is one of the most immediately conclusive pieces of evidence you'll find at this rung: it means DHCP failed, full stop — the cause could be a disconnected cable, a misconfigured switch port, a DHCP server outage, or a wireless authentication failure, but the fix is squarely at this layer, and there's no point testing DNS, ping, or anything further up the ladder until it's resolved.

The Default Gateway: The Machine's Only Way Out

The default gateway is the router a machine sends every packet through when the destination isn't on its own local subnet — which, for almost any real complaint ("I can't reach the app," "the internet's down"), is nearly everything. If the gateway itself can't be reached, nothing beyond the local network can be either, regardless of how healthy DNS or the destination server are. That makes the gateway worth testing directly, separately from testing the actual destination:

A gateway that responds to a ping like this is a genuinely useful data point: it separates "something is wrong with my own local segment" from "something is wrong further out." If the gateway responds fine but the actual destination in Chapter 5's tests doesn't, the problem is somewhere beyond this machine's own local network — a routing issue further upstream, the destination itself, or DNS. If the gateway doesn't respond at all, the problem is much more likely to be local: a cable, a switch port, a VLAN misconfiguration, or the gateway device itself being down.

Working Example: Continuing the Ticket

Back to the running ticket from Chapters 1 and 2. Before even reaching for ping against the app itself, the user reads back their own ipconfig /all output over the phone: a real-looking 192.168.1.42 address, subnet mask 255.255.255.0, gateway 192.168.1.1 — no 169.254.x.x address in sight. A quick ping to that gateway from their machine gets replies. Local connectivity confirmed, in well under a minute, with no need to touch the application at all — exactly the kind of fast, evidence-based elimination this course is built around. The ladder moves up to Chapter 4: does the app's name actually resolve to the right address?

Hands-On Exercises

Local connectivity confirmed in Chapter 3 means this machine can reach its gateway and, through it, the rest of the network. The next rung, per Chapter 2's ladder, is DNS: does the name the user is actually typing resolve to the IP address it's supposed to? This chapter covers the two tools that answer that question, the handful of failure patterns that cover almost every real DNS ticket, and one technique — bypassing local DNS entirely — that's often the single fastest way to tell a local infrastructure problem apart from a genuine, global DNS issue.

How Resolution Actually Happens

When a name is looked up, the request doesn't necessarily go out to "the internet" fresh every time. It typically passes through several layers, any of which might already hold — or wrongly hold — an answer: the application's own cache, the operating system's resolver cache, the configured DNS server (often a local corporate resolver), and only then, if nothing already has an answer, a chain of recursive lookups out to the authoritative servers for that domain. Every one of those layers can cache a result for a period of time set by that record's TTL (time to live) — which matters a great deal diagnostically, and gets its own warning later in this chapter.

Two Tools, One Underlying Answer

Reading a Healthy Resolution

Two things worth noting even in a healthy result: which server answered (dns.corp.example.com here — the locally configured resolver, not necessarily the domain's own authoritative server), and that the answer is marked "non-authoritative" — meaning it came from a cache somewhere along the chain, not fresh from the domain's own DNS servers. Neither is a problem on its own; both become relevant the moment the answer looks wrong.

The Four Failure Patterns

The line to look for is always status: — in dig's output it's stated explicitly, which is exactly why it's the more useful tool once you already suspect a DNS problem rather than just doing a routine lookup.

Bypassing Local DNS to Isolate the Problem

One of the most useful single techniques in this chapter: query a known public DNS server directly, instead of whatever's configured by default, and compare the two answers.

Two different answers for the same name is a genuinely strong signal: the local resolver is holding a stale or otherwise incorrect answer, while the public internet's view of that domain is already correct — or, less often, the reverse, if a change was only made locally and hasn't propagated out yet. Either way, this single comparison usually tells you within seconds whether the problem is specific to local DNS infrastructure or a real, global issue with the domain itself.

Working Example: Continuing the Ticket

The ticket from Chapters 1–3 continues: local connectivity confirmed, so the ladder moves to DNS. nslookup app.example.com from the user's machine returns 203.0.113.77 — but a quick dig @8.8.8.8 app.example.com +short from your own machine returns 203.0.113.42, a different address. That mismatch alone is the finding: this user's local DNS resolver is serving a stale answer, most likely a caching issue on the corporate resolver or a TTL that hasn't yet expired since a recent change. The fix belongs to DNS infrastructure, not the application — and the ladder can move to Chapter 5 once a correct answer is confirmed, to check whether the right IP is actually reachable.

Hands-On Exercises

Both tools in this chapter have already made cameo appearances — Chapter 1's timed-out ping, Chapter 3's gateway ping. This chapter goes deeper on what they're actually doing under the hood, because a surprising amount of wasted diagnostic time comes from treating a ping reply as proof of more than it actually proves, or reading a broken-looking traceroute as more conclusive than it really is.

What Ping Actually Tests

ping sends an ICMP echo request and waits for an ICMP echo reply. That's the entire test — it says nothing directly about whether any actual service on that machine is working. A web server can be completely healthy and serving every request correctly while its host doesn't answer ping at all (ICMP disabled by policy, same as Chapter 3's gateway example); equally, a host can answer ping instantly while the one service you actually care about has crashed. Ping tests reachability at the network layer, not health at the application layer — conflating the two is one of the most common false conclusions in network troubleshooting.

Reading Ping Output In Depth

• Packet loss % — the single most important summary line; any sustained loss above 0% on a healthy path is worth investigating further, even if most packets get through
• Round-trip time (min/avg/max) — high or wildly varying latency (a large gap between min and max, called jitter) can point toward congestion somewhere on the path, even when every packet technically arrives
• TTL in the reply — a rough hint at how many hops away the destination is; a TTL value much lower than expected for a "local" destination can be a sign traffic is taking an unexpectedly long path

Traceroute: Watching the Path Hop by Hop

Where ping only reports the final result, traceroute (Linux/macOS) and tracert (Windows) reveal every router along the way. The mechanism is a genuinely clever trick with a packet's TTL field: the first probe is sent with TTL set to 1, so the very first router along the path decrements it to 0 and sends back an ICMP "time exceeded" message — revealing itself — instead of forwarding the packet further. The next probe uses TTL 2, revealing the second router, and so on, one hop further with each round, until a probe finally reaches the actual destination.

Reading Traceroute Output

Each numbered line is one hop, with up to three round-trip times from three separate probes sent to it. Hop 3 shows three asterisks — no response at all from that specific router — yet hop 4 responds normally and the trace reaches the actual destination at hop 5. That's a genuinely common, non-broken pattern: many routers are configured to rate-limit or simply not generate the ICMP "time exceeded" messages traceroute depends on, even while forwarding the actual traffic through them perfectly normally.

What Neither Tool Proves

Two honest limits worth carrying into every later chapter. First, neither tool says anything about the application layer — a perfect ping and a clean traceroute both stop exactly at "the network path works," which is Chapter 6 and 7's job to build on, not this chapter's. Second, the path a traceroute reveals is only the outbound path — return traffic can genuinely take a different route back (asymmetric routing is common on real networks), so a trace that looks broken partway through doesn't necessarily mean the return path is broken in the same place, or at all.

Working Example: Continuing the Ticket

Chapter 4 confirmed the correct IP is 203.0.113.42 once the user's DNS cache issue was accounted for. A ping directly to that IP now returns clean, consistent replies with 0% loss — network reachability confirmed. A traceroute shows one silent hop partway through, but reaches the destination normally, consistent with this chapter's own "silent hop, normal arrival" pattern rather than a real problem. The ladder moves to Chapter 6: with the network path confirmed healthy, is the actual application port open and accepting connections?

Hands-On Exercises

Chapter 5 closed out with the network path confirmed clean — a healthy ping, a traceroute that reaches the destination. That confirms packets can get to the right machine. It says nothing about whether anything on that machine is actually listening on the specific port the application needs. This chapter is entirely about that one narrow question, and about reading the difference between an active "no" and total silence — a distinction that's come up in passing since Chapter 2, and finally gets its full treatment here.

Why the Network Layer Passing Isn't the Whole Answer

A server can respond to ping perfectly while the specific service you care about — a web server on port 443, a database on port 3306 — has crashed, was never started, or is deliberately firewalled off from where you're testing. Confirming the network path is healthy narrows the search meaningfully, but the only way to confirm the actual port is to try connecting to it directly, which is what all three tools in this chapter do, in slightly different ways.

Three Tools for One Job

Reading the Three Outcomes

curl's Connection Phase

For a web service specifically, curl -v shows the raw TCP connect step explicitly, before anything HTTP-related begins:

Even without reading any further, the "Trying..." and "Connected to..." lines alone confirm the exact same thing nc -zv would — this chapter's own narrow question. Everything curl prints after that point — the TLS handshake, the request headers, the response status code — belongs to Chapter 9, once the port itself is confirmed open.

Working Example: Closing Out the Ticket

Back to the ticket that's run since Chapter 1. With DNS corrected (Chapter 4) and the network path confirmed clean (Chapter 5), a final check confirms port 443 as well:

Every rung of the ladder — local connectivity, DNS, network reachability, and now port reachability — checks out clean. Which is, in its own way, the actual finding: this ticket's real root cause was the stale DNS answer identified back in Chapter 4. Once that single rung was corrected, everything above it was already fine, and there was never a firewall or application-layer problem to chase at all. That's exactly the payoff the ladder is built for — it would have been easy to spend far longer investigating firewalls or application logs for a problem that was actually settled two chapters ago.

Hands-On Exercises

Chapter 6 left one question open: a refused connection could mean nothing is listening on that port, or it could mean a firewall explicitly rejected it — and from a plain client-side test, the two can look identical. This chapter is about diagnosing firewall involvement specifically, under the constraint most support engineers actually work under: you very often can't see the firewall's own rules or logs at all, because it belongs to another team, a cloud provider's own console, or an ISP.

Two Ways a Firewall Can Say No

A firewall rule that blocks traffic can do it two genuinely different ways, and which one it uses shapes what you'll actually see from the client side:

Both behaviors are entirely legitimate, deliberate configuration choices — DROP is often preferred specifically because it gives an attacker less information (a silent void looks the same whether a port is closed or actively blocked), while REJECT gives a faster, cleaner failure for legitimate traffic that isn't allowed. Distinguishing which one actually happened, and telling a firewall REJECT apart from a genuinely closed port, needs a packet-capture tool like tcpdump or Wireshark to inspect the actual ICMP response — deliberately out of scope for this course, but worth knowing the limit exists rather than assuming a simple client tool can always tell you.

Symptom Patterns That Point at a Firewall

Testing From Multiple Vantage Points

The single most useful technique available when you can't see the rules yourself is testing the exact same port from more than one location and comparing the results — the same instinct as Chapter 1's own scoping questions ("one user or many, one destination or everywhere"), now applied specifically to isolating a boundary rule. A port that opens cleanly from inside the same network as the server, but times out from outside it, is strong evidence for a boundary firewall or a cloud security group specifically — not the service itself, which is demonstrably working for at least one source.

Cloud environments make this pattern especially common: a AWS Security Group or Azure NSG can silently restrict a port to a specific source range, and a support engineer without console access to that layer may have no visibility into the rule at all — only its effect, which is exactly why comparing results from multiple vantage points is often the fastest available path to a confident answer.

Working Example: A Fresh Ticket

A new ticket, unrelated to the one resolved in Chapter 6: users report an internal reporting app is unreachable when connecting from home, but works fine in the office. DNS and network reachability both check out from every location tested. Testing the port itself from multiple vantage points narrows it quickly:

• From the office LAN: port opens immediately
• Connected via the corporate VPN, from home: port opens immediately
• Connecting directly from home, no VPN: the port times out every time

This pattern points precisely at a boundary rule that permits traffic from the office network and the VPN's own address range, but not from the general internet — consistent with a port-specific, source-scoped firewall rule. Worth being honest about the next step: this could be a genuine misconfiguration, or it could be entirely intentional access control — this app may simply have never been meant to be reachable without the VPN. The right next step is confirming which one it is with whoever owns that access policy, not assuming either answer and proceeding to "fix" something that might not be broken at all.

Hands-On Exercises

Chapter 7 found that traffic behaved differently depending on whether it came from the office, over VPN, or directly from home — and left the actual mechanism unexplained. This chapter covers the three things most likely to be quietly rewriting the path itself: NAT changing which address the far end actually sees, a VPN routing only some traffic (or all of it) somewhere unexpected, and a proxy sitting in the middle without the client necessarily even knowing it's there.

NAT: Why "My IP" and "The IP the Server Sees" Aren't the Same

Chapter 3's ipconfig output showed a private address like 192.168.1.42 — an address that's only meaningful on the local network. The router performing Network Address Translation (NAT) rewrites that private address to its own public one before traffic leaves the local network, and rewrites the reply back on the way in. This matters diagnostically more than it might seem: a server's own logs, or a firewall rule written to allow a specific "user's IP," will reference the public, NAT'd address — not the private one the user's own machine reports. Comparing the two, when they're expected to match and don't, is a genuinely common source of confusion.

A quick "what's my public IP" check like this is worth running before comparing a user's own reported address against anything in server logs or a firewall rule — otherwise you're comparing two genuinely different addresses and drawing conclusions from a mismatch that was never meaningful in the first place.

VPN: Full Tunnel vs. Split Tunnel

Chapter 7's ticket resolves here: a full-tunnel VPN routes every packet through the VPN, internal and general internet traffic alike — while a split-tunnel VPN routes only traffic destined for specific internal ranges through the tunnel, leaving everything else to go directly out the local internet connection as normal. Whether a given connection actually goes through the tunnel or not depends entirely on which mode is configured — "connected to VPN" alone doesn't tell you which one you're dealing with.

Proxies: Explicit and Transparent

An explicit proxy is one the client is deliberately configured to use — a browser or application setting pointing traffic at a specific proxy server. A transparent (or intercepting) proxy redirects traffic without any client-side configuration at all, commonly used on corporate networks for content filtering or security scanning — which means a support engineer troubleshooting a client that has no proxy settings configured can still be dealing with one, invisibly, at the network level.

One specific transparent-proxy behavior is worth knowing before Chapter 9 goes deep on TLS: some corporate security proxies perform TLS inspection — decrypting HTTPS traffic, inspecting it, then re-encrypting it with the proxy's own internal certificate before passing it on. A browser that already trusts that internal certificate authority (often pushed out by IT via group policy) sees nothing unusual. A script, a command-line tool, or any client that doesn't already trust that same internal CA will see the connection as presenting an untrusted certificate — because, from that client's point of view, it is one.

Working Example: A Script That Fails Where a Browser Doesn't

A ticket: an automation script calling an external API fails with a certificate validation error, but a colleague can reach the exact same API fine from their browser, from the same corporate network. Both facts turn out to be true, and neither is really about the API itself:

The browser trusts the corporate network's own internal certificate authority, pushed out to every managed machine — so it sees the TLS-inspecting proxy's re-issued certificate as perfectly valid and never shows a problem. The script's HTTP client, running with its own default trust store, has never heard of that internal CA, and correctly refuses to trust a certificate signed by an authority it doesn't recognize. Neither the API nor the network connection is actually broken; the fix belongs to the script's own environment — installing the corporate CA certificate into its trust store — not to anything on the network path itself. Chapter 9 covers reading a TLS handshake failure like this one in full.

Hands-On Exercises

This is the top rung of Chapter 2's ladder. Chapter 8 gave a first taste of a TLS-specific failure; this chapter reads TLS handshake problems and HTTP status codes properly, as real diagnostic signal rather than just "it errored." It's also worth naming up front what's different about this rung compared to every one before it: for the very first time, getting a response — any response, including an error — is itself good news about everything below it.

Reading a TLS Handshake Failure

Chapter 8 covered one TLS failure — an untrusted certificate issuer, caused by a transparent proxy's own re-issued certificate. That's one of several distinct TLS failure signatures worth telling apart, since each points at a genuinely different fix:

This site's own HTTPS/TLS Fundamentals (https1) course covers the handshake mechanics and certificate chain of trust behind each of these in full — this chapter focuses specifically on recognizing which one you're looking at from a failure message.

HTTP Status Codes as Diagnostic Signal

The 5xx Family, Specifically

These four get conflated constantly, but each says something genuinely different about where the failure happened:

Reading curl -v's Full Timeline

Put together, one verbose curl request shows every phase this course has built toward, in order:

Every line above the status code is confirmation, not failure — the connection, the TLS handshake, and the request itself all completed. The 502 specifically says the reverse proxy fronting this app received a response from its own backend, and that response was invalid — narrowing the problem to the backend service itself, or the connection between the proxy and that backend, rather than anything this course's earlier chapters cover.

Hands-On Exercises

Nine chapters built the pieces — scoping questions, the practical ladder, local connectivity, DNS, path testing, port checks, firewalls, VPN/NAT/proxy path changes, and reading the application layer itself. This capstone applies all of it to three fresh tickets, worked more briskly than earlier chapters' own dedicated walkthroughs, since the underlying discipline should already feel familiar by now.

Ticket 1: "The new hire can't reach anything"

A new employee's first-day laptop can't load any internal site or reach the internet at all — freshly imaged, connected today for the first time.

Total time to resolution: well under the time it would have taken to start troubleshooting DNS or a specific application — exactly why local connectivity is the ladder's own starting rung.

Ticket 2: "The reporting app doesn't work on the new Wi-Fi"

Since this week's new office Wi-Fi rollout, multiple users report the internal reporting app is unreachable over Wi-Fi, while it still works fine from a wired connection. Every other internal app works fine on both.

Ticket 3: "The partner API script times out sometimes, but I can never reproduce it in a browser"

A scheduled automation script calling a partner's API intermittently fails with a 504 error. A colleague testing the same API by hand, in a browser, from the same corporate network, has never once seen it fail.

The fix belongs to infrastructure — routing the batch server's traffic over the same primary path interactive users take, or raising the timeout on that specific backup path — handed off with the exact traceroute evidence above, per Chapter 7's own handoff principle.

Chapter Attribution

Honest Scope Note

Hands-On Exercises