Ko-fiSupport
Guides2026-11-08•11 min read

The Life of a Packet: Step-by-Step Hop Walkthrough Across PCs, Switches & Routers

B

BrainyTools Editor

Tech Contributor at BrainyTools

The Life of a Packet: Step-by-Step Hop Walkthrough Across PCs, Switches & Routers

Nothing tests your true understanding of networking—or prepares you better for the Cisco CCNA (200-301) exam and technical interviews—than tracing the exact Source MAC, Destination MAC, Source IP, Destination IP, ARP table, and MAC address table changes at every single link from Host A to Host B.


In previous guides, we examined the OSI & TCP/IP Models, Layer-2 Ethernet Switching, ARP, and IPv4 Routing individually.

Now, let us bring every single protocol and table together into one complete, end-to-end walkthrough—often called "The Life of a Packet" or "Packet Traveling."

Even better: the topology below is the exact default sample topology pre-built into our Web Packet Tracer & Network Simulator, meaning you can click Step Mode and verify every single frame and table entry in this article step by step!


1. The Reference Topology & Initial Device State

Here is the canonical two-subnet topology loaded when you open Web Packet Tracer:

   [ Subnet 1: 192.168.1.0/24 ]                     [ Subnet 2: 10.0.0.0/24 ]
┌──────────┐          ┌──────────┐     ┌──────────┐     ┌──────────┐          ┌──────────┐
│   PC1    │eth0  Fa0/1│   SW1    │Fa0/2│    R1    │Gi0/1│   SW2    │Fa0/2 eth0│   PC2    │
│.1.10/24  ├──────────┤ (L2 Sw)  ├─────┤Gi0/0:1.1 ├─────┤ (L2 Sw)  ├──────────┤.0.10/24  │
│gw: .1.1  │   Link 1 │          │Link2│Gi0/1:0.1 │Link3│  (Fa0/1) │   Link 4 │gw: .0.1  │
└──────────┘          └──────────┘     └──────────┘     └──────────┘          └──────────┘

To make the MAC addresses easy to read in tables, let us denote each interface's burned-in 48-bit MAC address as:

  • PC1 (eth0): IP 192.168.1.10/24, Gateway 192.168.1.1, MAC = MAC_PC1
  • R1 (Gi0/0): IP 192.168.1.1/24, MAC = MAC_R1_G0
  • R1 (Gi0/1): IP 10.0.0.1/24, MAC = MAC_R1_G1
  • PC2 (eth0): IP 10.0.0.10/24, Gateway 10.0.0.1, MAC = MAC_PC2
    **(Note: Switch ports SW1 Fa0/1–2 and SW2 Fa0/1–2 never place their own port MAC addresses into forwarded unicast data frames!)*

Initial State (Cold Boot — Before Any Traffic)

  • PC1 ARP Table (arp -a): Empty
  • SW1 MAC Table (show mac address-table): Empty
  • R1 ARP Table (show arp): Only its own local interfaces (192.168.1.1 -> MAC_R1_G0, 10.0.0.1 -> MAC_R1_G1)
  • R1 Routing Table (show ip route):
    • C 192.168.1.0/24 is directly connected, GigabitEthernet0/0
    • C 10.0.0.0/24 is directly connected, GigabitEthernet0/1
  • SW2 MAC Table (show mac address-table): Empty
  • PC2 ARP Table (arp -a): Empty

2. Step-by-Step Packet Journey: PC1 Pings 10.0.0.10 (PC2)

Now you click Ping Demo (PC1 → 10.0.0.10) in Step Mode:

Phase 1: Subnet 1 ARP Resolution (PC1 Resolves Default Gateway R1 Gi0/0)

  1. PC1 Subnet Check:
    • PC1 compares 192.168.1.10/24 with destination 10.0.0.10. Different subnet!
    • PC1 selects its Default Gateway (192.168.1.1) as the next-hop IP, sees 192.168.1.1 is not in its ARP cache, holds the ICMP Echo Request in its ARP waiter queue, and sends an ARP Request on Link 1:
      • L2 Frame: Src MAC = MAC_PC1, Dst MAC = FF:FF:FF:FF:FF:FF (Broadcast), EtherType = ARP
      • ARP Payload: "Who has 192.168.1.1? Tell 192.168.1.10 (MAC_PC1)"
  2. SW1 Learns & Floods:
    • SW1 receives the frame on Fa0/1.
    • MAC Table Update on SW1: Learns MAC_PC1 -> Fa0/1.
    • Because Dst MAC is FF:FF:FF:FF:FF:FF, SW1 floods the frame out Fa0/2 (Link 2) to R1 (Gi0/0).
  3. R1 Learns & Sends Unicast ARP Reply:
    • R1 receives the ARP Request on Gi0/0, sees targetIp == 192.168.1.1, and updates R1's ARP Table: 192.168.1.10 -> MAC_PC1.
    • R1 transmits a unicast ARP Reply out Gi0/0 (Link 2):
      • L2 Frame: Src MAC = MAC_R1_G0, Dst MAC = MAC_PC1 (Unicast)
      • ARP Payload: "192.168.1.1 is at MAC_R1_G0"
  4. SW1 Learns & Forwards Unicast:
    • SW1 receives the ARP Reply on Fa0/2.
    • MAC Table Update on SW1: Learns MAC_R1_G0 -> Fa0/2.
    • SW1 looks up Dst MAC = MAC_PC1, finds Fa0/1 in its MAC table, and forwards the frame unicast out Fa0/1 to PC1.
  5. PC1 Updates ARP Cache:
    • ARP Table Update on PC1: Learns 192.168.1.1 -> MAC_R1_G0.

Phase 2: ICMP Echo Request Travels PC1 $\rightarrow$ SW1 $\rightarrow$ R1

  1. PC1 Transmits the Queued ICMP Echo Request:
    • Now that PC1 knows MAC_R1_G0, it encapsulates the ICMP Echo Request and sends it on Link 1 (and SW1 forwards it unicast onto Link 2):
      • L2 Header: Src MAC = MAC_PC1, Dst MAC = MAC_R1_G0
      • L3 Header: Src IP = 192.168.1.10, Dst IP = 10.0.0.10, TTL = 128
      • ICMP Payload: echo-request, seq=1

Phase 3: R1 Routes the Packet & Resolves PC2 via ARP on Subnet 2

  1. R1 De-Encapsulates & Routes:
    • R1 receives the frame on Gi0/0, strips the Layer-2 Ethernet header, and checks Dst IP = 10.0.0.10.
    • R1 decrements TTL from 128 to 127.
    • R1 matches C 10.0.0.0/24 out Gi0/1. Because 10.0.0.10 is on a directly connected subnet, the next-hop IP is 10.0.0.10.
    • R1 checks its ARP cache for 10.0.0.10—not found! R1 queues the packet (ttl=127) and broadcasts an ARP Request out Gi0/1 (Link 3):
      • L2 Frame: Src MAC = MAC_R1_G1, Dst MAC = FF:FF:FF:FF:FF:FF
      • ARP Payload: "Who has 10.0.0.10? Tell 10.0.0.1 (MAC_R1_G1)"
  2. SW2 & PC2 Complete ARP on Subnet 2:
    • SW2 receives the broadcast on Fa0/1, learns MAC_R1_G1 -> Fa0/1, and floods it out Fa0/2 (Link 4) to PC2.
    • PC2 receives the ARP Request, learns 10.0.0.1 -> MAC_R1_G1 in PC2's ARP cache, and sends a unicast ARP Reply (Src MAC = MAC_PC2, Dst MAC = MAC_R1_G1).
    • SW2 receives the ARP Reply on Fa0/2, learns MAC_PC2 -> Fa0/2, and forwards it unicast out Fa0/1 to R1.
    • R1 updates its ARP Table: Learns 10.0.0.10 -> MAC_PC2.

