The Life of a Packet (Network Layer Forwarding)

Opening Framing: What Actually Happens When You Press Enter

Previous weeks taught you how to assign addresses, calculate subnets, and plan address blocks. This week shifts the focus from planning to motion. When a host sends a packet to another host, what actually happens inside the network? Which fields in the packet header control its journey? How does a router decide where to send it next? And how does a host translate an IP address into the MAC address it needs to build an Ethernet frame?

These are not abstract concerns. Every time a user opens a web page, sends a DNS query, or pings a server, the network executes the same sequence: the sending host checks whether the destination is local or remote, builds a Layer 3 packet with specific header fields, resolves the next-hop MAC address using ARP, wraps the packet in a Layer 2 frame, and sends it onto the wire. At each router along the path, the process partly repeats: the router strips the old frame, reads the IP header, consults its forwarding table, decrements the TTL, and re-encapsulates the packet in a new frame toward the next hop.

Understanding this end-to-end process is the difference between a student who can configure addresses and one who can troubleshoot why traffic does not arrive. This week builds the mental model that every routing, switching, and security course in the degree depends on.

Learning Outcomes

• LO1: Identify the key fields in the IPv4 header and explain how TTL, Protocol, Flags, and Fragment Offset influence forwarding and reassembly.
• LO2: Describe the complete ARP resolution process and explain why it is required before any IPv4 frame can be transmitted on an Ethernet LAN.
• LO3: Trace a packet from source to destination through at least one router, explaining what changes and what stays the same at each hop.
• LO4: Distinguish same-subnet (direct delivery via ARP) from routed delivery (ARP for the gateway, forwarding by the router).
• LO5: Use Wireshark and CLI tools to inspect ARP caches, IPv4 headers, and TTL behavior in a live or simulated network.

Key insight: a packet's IP addresses stay constant across the entire path, but the Ethernet MAC addresses change at every Layer 3 hop.

1) The IPv4 Header: A Field-by-Field Tour

Every IPv4 packet begins with a header that is at least 20 bytes long. This header is not cosmetic metadata; it is the instruction set that every router reads to decide what to do with the packet. If any critical field is corrupted, the packet is dropped. If a field value hits a boundary condition (such as TTL reaching zero), the packet is discarded and an error message is generated. A networking professional must be able to read these fields in a packet capture and reason about what they mean for forwarding.

IPv4 header layout (simplified 20-byte minimum header)

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version|  IHL  |  DSCP   |ECN|          Total Length           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Identification        |Flags|     Fragment Offset      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Time to Live |    Protocol   |        Header Checksum         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Source Address                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Destination Address                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2) TTL, Protocol, and Flags: The Three Fields That Shape Packet Behavior

Three header fields deserve special attention because they directly influence whether a packet reaches its destination, what the receiver does with it, and whether it can be split along the way.

Time To Live (TTL)

TTL is an 8-bit counter set by the sending host, typically to 64 (Linux), 128 (Windows), or 255 (network devices). Every router that forwards the packet decrements TTL by one. When TTL reaches zero, the router discards the packet and sends an ICMP Time Exceeded (Type 11) message back to the source. This prevents packets from circulating forever in a routing loop.

TTL is also the mechanism that makes traceroute work. By sending packets with progressively increasing TTL values (1, 2, 3, ...), each router along the path generates an ICMP Time Exceeded reply, revealing its IP address to the sender. You will explore this in detail in Week 9.

TTL behavior across three hops

Source host sets TTL = 64
Router 1 receives it, decrements TTL to 63, forwards
Router 2 receives it, decrements TTL to 62, forwards
Destination receives it with TTL = 62

If a routing loop exists:
Each loop iteration decrements TTL by the number of routers in the loop
Eventually TTL reaches 0 and the packet is dropped
Without TTL, the packet would circulate indefinitely

Protocol Field

The Protocol field tells the receiving host which upper-layer handler should process the payload. This is how the IP layer hands off data to the correct transport or control protocol. The three most common values are:

In Wireshark, the Protocol field appears as both the number and the name. When troubleshooting, you can filter by ip.proto == 6 to isolate TCP traffic or ip.proto == 1 to see only ICMP.

