← Home

Field Guide · Networking

Visual
Reference

The networking family's core mental models in one place, redrawn to a common style. This is a gallery, not a lesson: each diagram carries one idea and a pointer to the guide that develops it. Read it as a map of a single packet's life — how it's wrapped, where it goes, how the destination is found, and how the conversation opens — and use it to find which guide to open when a diagram raises a question.

8 diagrams one packet's life each links to its guide

Every other guide in the family zooms in on one stage. This one pulls back so the stages line up: a packet is wrapped in layered headers, addressed at two scopes at once, routed hop by hop toward a name that DNS resolves, and only then does a TCP and TLS handshake open the conversation the application wanted. The diagrams below follow that order.

01

Layers & Encapsulation

Each layer wraps the one above it with its own header; the wire carries the outermost wrapper, and each device unwraps only as far as it needs to.

A packet is an onion — each layer wraps the next Ethernet (L2) IP hdr (L3) TCP hdr (L4) app data (L7) trailer the wire carries the whole frame; a switch reads L2, a router reads L3, the server's app reads L7
Encapsulation. See Networking — Follow the Packet for the walk through each layer.

The same four layers, read as "what each one adds and the address it decides on":

L7 · ApplicationHTTP, DNS, TLS payloads — what the user actually wantedno address — it's the content L4 · TransportTCP / UDP — reliability & multiplexingkeys on the PORT (which process) L3 · NetworkIP — routing across networkskeys on the IP (end to end) L2 · LinkEthernet / Wi-Fi — one hop across the local mediumkeys on the MAC (local link)
The addresses that matter at each layer — the L3 IP is end-to-end, the L2 MAC is only ever local. That distinction drives the next diagram.
02

Addressing & the Path

A packet is addressed at two scopes at once. The destination IP is chosen once and rides end to end; the destination MAC is rewritten at every router hop, because it only ever names the next link.

L3 destination IP — unchanged, every hop Client Router 1 Router 2 Server dst MAC = R1 dst MAC = R2 dst MAC = Server L2 destination MAC — rewritten at every hop; it names only the next link, never the far end
The end-to-end IP vs the hop-by-hop MAC. See Networking and IP Routing.

How a host decides whether a destination is even on its own link — the mask draws the line between the network part and the host part of an address:

The mask splits every address (example: /24) network prefix — first 24 bits host — last 8 bits the mask draws this line is the destination in my subnet? yes — same linkresolve its MAC (ARP / ND), send direct no — different networksend to the default gateway
Local-vs-remote is the whole job of the mask. See Subnetting & CIDR.
03

Finding the Destination

When a packet is bound off-link, the router picks exactly one next-hop by applying three tie-breakers in a fixed order — each only consulted if the previous one left a tie.

candidate routes — every prefix that matches the destination 1 · Longest Prefix Match — the most specific route wins 2 · Administrative Distance — trust between sources, if tied 3 · Metric — lowest cost within one protocol, if still tied one next-hop — installed in the FIB, forwarded at line rate
Longest prefix, then distance, then metric — in that order. See IP Routing & Route Tables (which carries the verified Cisco AD values).

And the name has to become an address first. A stub resolver asks one recursive resolver, which does the walking — root, then TLD, then the authoritative server — and caches the answer for its TTL:

stub resolver(the client) recursive resolverdoes the walking, caches root — "ask the TLD" TLD — "ask the domain" authoritative — the answer recurse for me the recursive resolver caches each answer for its TTL — there is no "propagation," only caches expiring
Stub asks once; the resolver walks the hierarchy. See DNS.
04

Opening the Conversation

Only once the destination is reachable does the conversation open — first TCP's three-way handshake to establish a reliable channel, then, for anything encrypted, the TLS handshake on top of it.

Client Server SYN SYN-ACK ACK SYN-SENT SYN-RCVD ESTABLISHED ESTABLISHED close is symmetric (FIN / ACK each way); the side that closes first holds TIME-WAIT briefly — normal, not a leak
TCP's three-way handshake and the states it moves through. See Networking and the state list on the Command Card.

TLS 1.3 then negotiates keys and authenticates the server's name in a single round trip before any application data flows:

Client Server ClientHello + key share ServerHello + key share, {cert, Finished} {Finished} encrypted application data ~1 round trip, forward secrecy. Authenticates the server's NAME over an encrypted channel, not its intent
TLS 1.3 in ~1-RTT (RFC 8446). See TLS & Certificates for the chain of trust and the version rules.

Where each diagram lives

Wrap & address

Encapsulation, the layers, and the end-to-end-IP-vs-hop-MAC path → Networking — Follow the Packet. The mask and local-vs-remote → Subnetting & CIDR.

Find

The longest-prefix → distance → metric funnel (and the verified AD values) → IP Routing & Route Tables. Stub / recursive resolution and TTL → DNS.

Talk & troubleshoot

The TCP and TLS handshakes → Networking and TLS & Certificates. For reading trouble rather than mechanism → Misconceptions, Sage-Advice, the Command Card, and the Triage Trees.

This is a consolidation: every diagram is a redrawn view of a model developed in its home guide, kept deliberately conceptual — no administrative-distance numbers, no exact handshake byte order — so the authoritative, version-specific specifics stay where they were verified: the Cisco AD values in IP Routing, TLS 1.3 as RFC 8446 with its roughly-one-round-trip handshake and forward secrecy in TLS & Certificates, and the encrypted-transport and DNSSEC details in DNS. Nothing here is a security assurance — a completed handshake means the channel is open and, for TLS, that the server's name is authenticated over an encrypted channel; it does not mean the endpoint is trustworthy or that you are authorized, which is the distinction the Misconceptions and Zero Trust guides draw. Terms are in the Glossary; 00 · Start Here indexes the set.