Phase 4: ICMP Echo Request Reaches PC2 & Echo Reply Returns without Any Further ARP!

  1. R1 Re-Encapsulates & Transmits ICMP Echo Request to PC2:
    • R1 encapsulates the ttl=127 IPv4 packet into a brand-new Ethernet frame and sends it out Gi0/1 (Link 3 $\rightarrow$ SW2 $\rightarrow$ Link 4 $\rightarrow$ PC2):
      • L2 Header: Src MAC = MAC_R1_G1, Dst MAC = MAC_PC2 (Both MACs rewritten by R1!)
      • L3 Header: Src IP = 192.168.1.10, Dst IP = 10.0.0.10, TTL = 127 (IPs unchanged; TTL decremented!)
  2. PC2 Sends ICMP Echo Reply Back to PC1 (Zero Additional ARP Needed!):
    • Because PC2 already learned 10.0.0.1 -> MAC_R1_G1 during step 8, and SW2, R1, and SW1 already have all MAC and ARP entries populated, the ICMP Echo Reply travels straight back (PC2 $\rightarrow$ SW2 $\rightarrow$ R1 $\rightarrow$ SW1 $\rightarrow$ PC1) as pure unicast frames!

3. Master Header Comparison Table Across Every Link

Save this table for your CCNA exam review—it shows the exact header fields on Link 1/2 (Subnet 1) versus Link 3/4 (Subnet 2):

Packet & Link Location L2 Source MAC L2 Destination MAC L3 Source IP L3 Destination IP IPv4 TTL
1. Echo Request on Link 1 & Link 2 (PC1 $\rightarrow$ SW1 $\rightarrow$ R1 Gi0/0) MAC_PC1 MAC_R1_G0 192.168.1.10 10.0.0.10 128
2. Echo Request on Link 3 & Link 4 (R1 Gi0/1 $\rightarrow$ SW2 $\rightarrow$ PC2) MAC_R1_G1 MAC_PC2 192.168.1.10 10.0.0.10 127
3. Echo Reply on Link 4 & Link 3 (PC2 $\rightarrow$ SW2 $\rightarrow$ R1 Gi0/1) MAC_PC2 MAC_R1_G1 10.0.0.10 192.168.1.10 128
4. Echo Reply on Link 2 & Link 1 (R1 Gi0/0 $\rightarrow$ SW1 $\rightarrow$ PC1) MAC_R1_G0 MAC_PC1 10.0.0.10 192.168.1.10 127

4. Legitimate Sources & Standards References

  • IETF RFC 826: An Ethernet Address Resolution Protocol (Bidirectional ARP cache population from incoming ARP requests addressed to the local target IP).
  • IETF RFC 1122: Requirements for Internet Hosts — Communication Layers (End-to-end IPv4 encapsulation and hop-by-hop link-layer framing).
  • IETF RFC 1812: Requirements for IP Version 4 Routers (Layer-2 header stripping, TTL decrement, next-hop lookup, and Layer-2 re-encapsulation).
  • Cisco CCNA 200-301 Exam Topics (v1.1): Domain 1.0, 2.0 & 3.0 (End-to-end packet forwarding across Layer-2 switches and Layer-3 routers).

5. CCNA 200-301 Exam Prep: Questions & Detailed Answers

Question 1

In the topology PC1 (192.168.1.10/24) — SW1 — R1 — SW2 — PC2 (10.0.0.10/24), while the ICMP Echo Request is traveling on the cable between SW1 (Fa0/2) and R1 (Gi0/0), what are the Source MAC and Destination MAC addresses of the Ethernet frame?

  • A. Source MAC = SW1 Fa0/2 MAC; Destination MAC = R1 Gi0/0 MAC
  • B. Source MAC = PC1 eth0 MAC; Destination MAC = PC2 eth0 MAC
  • C. Source MAC = PC1 eth0 MAC; Destination MAC = R1 Gi0/0 MAC
  • D. Source MAC = SW1 Fa0/2 MAC; Destination MAC = PC2 eth0 MAC

Correct Answer: C
Explanation: A Layer-2 switch (SW1) never rewrites the Source or Destination MAC address of a transit Ethernet frame! Therefore, on both the PC1 -> SW1 cable and the SW1 -> R1 cable, the Source MAC is PC1's MAC address and the Destination MAC is PC1's default gateway (R1 Gi0/0).