Flags and Fragmentation

The three-bit Flags field controls whether a packet can be split (fragmented) into smaller pieces when it crosses a link with a smaller Maximum Transmission Unit (MTU). The bits are:

• Bit 0 (Reserved): Always 0.
• Bit 1 (DF — Don't Fragment): When set to 1, routers must not fragment this packet. If the packet exceeds the outgoing link's MTU, the router drops it and sends an ICMP "Fragmentation Needed" message (Type 3, Code 4).
• Bit 2 (MF — More Fragments): When set to 1, more fragments follow this one. The last fragment (or an unfragmented packet) has MF = 0.

Most modern networks set the DF bit and rely on Path MTU Discovery to avoid fragmentation entirely. Fragmentation is expensive: it increases processing, wastes bandwidth on duplicated headers, and complicates firewalls and NAT devices. If any single fragment is lost, the entire original datagram must be retransmitted by the upper-layer protocol.

3) ARP: Translating IP Addresses into MAC Addresses

Every Ethernet frame requires a destination MAC address. But applications and routing tables work with IP addresses. ARP (Address Resolution Protocol) bridges that gap. When a host knows the IP address it needs to reach on the local subnet but does not know the corresponding MAC address, it uses ARP to ask the network: "Who has this IP? Tell me your MAC address."

ARP operates only within a single broadcast domain. It is a Layer 2 broadcast mechanism that cannot cross a router. This is fundamental: ARP resolves the next hop's MAC address, not the final destination's MAC address (unless the destination is on the same subnet).

The ARP Process Step by Step

1. Host checks its ARP cache. Before sending any ARP request, the host looks in its local ARP table for an existing mapping of the target IP to a MAC address. If a valid entry exists, the host uses it immediately and no broadcast is needed.
2. ARP Request (broadcast). If no entry exists, the host constructs an ARP Request containing its own IP and MAC (sender fields) and the target IP it wants to resolve. This request is sent as an Ethernet broadcast (destination MAC ff:ff:ff:ff:ff:ff). Every device on the local LAN segment receives this frame.
3. Target responds (unicast). The device that owns the requested IP address responds with an ARP Reply sent as a unicast directly back to the requester. The reply contains the target's MAC address. All other devices on the LAN silently discard the request.
4. Requester updates its ARP cache. The original host stores the IP-to-MAC mapping in its ARP cache with a timeout (typically 15-45 seconds for incomplete entries, and several minutes for resolved entries depending on the operating system). Future packets to the same IP reuse this cached entry without additional broadcasts.

ARP exchange example

Host A (10.1.1.10, MAC aa:aa:aa:aa:aa:aa) wants to reach Host B (10.1.1.20)

Step 1: Host A checks ARP cache — no entry for 10.1.1.20

Step 2: Host A sends ARP Request
  Ethernet header:
    Source MAC:      aa:aa:aa:aa:aa:aa
    Destination MAC: ff:ff:ff:ff:ff:ff  (broadcast)
  ARP payload:
    Sender IP:  10.1.1.10
    Sender MAC: aa:aa:aa:aa:aa:aa
    Target IP:  10.1.1.20
    Target MAC: 00:00:00:00:00:00  (unknown — to be resolved)

Step 3: Host B (MAC bb:bb:bb:bb:bb:bb) recognizes its own IP and replies
  Ethernet header:
    Source MAC:      bb:bb:bb:bb:bb:bb
    Destination MAC: aa:aa:aa:aa:aa:aa  (unicast back to A)
  ARP payload:
    Sender IP:  10.1.1.20
    Sender MAC: bb:bb:bb:bb:bb:bb
    Target IP:  10.1.1.10
    Target MAC: aa:aa:aa:aa:aa:aa

Step 4: Host A caches: 10.1.1.20 → bb:bb:bb:bb:bb:bb
        Host B also caches: 10.1.1.10 → aa:aa:aa:aa:aa:aa (learned from the request)

4) Same-Subnet vs. Routed Delivery: Two Different Packet Paths

