← Interview Prep

Life of a Packet — Fundamentals

Three scenarios, walked field by field: what changes, what stays, and why.

A whiteboard-friendly format: at every hop, write down what changed, what stayed the same, and why. The one principle to state out loud before anything else:

The L2 header lives exactly one hop (hop-by-hop) and is rewritten at every router. L3 addresses live end-to-end and never change — until NAT appears. L4 is touched by no one except NAT and MSS clamping.

Scenario A — One L2 segment (single subnet)

H1 ──────── SW1 ──────── H2
10.0.10.11/24           10.0.10.22/24
aa:aa:aa:00:00:11       aa:aa:aa:00:00:22
        VLAN 10, both ports access

A.1 The sender's decision: local or via the gateway

H1 applies its own mask to the destination address:

• 10.0.10.11 AND 255.255.255.0 = 10.0.10.0
• 10.0.10.22 AND 255.255.255.0 = 10.0.10.0

They match → the destination is on my subnet → send it directly, destination MAC = H2's own MAC, the gateway is not involved at all.

This is the key fork of the whole walkthrough, and it must be said explicitly: the router is neither needed nor involved in this scenario, even if one exists on the network.

A.2 ARP (if the cache is empty)

ARP Request — broadcast:

ARP Reply — now unicast, from H2 to H1, with the Target filled in.

Side effect: at this moment the switch learned H1's MAC on its port (from the request's SRC MAC), and H2's MAC from the reply.

A.3 The data frame

A.4 What the switch does

• Looks only at the DST MAC, searches for it in the MAC table (FDB) for this VLAN.
• Found → sends out one port. Not found → floods to all ports in the VLAN except the ingress one (unknown unicast flooding).
• Does not touch the IP header: TTL is not decremented, the IP checksum is not recomputed.
• FCS: under store-and-forward it is checked and regenerated. Adding or removing an 802.1Q tag forces an FCS recompute, because the frame length changed.

A.5 If there is a trunk between them

On a trunk an 802.1Q tag is inserted — +4 bytes between SRC MAC and EtherType:

The maximum frame becomes 1522 bytes. On the egress access port the tag is stripped. This is the only modification a "plain" switch makes to a frame.

Scenario B — Routing, multiple hops

H1 ── R1 ══ R2 ══ R3 ── H2
10.0.10.11/24                        10.0.30.22/24
GW 10.0.10.1                         GW 10.0.30.1

R1: e0 10.0.10.1/24   (MAC bb:...:01)   e1 10.0.255.0/31 (MAC bb:...:11)
R2: e0 10.0.255.1/31  (MAC cc:...:01)   e1 10.0.255.2/31 (MAC cc:...:11)
R3: e0 10.0.255.3/31  (MAC dd:...:01)   e1 10.0.30.1/24  (MAC dd:...:11)

B.1 The sender's decision

10.0.30.22 AND 255.255.255.0 = 10.0.30.0 ≠ 10.0.10.0 → different subnet → send to the default gateway's MAC.

A critical detail people trip on: ARP is done for the gateway's IP (10.0.10.1), not the receiver's IP. H1 will never learn H2's MAC, and it shouldn't.

B.2 The frame on the first hop (H1 → R1)

B.3 What happens at every router

The same loop, repeated on R1, R2, R3:

1. Verify the DST MAC is mine (otherwise drop, unless promiscuous).
2. Strip the L2 header, check the FCS.
3. Take the DST IP → LPM lookup in the FIB → egress interface and next-hop.
4. TTL − 1. If it hits 0 → drop and return ICMP Time Exceeded (type 11).
5. Recompute the IP header checksum (incrementally, RFC 1624 — the whole header is not re-summed).
6. Find the next-hop MAC (ARP / neighbor cache); no entry → ARP request, the packet waits in a queue.
7. Build a new L2 header: SRC MAC = my egress interface, DST MAC = next-hop.
8. Recompute the FCS and send.

B.4 Per-hop summary