Question 2

When PC2 (10.0.0.10) receives the ICMP Echo Request from PC1 (192.168.1.10) and prepares to send the ICMP Echo Reply back to PC1, why does PC2 NOT need to send an ARP Request for its default gateway (10.0.0.1)?

  • A. Because ICMP Echo Replies are sent as Layer-2 broadcasts.
  • B. Because PC2 already learned 10.0.0.1's MAC address from the Sender IP/MAC fields of the ARP Request that R1 sent moments earlier.
  • C. Because PC2 copies PC1's MAC address directly from the incoming frame.
  • D. Because SW2 responds to ARP on behalf of R1.

Correct Answer: B
Explanation: Per RFC 826, when R1 (10.0.0.1) sent its ARP Request asking for 10.0.0.10, the ARP Request payload included R1's own Sender IP = 10.0.0.1 and Sender MAC = MAC_R1_G1. When PC2 received that ARP Request targeting its own IP, PC2 immediately stored 10.0.0.1 -> MAC_R1_G1 in its ARP table. Thus, when PC2 sends the ICMP Echo Reply back via its default gateway 10.0.0.1, the gateway's MAC is already in PC2's ARP cache!


Question 3

After PC1 (192.168.1.10/24) successfully pings PC2 (10.0.0.10/24) through R1, you run show mac address-table on SW1 (the switch on Subnet 1). Which MAC addresses will appear in SW1's MAC address table?

  • A. PC1, R1 Gi0/0, R1 Gi0/1, and PC2
  • B. PC1 and PC2 only
  • C. PC1 (on Fa0/1) and R1 Gi0/0 (on Fa0/2) only
  • D. R1 Gi0/0 and R1 Gi0/1 only

Correct Answer: C
Explanation: Layer-2 MAC addresses are strictly local to their broadcast domain (subnet) and never cross a Layer-3 router (R1). Therefore, SW1 only ever sees frames sourced from devices in Subnet 1: PC1 (Fa0/1) and R1 Gi0/0 (Fa0/2). SW1 never sees MAC_R1_G1 or MAC_PC2.


Question 4

How many fields inside the Layer-3 IPv4 header change when router R1 forwards a normal unicast ICMP Echo Request from Gi0/0 (192.168.1.1) to Gi0/1 (10.0.0.1) (with no NAT or QoS DSCP remarking configured)?

  • A. Zero—the Layer-3 IPv4 header is completely untouched by routers.
  • B. Two—the TTL (Time to Live) field is decremented by 1, and the IPv4 Header Checksum is recalculated.
  • C. Four—the Source IP, Destination IP, TTL, and Checksum all change.
  • D. One—only the Source IP changes to 10.0.0.1.

Correct Answer: B
Explanation: Without NAT, the Source IP and Destination IP remain unchanged end-to-end. However, every router hop decrements the 8-bit TTL field by 1, and because the TTL field is part of the 20-byte IPv4 header, the router must also recompute the 16-bit IPv4 Header Checksum.


Question 5

After the first ping probe (seq=1) from PC1 to PC2 completes and populates all ARP and MAC tables, how many ARP Requests and how many flooded frames occur when PC1 sends the second ping probe (seq=2) a second later?

  • A. 2 ARP Requests, 2 flooded frames
  • B. 1 ARP Request, 1 flooded frame
  • C. 0 ARP Requests, 0 flooded frames (100% unicast forwarding across every link)
  • D. 0 ARP Requests, 2 flooded frames

Correct Answer: C
Explanation: Once PC1, R1, and PC2 have cached each next-hop's MAC address in their ARP tables, and SW1 and SW2 have learned the MAC addresses on Fa0/1 and Fa0/2, probes seq=2, seq=3, and seq=4 require zero ARP Requests and zero switch flooding—every frame is switched and routed as a known unicast!

Related Videos

Enjoyed this article?

Check out our suite of free online developer tools to boost your productivity even further. 100% Privacy Focused.

Explore Tools