Before a host can send any IPv4 packet, it must answer one question: is the destination on the same subnet as me, or is it somewhere else? The answer determines whose MAC address the host resolves with ARP. This decision happens on every single packet, and it is the single most important concept in Layer 3 forwarding.

Same-Subnet (Direct) Delivery

When the destination IP falls within the sending host's own subnet (as determined by ANDing the destination IP with the local subnet mask), the host knows the destination is directly reachable on the LAN. The host uses ARP to resolve the destination's MAC address and builds an Ethernet frame addressed directly to that device. The default gateway is not involved.

Same-subnet delivery

Host A: 10.1.1.10/24      Host B: 10.1.1.20/24

Host A wants to reach 10.1.1.20:
1. AND destination (10.1.1.20) with own mask (/24):
   10.1.1.20 AND 255.255.255.0 = 10.1.1.0
2. AND own IP (10.1.1.10) with own mask:
   10.1.1.10 AND 255.255.255.0 = 10.1.1.0
3. Results match → same subnet → direct delivery
4. ARP for 10.1.1.20 → get Host B's MAC
5. Build frame: src MAC = A, dst MAC = B, payload = IP packet
6. Gateway is not used

Routed (Indirect) Delivery

When the destination IP does not fall within the local subnet, the host knows it cannot reach the destination directly. Instead, the host ARPs for the default gateway's MAC address and builds the Ethernet frame with the gateway's MAC as the destination. The IP header still carries the original source and destination IP addresses — only the Ethernet addressing changes.

Routed delivery

Host A: 10.1.1.10/24   Gateway: 10.1.1.1   Remote server: 10.2.2.50

Host A wants to reach 10.2.2.50:
1. AND destination (10.2.2.50) with own mask (/24):
   10.2.2.50 AND 255.255.255.0 = 10.2.2.0
2. AND own IP (10.1.1.10) with own mask:
   10.1.1.10 AND 255.255.255.0 = 10.1.1.0
3. Results differ → different subnet → use default gateway
4. ARP for 10.1.1.1 (gateway) → get router's MAC
5. Build frame: src MAC = A, dst MAC = Router, payload = IP packet
   IP header still says: src = 10.1.1.10, dst = 10.2.2.50
6. Router receives the frame, reads the IP header, and forwards

5) How a Router Makes a Forwarding Decision

A router sits between two or more subnets. When a frame arrives on one of its interfaces, the router performs a sequence of steps to decide where to send the packet next. Understanding this sequence is what separates address planning (which you learned in Weeks 4-6) from actual traffic forwarding.

Router Forwarding Steps

1. Receive the frame. The router's interface accepts the Ethernet frame because the frame's destination MAC matches the router interface's MAC (or is a broadcast). The router strips the Layer 2 header.
2. Read the IP header. The router examines the destination IP address in the IPv4 header.
3. Consult the routing table. The router performs a longest-prefix match on the destination IP against all entries in its routing table (also called the RIB — Routing Information Base). The entry with the most specific matching prefix wins.
4. Check TTL. If TTL is 1 or 0, the router drops the packet and sends an ICMP Time Exceeded message back to the source. If TTL is greater than 1, the router decrements it by 1.
5. Recalculate the header checksum. Because the TTL changed, the header checksum must be recomputed before forwarding.
6. Determine the next hop and exit interface. The matching route entry specifies either a next-hop IP address and/or an exit interface. If the destination is directly connected to the router, the next hop is the destination itself.
7. ARP for the next-hop MAC. The router checks its own ARP cache for the next-hop IP's MAC address. If no entry exists, the router ARPs for it on the exit interface.
8. Encapsulate and forward. The router builds a new Ethernet frame with its own exit-interface MAC as the source and the next-hop MAC as the destination, places the (updated) IP packet inside, and sends it out.

Full packet journey: Host A → Router → Host B

Network: 10.1.1.0/24 ──[R1]── 10.2.2.0/24

Host A: 10.1.1.10  (MAC aa:aa)
R1 g0/0: 10.1.1.1  (MAC r1:g0)
R1 g0/1: 10.2.2.1  (MAC r1:g1)
Host B: 10.2.2.50  (MAC bb:bb)

