Journeys
Everything that happens between plugging in a laptop and seeing a page. Four or five protocols run before a single byte of the page is requested, and each exists because the one before it could not do this job. DHCP hands over an address, ARP turns the gateway's address into a MAC, DNS turns a name into an address — and only then can TCP open anything. In these captures those handoffs are real: the address DHCP leases is the source address on the HTTP request.
The last two go further out. On one LAN the route to everywhere else is a single default gateway, which quietly leaves the impression that routes simply exist. The routed journeys start before that: OSPF and BGP running at the same time on one router, filling one routing table, and an application opening a connection across the result.
The whole chain, working
You plug in a laptop and type a name. Four protocols run before a single byte of the page is requested, and each one exists because the one before it could not do this job. Watch what each stage hands to the next.
The same four stages, plus one: before any request is sent, the server has to prove it is the server. Note what a capture can still read after encryption starts — and what it cannot.
The office journeys stop at the gateway. This one starts before it: two routing protocols fill one routing table, then ARP and DNS do their usual jobs, then an application opens a connection across the result. Nothing in the application's packets refers to a routing protocol — and that is what the routing protocols are for.
Two captures of one network. In the first, the routers talk only to each other and no user traffic exists at all. In the second, user traffic crosses the network — while the routing protocols carry on saying hello in the background, because they never stop. Not one of their packets carries a byte of anybody's data. OSPF and BGP create forwarding information; the routing table selects a path; IP forwards packets; TCP, TLS and HTTP carry the application. Each of those depends on the one before it having already finished.
Diagnosis labs — ten ways it breaks
Each capture below contains exactly one fault, always at the same place — these are fixed cases, not random ones, so you can compare notes on them. The symptom rarely names the layer. Play the capture, commit to a diagnosis, and only then read the answer.
The last three are routed faults and assume the routed journeys above. Two of them look identical from the laptop and have completely different causes; in the third nothing is broken anywhere and the traffic still goes nowhere.
The laptop reports no network connection. One stage in this capture never completes, and every later stage is missing entirely — which is itself the clue.
Diagnosis: local machines work, the internet does notPrinting works. The intranet works. Anything outside this LAN times out. The laptop has an address, so the problem is further along.
Diagnosis: the settings look correctAddress, mask, gateway and resolver all match the documentation. Traffic off the LAN still fails. The configuration is not the problem.
Diagnosis: one site fails, everything else is fineOther sites load normally. This one fails instantly — not slowly, instantly. That timing is a clue in itself.
Diagnosis: the site is reachable but refusesThe name resolves and the server is clearly alive — it answers immediately. It just will not accept the connection.
Diagnosis: the browser warns before showing anythingThe connection opens fine, bytes flow both ways, and then the client hangs up on purpose. Something in what the server sent was unacceptable.
Diagnosis: the page loads, and it is an error pageEvery layer beneath does its job perfectly. This is the case where the network is genuinely not at fault — and being able to prove that is the skill.
Diagnosis: the intranet is gone, the internet is fineExternal sites load. The internal application server does not respond at all. That split — outside works, inside does not — narrows this before you open a single packet.
Diagnosis: the link is up and the routes never arriveThe circuit to the provider is up and the interface counters climb. Nothing outside the company is reachable, and the internal network is completely unaffected.
Diagnosis: nothing is broken and it still does not workEvery device is up. Every protocol session is established. Every configuration matches the documentation. The application is unreachable anyway — this is the case that teaches what a routing table actually is.