Lesson
A Packet’s First Journey Through a Small Network
Learning objective
Narrate an end-to-end exchange using the concepts from Lessons 1–8.
This lesson joins the first eight foundations into one complete conversation. You will follow a PC sending an ICMP echo request to a server on another IPv4 network and follow the reply home.
The addresses use documentation ranges, so they explain the decisions without pretending to be your production network. DNS, DHCP and NAT are assumptions or previews here; their full behavior belongs to later lessons.
Before the first frame
The PC already has 192.0.2.10/24, default gateway 192.0.2.1, and destination IP 198.51.100.20. Imagine the address came from configuration or DHCP and the name was already resolved by DNS. Neither service appears in this exchange.
The PC applies its /24 prefix to its own address and the destination. The results differ, so the destination is remote. The PC keeps the server as the IP destination but chooses the default gateway as its first local next hop.
Resolve the next hop
Ethernet cannot send a frame using only the gateway's IP address. When the PC has no cached mapping, it broadcasts an ARP request: “Who has 192.0.2.1?” The destination MAC is FF:FF:FF:FF:FF:FF.
The switch floods that broadcast only inside the local broadcast domain. The router does not forward the ARP request to the server network. Because its LAN interface owns 192.0.2.1, the router replies with that interface's MAC address. The PC records the mapping.
Switch and route the request
The PC builds an Ethernet frame addressed to the router's LAN MAC. Inside it, the IP packet remains addressed from the PC to the remote server, and inside that packet is the ICMP echo request.
The switch reads the destination MAC and forwards the frame toward the router. The router removes the incoming Ethernet frame, reads the destination IP, selects its server-facing interface, decreases TTL, and builds a replacement frame for the next link. The end-to-end IP addresses remain unchanged in this lesson because NAT is not part of the topology.
Return traffic
The server accepts the request and creates an echo reply with the IP endpoints reversed. Its first frame is addressed to its own gateway. At the router, that frame ends; the router selects the PC-side network and creates another frame. The switch forwards it to the PC, completing the round trip.
Complete packet journey
The player starts automatically unless your device requests reduced motion. Pause, move one step at a time, or change speed. Every link names both interfaces. At each step, open the packet and switch between the plain-language and technical inspection views.
Match evidence to the journey
I know this—proceed to advancedMatch each observation to the decision it proves:
| Evidence | Journey step | What it proves |
|---|---|---|
ip route get 198.51.100.20 | Before the frame | The host selected a route, next hop and outgoing interface. |
arp.opcode == 1 | Resolve the next hop | An ARP request asked for a local IPv4-to-MAC mapping. |
eth.dst == 00:11:22:33:44:01 | First request frame | The local frame targets the gateway rather than the remote server's MAC. |
icmp.type == 0 | Return traffic | The capture contains an ICMP echo reply. |
Basic Wireshark check
Display filter: arp or icmp
Fields to inspect
eth.srceth.dstarp.opcodeip.srcip.dstip.ttlicmp.type
Normal evidence: An ARP request and reply precede the ICMP request when the gateway mapping is absent. IP endpoints remain end to end while Ethernet addresses differ across routed links.
Try it: Compare the Ethernet addresses before and after the router, then compare the IP endpoints. Record where the capture was taken because one observation point cannot expose every link.
Troubleshoot the first failed hop
Work from the source outward and record evidence instead of restarting every device:
- Confirm the host has an address, prefix, gateway and usable interface.
- Confirm the host selects the expected route.
- Check whether ARP resolves the gateway.
- Verify the request leaves the host and reaches the switch/router boundary.
- Verify the router has a route and creates the next-link frame.
- Look for the request at the server and then follow the reply in reverse.
Interview scenario
The PC repeatedly broadcasts ARP for its gateway but receives no reply. What has failed, and what has not yet been tested?
Show answer and reasoning
The failure is still on the local next-hop resolution path. Check the PC interface and VLAN, switch forwarding, the gateway interface state and address, and whether the devices share the intended broadcast domain. Remote routing, the server, and the return path have not yet been tested because the first unicast frame was never created.
Knowledge check and summary
Remember: the host chooses a next hop, ARP supplies a local MAC, switches forward frames, routers replace link framing, and the response repeats the decisions in reverse.