── Hop 1: Host A → R1 ──
Ethernet: src=aa:aa, dst=r1:g0
IP:       src=10.1.1.10, dst=10.2.2.50, TTL=64

── Router R1 processing ──
1. Strips Ethernet header
2. Reads destination IP: 10.2.2.50
3. Routing table lookup: 10.2.2.0/24 via g0/1 (directly connected)
4. TTL 64 → 63
5. Recalculates header checksum
6. ARPs for 10.2.2.50 on g0/1 if needed → gets bb:bb

── Hop 2: R1 → Host B ──
Ethernet: src=r1:g1, dst=bb:bb
IP:       src=10.1.1.10, dst=10.2.2.50, TTL=63

Note: IP addresses unchanged. MAC addresses completely different at each hop.

6) Configuration and Verification: Inspecting ARP and IPv4 Headers

The concepts above become concrete when you inspect real ARP tables and packet headers. The following commands let you observe the forwarding process as it happens on your own machine and on network devices.

Viewing the ARP Cache

Windows:
arp -a
  Displays all ARP cache entries (IP → MAC mappings)

Linux / macOS:
ip neigh          (modern)
arp -a            (legacy)

Cisco IOS:
show ip arp
show arp

Example ARP cache output (Windows)

C:\> arp -a

Interface: 10.1.1.10 --- 0x5
  Internet Address      Physical Address      Type
  10.1.1.1              00-50-56-c0-00-01     dynamic
  10.1.1.20             00-0c-29-3e-7a-12     dynamic
  10.1.1.255            ff-ff-ff-ff-ff-ff     static

Interpretation:
- 10.1.1.1 is the gateway — its MAC was learned via ARP
- 10.1.1.20 is a local host — also learned via ARP
- 10.1.1.255 is the broadcast — always mapped to ff:ff:ff:ff:ff:ff

Clearing the ARP Cache (for testing)

Windows (admin):
arp -d *
  Clears all dynamic ARP entries so you can observe ARP being rebuilt

Linux (root):
ip neigh flush all

Cisco IOS:
clear ip arp

Inspecting IPv4 Headers in Wireshark

When you capture traffic in Wireshark, expand the "Internet Protocol Version 4" section to see every header field. Key things to examine:

• TTL value: Compare the TTL of a ping request leaving your machine versus the reply arriving back. The difference tells you how many router hops are in the path.
• Protocol field: Confirms whether the payload is ICMP (1), TCP (6), or UDP (17).
• Flags: Check whether DF is set. Most TCP traffic sets DF for Path MTU Discovery.
• Source and destination IP: Confirm they remain constant even when the Ethernet MACs change at each hop.

Wireshark display filter examples

ip.addr == 10.1.1.10        Show all traffic to/from this host
ip.ttl < 5                  Find packets with suspiciously low TTL
arp                          Show all ARP traffic
ip.proto == 1                Show only ICMP (ping, traceroute)
ip.flags.df == 1             Show packets with Don't Fragment set
eth.dst == ff:ff:ff:ff:ff:ff Show all Ethernet broadcasts (includes ARP requests)

7) Troubleshooting and Failure Modes

Forwarding and ARP failures are among the most common network problems. Because they involve both Layer 2 and Layer 3, the symptoms can be confusing unless you know where to look. The table below maps common symptoms to likely causes and the first diagnostic step you should take.

ARP Troubleshooting Workflow

1. Clear the ARP cache (arp -d *) to ensure fresh resolutions.
2. Start a Wireshark capture filtered to arp.
3. Ping the target IP address.
4. In Wireshark, confirm an ARP Request was sent and look for the ARP Reply.
5. If no reply: the target is unreachable at Layer 2. Check cables, VLANs, and that the target is powered on.
6. If a reply arrives but pings still fail: the issue is higher up — check IP configuration, routing, or firewall rules.

Real-World Design Context: Why This Matters Beyond the Lab

The forwarding process described this week is not just exam material. It is the exact sequence that runs billions of times per second across the internet and in every enterprise data center. Grasping these mechanics informs decisions across multiple domains:

• TTL and security monitoring: Security analysts use TTL values to fingerprint operating systems. A packet arriving with TTL = 118 likely started at 128, meaning it crossed approximately 10 hops. If that same source normally shows TTL = 62 (started at 64, 2 hops away), the discrepancy may indicate IP spoofing or traffic redirection.
• ARP and LAN security: ARP spoofing is the foundation of man-in-the-middle attacks on switched LANs. Enterprises deploy Dynamic ARP Inspection (DAI) on switches to validate ARP packets against a trusted binding table. Understanding how ARP works is a prerequisite for understanding how these defenses function.
• MTU and application performance: Fragmentation degrades throughput and breaks some VPN and tunneling protocols. Network engineers configure Path MTU Discovery and adjust interface MTUs on tunnel endpoints. The DF bit and ICMP Fragmentation Needed messages are the mechanisms behind this.
• Cloud and virtual networking: In AWS, Azure, and GCP, the forwarding model described this week still applies — but the "router" is a virtual construct and ARP may be intercepted by the hypervisor. Understanding the physical model is essential before learning how cloud networking abstracts it.
• Routing table design: The longest-prefix match rule introduced this week is the foundation of every routing protocol. OSPF, BGP, and even SD-WAN overlays all populate the same forwarding table that uses this same lookup logic.

Guided Lab: Analyzing ARP and IPv4 Headers in Wireshark

Goal: Observe ARP resolution and IPv4 header fields in a live packet capture, and trace the forwarding behavior of traffic across at least one router hop.

Prerequisites

• Wireshark installed (or access to a pre-captured .pcap file)
• A network with at least one other reachable host and a default gateway
• Administrative/root access to clear the ARP cache

Part A: Observing ARP Resolution

1. Open Wireshark and start a capture on your active network interface.
2. Open a terminal and clear your ARP cache:
   Windows: arp -d *
Linux/macOS: sudo ip neigh flush all
3. Ping your default gateway: ping 10.1.1.1 (use your actual gateway IP).
4. Stop the Wireshark capture after a few seconds.
5. Apply the display filter: arp
6. Locate the ARP Request:
   • Confirm the destination MAC is ff:ff:ff:ff:ff:ff (broadcast).
   • Note the sender IP and sender MAC in the ARP payload.
   • Note the target IP (your gateway) and that the target MAC is 00:00:00:00:00:00.
7. Locate the ARP Reply:
   • Confirm it is unicast (destination MAC matches your machine).
   • Record the gateway's MAC address from the sender MAC field.
8. Verify the ARP cache now contains the gateway entry: arp -a

Part B: Inspecting IPv4 Headers

1. Start a new Wireshark capture.
2. Ping an external IP address (e.g., ping 8.8.8.8).
3. Stop the capture and filter: icmp
4. Select an Echo Request packet and expand the "Internet Protocol Version 4" section:
   • Record the TTL value set by your OS.
   • Confirm Protocol = 1 (ICMP).
   • Note whether the DF flag is set.
   • Verify the source IP is your machine and the destination is 8.8.8.8.
5. Select the corresponding Echo Reply:
   • Record its TTL. The difference between this TTL and the server's likely initial TTL (often 64 or 128) tells you how many hops the reply crossed.
   • Note that the source and destination IPs are swapped compared to the request.
6. Now examine the Ethernet layer of the Echo Request:
   • Confirm the destination MAC is your gateway's MAC (not 8.8.8.8's MAC — that address is not on your LAN).
   • This proves the routed delivery model: IP header points to the remote destination, Ethernet header points to the local gateway.

Part C: Recording Your Findings

Document the following in a short report:

1. The ARP Request/Reply exchange for your gateway (IPs, MACs, broadcast vs. unicast).
2. The IPv4 header fields of one ICMP Echo Request (TTL, Protocol, Flags, source IP, destination IP).
3. The Ethernet destination MAC of the ICMP Echo Request and why it is the gateway's MAC, not 8.8.8.8's MAC.
4. The TTL of the Echo Reply and your calculation of how many hops it crossed.

Deliverable

