A host sending to another subnet wraps its data in headers (encapsulation: app ▶ transport ▶ IP ▶ Ethernet), sets the destination MAC to the gateway but the destination IP to the final server, and uses ARP to learn the gateway's MAC. Each switch learns the source MAC and forwards by MAC; each router decapsulates, decrements TTL, and re-encapsulates in a new frame. This lab makes you predict every one of those steps in the visualizer, then compares TCP, UDP, FTP and DHCP — and optionally rebuilds it in Packet Tracer.
If you've read the theory in TCP vs UDP and How Enterprise Networks Move Traffic, this is where it becomes muscle memory. The whole lab runs on one fixed topology — the same one the visualizer uses — so you can predict, then verify, every step.
★ THE TOPOLOGY
One host, two switches, two routers, one server — across three subnets. This is deliberately the smallest network that still forces a packet to be re-encapsulated at every router and resolved by ARP on every segment.
| DEVICE / INTERFACE | IP ADDRESS | DEFAULT GATEWAY |
|---|---|---|
| PC1 | 192.168.1.10 /24 | 192.168.1.1 |
| R1 G0/0 (LAN A) | 192.168.1.1 /24 | — |
| R1 G0/1 (WAN) | 10.0.0.1 /30 | — |
| R2 G0/1 (WAN) | 10.0.0.2 /30 | — |
| R2 G0/0 (LAN B) | 192.168.2.1 /24 | — |
| SERVER | 192.168.2.20 /24 | 192.168.2.1 |
R1 and R2 reach each other's LANs with one static route each (or a routing protocol). The point of the lab is the packet behaviour, not the routing config — but the optional Packet Tracer section below gives you the commands.
★ TASK 1 — TRACE AN ICMP PING (WITH ARP)
Open the visualizer in ICMP · PING mode with the device tables set to BUILD FROM EMPTY. Before each NEXT ▶, predict what happens. Then check.
- PC1 wants to reach 192.168.2.20. Is that local or remote? What does PC1 do with the packet as a result?
- What is PC1 missing before it can build the frame, and how does it get it?
- When the ARP request goes out, what is the destination MAC? What does SW1 do with a broadcast?
- In the finished frame, what is the destination IP? The destination MAC? Why are they different devices?
- Remote — 192.168.2.20 is in 192.168.2.0/24, not PC1's 192.168.1.0/24. So PC1 sends the frame to its default gateway (192.168.1.1), not directly to the server.
- The gateway's MAC address. PC1 sends an ARP request — a broadcast asking "who has 192.168.1.1?"
- Destination MAC
FF:FF:FF:FF:FF:FF(broadcast). SW1 floods it out all other ports, and learns PC1's source MAC on the port it arrived on. - Destination IP = the server (192.168.2.20, the final target). Destination MAC = the gateway (R1's G0/0, the next hop on this link). The IP is end-to-end; the MAC is only hop-to-hop. This is the single most important idea in the whole lab.
★ TASK 2 — ENCAPSULATION / DECAPSULATION AT EACH HOP
Keep stepping. As the echo request crosses R1 and R2, track what changes and what doesn't.
Changes: the Layer-2 frame is stripped and a brand-new one built — new source/destination MAC for the next link — and the TTL drops by 1 (64 → 63 → 62).
Stays the same: the source and destination IP addresses, and the entire transport segment / application payload inside. Routers operate at Layer 3; they never touch Layer 4.
- At R1, what is the first thing it does when the frame arrives, and how does it decide where to send the packet next?
- Why does the TTL decrement, and what happens if it ever reaches 0?
- What does SW1 do that R1 does not — and vice versa?
- R1 sees the destination MAC is its own, so it strips the frame (decapsulation) and reads the IP header. It does a routing-table lookup on the destination IP to find the next hop (10.0.0.2 via G0/1), then re-encapsulates.
- TTL prevents packets looping forever. Every router decrements it by 1; at 0 the packet is dropped and an ICMP Time Exceeded is returned to the source (this is how
tracerouteworks). - SW1 forwards on destination MAC and never reads the IP (Layer 2). R1 reads the IP, rewrites the L2 header, and decrements TTL (Layer 3). The switch never changes the frame; the router rebuilds it.
★ TASK 3 — WATCH THE DEVICES LEARN
The visualizer's WHAT THE DEVICES KNOW panel shows every ARP cache and switch MAC table. With the toggle on BUILD FROM EMPTY, step through the ping and watch them fill in. Then switch to PRE-RESOLVED and re-run a TCP scenario to see the steady state.
- What does a switch put in its MAC table, and which field of the frame does it read to learn it?
- How does a router populate its ARP cache without sending its own ARP request?
- Why is the first ping in a fresh network slower than the next four?
- A switch maps source MAC → port. It reads the source MAC of every frame and records the port it arrived on. (It forwards on the destination MAC, but learns from the source.)
- When a router receives a frame, it already has the sender's source MAC and source IP — it caches that pairing passively. It only sends its own ARP request when it needs a MAC it hasn't seen.
- The first ping triggers ARP (and possibly multiple ARP exchanges along the path), which adds round trips. Once every cache is populated, later pings skip ARP entirely. This is why
pingoften shows the first reply with a higher time.
★ TASK 4 — THE TCP 3-WAY HANDSHAKE
Switch to TCP · HTTP. Step through the handshake before any data appears.
- How many segments cross the network before the first byte of application data?
- Why is the source port 49152 and the destination port 80?
- Each handshake segment is routed hop-by-hop just like the ping — does the TCP segment itself change at any router?
- Three — SYN, SYN-ACK, ACK — a full round trip plus one before the GET. That setup latency is exactly what UDP avoids.
- 80 is the well-known port the web server listens on; 49152 is a random ephemeral port the client picked as its source so replies can be matched back to this exact socket.
- No. Routers rewrite the L2 frame and drop the TTL, but the TCP segment (ports, flags, sequence numbers) is untouched in transit — only the two endpoints read or change Layer 4.
★ TASK 5 — UDP, AND DHCP'S BROADCAST
Now compare connectionless traffic. Step UDP · NTP, then UDP · DHCP.
- How many packets does the NTP exchange take versus the TCP handshake? Why no SYN?
- In the DHCP Discover, what is the source IP and why? What is the destination MAC?
- Why does DHCP stay on the local LAN instead of crossing the routers like the others?
- Two (request + response). UDP is connectionless — there's nothing to set up, so no handshake. Lower overhead, lower latency.
- Source IP
0.0.0.0— the client has no IP yet. Destination MACFF:FF:FF:FF:FF:FF(broadcast) so every device, including the DHCP server, sees it. Client port 68 → server port 67. - DHCP is a link-local broadcast and routers don't forward broadcasts. (In the real world an
ip helper-addressturns the broadcast into a unicast relay so one server can serve many VLANs — beyond this lab.)
★ TASK 6 — FTP ACTIVE vs PASSIVE
Select TCP · FTP and use the FTP MODE toggle. Run it once in each mode and watch the data connection's handshake direction.
The control channel is always client → server :21. The data channel differs:
Passive: the client opens the data connection to a high port the server advertises (PASV). Both connections are outbound from the client — firewall-friendly.
Active: the server opens the data connection back from port 20 to the client (PORT). That unsolicited inbound is what client firewalls block — which is why passive became the default.
- In passive mode, which device sends the SYN that opens the data connection?
- In active mode, which device sends it, and from which port?
- Why is FTP awkward for ACLs and NAT?
- The client — it connects to the server's advertised high data port.
- The server, from port 20, back to the client's
PORT-specified port. - It uses two separate connections on two ports, and in active mode one of them is inbound to the client — so a stateless ACL or NAT has to account for both. See the ACL lab for how you'd permit it.
★ OPTIONAL — REBUILD IT IN PACKET TRACER
The visualizer gives you the model; Packet Tracer's Simulation mode lets you confirm it on emulated Cisco gear. Build the topology from the addressing table above, then:
- Click Simulation (bottom-right). Set the event filter to ICMP and ARP only.
- Use the simple-PDU (envelope) tool to ping the server from PC1. Click Capture / Forward to step the PDU one device at a time.
- Click the moving envelope at each device and open the Inbound/Outbound PDU Details (OSI Model + PDU tabs). Confirm the destination MAC changes at each router while the destination IP stays fixed — exactly what you saw in the browser.
- Clear the ARP caches (
clear arp/ power-cycle PCs) and watch the ARP exchange happen on the first ping, then disappear on the second. - For TCP: add the event filter for TCP, open the server's HTTP service, and browse to
http://192.168.2.20from PC1's Web Browser. Step the SYN / SYN-ACK / ACK.
★ VERIFICATION CHECKLIST
- ☐ Traced an ICMP ping with the device tables building from empty; predicted the ARP step before it happened.
- ☐ Can state the difference between the destination IP and destination MAC in the echo request, and why they point at different devices.
- ☐ Watched the TTL decrement and a new L2 frame built at both routers, with the IP packet unchanged.
- ☐ Stepped the TCP 3-way handshake and counted three segments before any data.
- ☐ Compared UDP (NTP) and the DHCP broadcast; can explain why DHCP stays local.
- ☐ Toggled FTP active vs passive and identified who opens the data connection in each.
- ☐ (Optional) Rebuilt the topology in Packet Tracer and confirmed the same behaviour in Simulation mode.
★ COMMON GOTCHAS
The trap: assuming the frame is addressed to the server's MAC. Reality: for a remote destination, the L2 destination is always the next hop (the gateway). The server's MAC isn't even known to PC1 — and never needs to be.
The trap: thinking the source/destination IP changes per hop. Reality: the IP is end-to-end and unchanged (barring NAT). Only the MAC addresses and TTL change. NAT is the deliberate exception — covered separately.
The trap: picking a transport protocol for ping. Reality: ICMP is Layer 3, alongside IP — no ports, no TCP/UDP. The visualizer's ICMP scenario shows this cleanly.
★ WHY THIS IS A BROWSER LAB
Packet flow is a visualization problem. A static .pkt file can show you the topology and let you step one PDU — but the browser visualizer shows the encapsulation stack, the ARP caches, and the MAC tables building simultaneously, with narration on every step and instant scenario switching between ICMP, TCP, UDP, FTP and DHCP. That side-by-side view is what makes encapsulation finally click. The optional Packet Tracer section then grounds it in real Cisco gear — best of both.
Odom's "fundamentals" and "IP routing" chapters cover everything traced in this lab. Amazon affiliate.