Exercise 3: Why Test the Gateway Separately from the Destination — Possible Solution
====================================================================

WHAT TESTING THE GATEWAY SEPARATELY ACTUALLY SEPARATES
------------------------------
Per this chapter, "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.'" Testing the
gateway in isolation, before testing the actual destination, produces a
result that specifically narrows down where in the path the problem is.

WHAT EACH RESULT TELLS YOU
------------------------------
Per this chapter: if the gateway responds fine but the actual
destination doesn't (tested later, in Chapter 5), 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.

WHY TESTING ONLY THE DESTINATION WOULDN'T GIVE YOU THIS
------------------------------
If you skip straight to testing the destination and it fails, you only
know "something between here and there is broken" - you don't yet know
whether that "something" is the very first hop (the local gateway) or
somewhere much further along the path. Testing the gateway first splits
that single unknown into two separately-confirmed segments (local vs.
everything beyond it), which is strictly more information than testing
the destination alone provides.

WHY THIS WORKS AS AN ANSWER
------------------------------
It explains the specific diagnostic value of isolating the local
segment from everything beyond it, using both of the chapter's own
named outcomes (gateway responds/destination doesn't vs. gateway
doesn't respond at all) rather than just restating that the gateway
"should be checked too" without explaining what that check actually
proves.