In one sentence: L2 changes completely at every hop, L3 addresses change nowhere, TTL decreases, the IP checksum is recomputed, and no one touches L4.

B.5 The subtleties that separate levels

• TCP/UDP checksum does not change, even though the pseudo-header contains IP addresses — simply because the addresses didn't change. In Scenario C this stops being true.
• IPv6: no header checksum at all (nothing to recompute), TTL is called Hop Limit, and intermediate nodes do not fragment — only the source does, after PMTUD.
• IPv4 fragmentation: if the egress MTU is smaller than the packet and DF=0, the router splits it, filling Identification, the MF flag and Fragment Offset; only the receiver reassembles. If DF=1 — drop and ICMP type 3 code 4 with the MTU. Hence PMTUD and its black holes when ICMP is filtered.
• ECMP: with several paths, selection is by a hash of the 5-tuple; packets of one flow follow one path (to preserve ordering), different flows take different paths.
• Traceroute is built on exactly this: packets with TTL 1, 2, 3… each hop returns Time Exceeded with its own address.
• The return traffic is a fully mirrored procedure, and the path may be asymmetric — normal for routing, but it breaks stateful devices (firewalls, NAT).

Scenario C — L2 + L3 + Internet via NAT

H1 ── SW1 ── R(NAT/FW) ══ ISP ══ Internet ── Server
192.168.1.11/24          WAN 203.0.113.5              93.184.216.34:443
GW 192.168.1.1

H1 opens a TCP session to 93.184.216.34:443, source port 51514.

C.1 Inside the LAN (H1 → R)

As in Scenario B: different subnet → ARP for the gateway → frame to the gateway's MAC.

C.2 At the NAT router — what changes on top

First ordinary routing (TTL−1, new L2, IP checksum recompute), and on top of that:

The key point to state explicitly: NAT is the only place in this walkthrough where an L3 address changes and, as a consequence, an L4 checksum must be touched. That is what separates NAT from routing fundamentally, not quantitatively.

A translation-table (conntrack) entry appears:

192.168.1.11:51514  ⇄  203.0.113.5:62001  →  93.184.216.34:443   TCP  ESTABLISHED

C.3 The packet on the Internet

The server sees only the public address; it knows nothing about the existence of 192.168.1.11.

C.4 The return path

The reply arrives at 203.0.113.5:62001. The router looks up the translation table:

• found → DST IP is rewritten to 192.168.1.11, DST port to 51514, IP and TCP checksums recomputed;
• not found (session expired, a restart, an asymmetric path) → the packet is dropped. Hence "the session was working and suddenly died" after a timeout or a failover to a standby node without state sync.

Then ordinary LAN delivery: ARP for 192.168.1.11, frame to H1's MAC.

Cheat sheet: what changes where

How to present it at the whiteboard

1. Start with the fork: my subnet or someone else's — everything else depends on it. Show the AND-with-the-mask operation.
2. State separately: ARP is always for the next-hop, not the final address.
3. Keep two columns — "changes" and "doesn't change." The interviewer is usually looking for exactly this understanding of the hop-by-hop vs. end-to-end boundary.
4. Call out the side effects: MAC learning, ARP-cache population, conntrack entry creation. State is what breaks later.
5. Finish with a clarifying question: "want me to show what changes if we insert MPLS/VXLAN between hops, or if the path is asymmetric?" — this turns the walkthrough into a dialogue and shows depth.

Likely follow-up questions

• What happens if two hosts in the same segment have different masks?
• Why does a router decrement TTL but a switch doesn't — and what then protects the L2 network from loops? (nothing, hence STP and storm control)
• Why did IPv6 drop the header checksum? (L4 and L2 already compute one, and recomputing at every hop was wasted work)
• What does the same walkthrough look like for a VRRP gateway? (virtual MAC 00:00:5e:00:01:XX, the active router answers ARP)
• What happens on an asymmetric path through two NAT devices without state sync?
• Where does a firewall enter this picture, and why is it stateful too?