A one-page report containing annotated Wireshark screenshots (or text extracts) showing the ARP exchange, the IPv4 header fields, and the MAC-vs-IP addressing proof. Include a sentence explaining why the Ethernet destination MAC is the gateway, not the remote server.

Week 7 Outcome Check

By the end of this week, you should be able to:

• Name the key IPv4 header fields and explain the role of TTL, Protocol, Flags, and Fragment Offset
• Walk through the ARP resolution process from cache check to broadcast request to unicast reply
• Explain why a host ARPs for its gateway when sending to a remote destination, not for the destination itself
• Trace a packet across a router hop, identifying what changes (MAC addresses, TTL, checksum) and what stays the same (source IP, destination IP)
• Use arp -a, Wireshark ARP filters, and IPv4 header inspection to verify forwarding behavior
• Diagnose common failures such as missing ARP entries, wrong subnet masks, missing gateways, and routing loops

Next week introduces IPv6 fundamentals: the 128-bit address format, address types, and SLAAC.

Hands-On Labs

Use these activities to build practical skills with ARP, IPv4 headers, and forwarding logic.

Checkpoint Questions

1. What happens to a packet when its TTL reaches zero at a router? What ICMP message is generated?
2. Explain why the IPv4 header checksum must be recalculated at every hop, even though the source and destination IP addresses do not change.
3. A host with IP 10.1.1.10/24 sends a packet to 10.1.1.50. Does it ARP for the destination directly or for the gateway? Why?
4. The same host sends a packet to 10.2.2.50. What MAC address appears as the Ethernet destination in the frame leaving the host?
5. What is the purpose of the Protocol field in the IPv4 header? Give three protocol number examples.
6. Why does setting the DF (Don't Fragment) bit help with Path MTU Discovery? What happens if a packet with DF set is too large for a link?
7. A host's ARP cache shows "incomplete" for a local IP address. List three possible causes.
8. In a Wireshark capture, you see an ICMP Echo Reply with TTL = 52. If the remote server is running Linux (default TTL = 64), approximately how many router hops did the reply cross?

Weekly Reflection

Reflection prompt (200-300 words):

This week shifted from address planning to understanding how packets actually move through a network. Reflect on the relationship between Layer 2 and Layer 3 in the forwarding process.

• Why is ARP necessary in an Ethernet network even though we already have IP addresses?
• What would happen in a network without TTL? What kinds of failures would become permanent instead of temporary?
• Why is the distinction between "same-subnet" and "routed" delivery the most important concept in Layer 3 forwarding?
• How does understanding the packet path help you troubleshoot problems that might otherwise seem mysterious?

A strong reflection should connect the mechanics of ARP and router forwarding to the troubleshooting and design decisions that network engineers make every day.

Recommended References

• RFC 791: Internet Protocol (IPv4 Specification) — the original standard defining the IPv4 header format, fragmentation, and forwarding behavior.
• RFC 826: An Ethernet Address Resolution Protocol — the ARP specification describing request/reply mechanics and cache behavior.
• RFC 1191: Path MTU Discovery — explains how the DF bit and ICMP Fragmentation Needed messages enable hosts to discover the maximum MTU along a path.
• IANA Protocol Numbers: Protocol Numbers Registry — the authoritative list of IPv4 Protocol field values (1=ICMP, 6=TCP, 17=UDP, etc.).
• Cisco Networking Academy: Networking Basics — structured coursework on IPv4 forwarding, ARP, and router operation aligned with CCNA objectives.
• Wireshark User Guide: Wireshark Documentation — reference for capture setup, display filters, and protocol dissection used in this week's lab.
• SANS SEC503: Intrusion Detection In-Depth — Day 2 covers packet header analysis in a security context, including TTL fingerprinting and fragmentation attacks.

Read RFC 791 sections 3.1 (header format) and 3.2 (fragmentation) alongside your Wireshark captures. Seeing the standard and the live traffic side by side builds the deepest understanding.

Week 07 Quiz

Test your understanding of IPv4 header fields, ARP mechanics, router forwarding decisions, and same-subnet vs. routed delivery.