Learning bite
Packets, routes, and the OSI seven-layer model
Trace local delivery, routed traffic, and replies while using OSI as a troubleshooting model.
On this page
Follow the message without mixing the addresses
After name resolution, an application uses a destination address and transport port. The OS consults its route table. If the destination is outside the connected network, the next hop is typically a gateway. That gateway's link-layer address is different from the remote site's IP address.
On an Ethernet-like IPv4 link, ARP discovers the next hop's MAC address when needed. IPv6 uses Neighbor Discovery, which also supports router discovery. A populated neighbor cache avoids another discovery exchange. These mechanisms apply to the local link; they do not resolve the remote site's MAC across the internet. ARP↗, IPv6 Neighbor Discovery↗.
A simplified outbound path is:
Browser HTTP data
-> encrypted transport data
-> IP packets
-> local-link frames
-> Wi-Fi/Ethernet signals
-> access network / gateway
-> routed networks
-> destination endpoint
This is encapsulation: one protocol carries another's data. At a routed hop, the incoming link framing ends and the next link gets appropriate new framing. Routers forward using IP routing information and decrement IPv4 TTL or IPv6 Hop Limit; reaching zero prevents indefinite loops. They are not normally decrypting HTTPS page content to decide the next hop. Internet host layering↗, IPv6 forwarding fields↗.
A NAT example, not LearnWithSK's actual route
The following addresses are a labeled teaching example. The public-looking ranges are reserved for documentation and must not be used as live targets.
| Observation point | Outbound source | Destination |
|---|---|---|
| Home laptop | 192.168.50.20:51514 | 203.0.113.20:443 |
| After an IPv4 NAPT gateway | 198.51.100.9:62001 | 203.0.113.20:443 |
| Reply arriving at the gateway | 203.0.113.20:443 | 198.51.100.9:62001 |
| Reply delivered to the laptop | 203.0.113.20:443 | 192.168.50.20:51514 |
The gateway tracks the translation. Ordinary routers do not all rewrite the source IP or source port. Not every connection uses NAT; a globally addressed IPv6 client is a common alternative. NAT and a firewall have different responsibilities, even when one device supplies both. Traditional NAT/NAPT↗, documentation addresses↗.
A reverse proxy terminates one connection and can open another toward an origin. This produces separate connection legs, not merely another router hop. Route symmetry is not guaranteed, and a trace of the outbound direction does not establish the reply route.
Work through the first hop
Imagine the laptop 192.168.50.20/24 needs to reach the documentation-only address 203.0.113.20. The destination is outside its local /24, so an applicable default route selects its local gateway, for example 192.168.50.1. The laptop needs the gateway's local-link address, not the remote site's MAC address.
The outgoing IP packet still names the remote destination, while the local frame is addressed to the next hop. At the router, that link frame ends. The router chooses another route and places the packet in the next link's framing, with the hop count reduced. A NAPT gateway may also translate the source address/port as in the preceding table. These are three distinct changes: new link framing, hop-count decrement, and translation only where configured.
Practice without sending traffic: sketch two boxes for laptop and router, then a third for the remote endpoint. Put the IP destination above all routed legs, and a separate link destination on each local leg. For the return direction, draw the translation-table lookup at the NAPT gateway. The exact return routers remain unknown in this example.
Question: does a router need the site's private TLS key to forward the packet? Normally no. IP forwarding uses network-layer information. A terminating reverse proxy is different: it is an endpoint for one protected connection and may open another.
Use the seven layers as questions
OSI is a reference model. The internet stack does not implement seven separate handshakes, processes, or header sets for every request. The assignments below explain responsibilities; TLS, QUIC, and application-session behavior do not map perfectly to one OSI box. ITU-T X.200↗.
| Layer | Responsibility | Relate it to this journey |
|---|---|---|
| 7 — Application | Protocol meaning exposed to applications | HTTP methods/status, DNS queries; which name/path/operation is requested? |
| 6 — Presentation | Representation and transformations | Character encoding, content encoding, cryptographic protection as a conceptual concern; is the data interpretable? |
| 5 — Session | Coordination of exchanges | Establishing/resuming a conversation conceptually; an application login session is not a dedicated OSI protocol |
| 4 — Transport | Communication between transport endpoints | TCP stream or UDP datagrams, ports; QUIC supplies transport functions above UDP |
| 3 — Network | Addressing and forwarding between networks | IP addresses, route selection, TTL/Hop Limit; is the destination reachable? |
| 2 — Data link | Delivery on a link | Ethernet/Wi-Fi frames and link addresses; can the next hop be reached locally? |
| 1 — Physical | Transmission of signals | Radio/copper/fiber and interface link state; can bits be carried? |
For practical internet diagnosis, group upper-layer responsibilities into the application stack and use application → transport → internet → link as the broad TCP/IP view. DNS is an application protocol, even though a page request often depends on it early. HTTPS can fail at certificate validation after basic connectivity works. TCP/IP layering↗.
Responses and failure boundaries
| Observation | What it supports; what it does not settle |
|---|---|
| A DNS answer exists | A resolver supplied records; routing, TLS, and page health remain unproven |
| Ping replies | Some ICMP exchange works; HTTPS may still fail |
| TCP connection succeeds | A transport endpoint answered; certificate and application behavior remain unproven |
| TLS validates | A secure peer was established; the requested resource may still fail |
| HTTP 404 arrives | An HTTP component answered; it does not mean the network is down |
| HTML loads but a script fails | Inspect that separate resource's URL, status, policy, and client error |
A traceroute estimates responding hops with probes of increasing TTL/Hop Limit. Asterisks can mean filtering or lack of replies, not a proven broken link. Different protocols, load balancing, tunnels, and time can give a different path from the browser. It is evidence, not a full topology map.
Checkpoint
Draw an outbound packet and its reply. Label domain, destination IP, destination port, local next hop, and local-link address separately. Mark which values may change through NAT or a proxy. Name the smallest observation that distinguishes DNS, transport, TLS, and HTTP failures.
For a worked layer classification, compare “Wi-Fi disconnected,” “name not found,” “certificate hostname mismatch,” and “404.” The first points to the local link/physical context. Name lookup is an application-protocol dependency. Certificate checking happens after some connectivity has already worked. A 404 is a valid HTTP response about the requested resource. The useful question is which observation distinguishes the failure, not which single OSI number can be attached to every symptom.
Continue with the browser observation lab. Later Linux networking lessons revisit these concepts with local tools and a server you control.
Your notes and evidence
Record observations, questions, or links to your work. Keep credentials out of your notes.
Back up or restore this path
Progress and notes stay in this browser. A backup contains only this learning path.