FUNDAMENTALS · MECHANISM WALKTHROUGH

PC to Internet
What Really Happens, Step by Step

the exact order of events from cable-in to a page loading — read once, rehearse the skeleton below, and you can explain it cold.

LINK UP→ PORT STATE (STP)→ DHCP (DORA)→ ARP → GATEWAY→ SWITCH (MAC TABLE)→ ROUTE→ NAT/PAT→ FIREWALL POLICY→ INTERNET→ RETURN (STATEFUL)

01 The Full Sequence — Worked Example

Physical Link (Layer 1)

Cable goes into the switchport. The NIC and switch auto-negotiate speed/duplex, the link light comes up, and the port state moves from down to up.

Link

Switch Port State (Spanning Tree)

If STP is running, the port cycles Blocking → Listening → Learning → Forwarding (~30-50s on classic 802.1D) — unless it's an access/edge port with PortFast enabled, which jumps straight to Forwarding since a single PC can't form a loop. The switch also starts learning the PC's source MAC off the very first frame it transmits, whatever that frame turns out to be.

L2 Port

DHCP — Getting an IP (DORA)

The PC has no IP yet, so everything here is broadcast: Discover ("any DHCP server out there?") → server replies with an Offer (192.168.10.55) → PC broadcasts a Request to accept it, which also tells any other server on the segment its offer wasn't taken → server sends an Ack confirming the lease. If the DHCP server isn't on this subnet, the gateway relays the broadcast as a unicast (ip helper-address).

DHCP

Checkpoint — What the PC Now Has

IP: 192.168.10.55/24 Gateway: 192.168.10.1 DNS: 8.8.8.8 Lease time: e.g. 24h. Every step from here on is built on these four values — nothing else has happened yet.

Checkpoint

ARP — Finding the Gateway's MAC

The PC compares the destination (an internet address) against its own /24 — it's not local, so the frame needs to go to the gateway's MAC, not the destination's. ARP request broadcast: "who has 192.168.10.1?" → gateway replies with its MAC → cached locally (commonly ~4 hours).

ARP

DNS Resolution (brief)

Before anything meaningful can be requested, the domain name (e.g. example.com) needs an IP. The resolver query to 8.8.8.8 (UDP/53) travels this exact same switch → gateway → NAT → firewall → internet path — DNS traffic isn't special-cased, it's just another flow.

DNS

Switch Forwards Toward the Gateway

The frame is addressed to the gateway's MAC (from step 5). The switch looks that MAC up in its table and sends the frame out one specific port — no flooding, because it's a known unicast destination now.

L2 Forward

Routing at the Gateway

The gateway strips the L2 header, reads the destination IP, matches its default route, and forwards the packet toward the firewall/WAN edge.

L3 Route

NAT / PAT Translation

The private source 192.168.10.55:51422 gets rewritten to a public IP:port, e.g. 203.0.113.9:40551. A translation table entry is created — this entry is exactly what makes the return trip possible later.

NAT

Firewall Policy Evaluation

State table lookup finds no existing session, so the rule base is evaluated top-down. A matching allow rule (LAN→WAN) creates a new session entry, and the packet is forwarded out the WAN interface.

Firewall

Out to the ISP and Across the Internet

From here it's routed between autonomous systems via BGP-learned paths — outside your network's control. In an interview, acknowledging this exists is enough; it's not where the depth is expected.

Internet

The Response Comes Back

The destination server replies, addressed to your public IP:port — 203.0.113.9:40551.

Response

Return Path — Stateful

The firewall matches this against the session created in step 10 — no separate inbound rule is needed — un-NATs the destination back to 192.168.10.55, and routes it back through the gateway.

Return

Switch Delivers to the PC

The switch already has 192.168.10.55's MAC in its table from step 2 — no flooding, no ARP needed on this leg. The frame goes straight out the PC's port, and the loop closes.

Delivered

02 How to Explain This in an Interview

State your assumption up front — say "I'll assume a dynamic IP via DHCP" before you start. It signals you know static addressing is a variant, without derailing the walkthrough.
Don't skip ARP. It's the single most commonly forgotten step, and skipping it is the clearest signal of shallow, memorized-only understanding rather than real experience.
Explicitly explain why return traffic doesn't need a new inbound firewall rule. This is often the exact detail an interviewer is listening for — it proves you understand state, not just "allow/deny."
Narrate cause → effect, not just a list of protocol names. "Because the PC's stack doesn't have an IP yet, it has to broadcast" shows understanding. "Then DHCP happens" doesn't.
Keep a steady pace. Fourteen steps in under 90 seconds is about right — rushing sounds rehearsed, stalling on any one step signals you don't actually know what's underneath the buzzword.

03 Follow-Up / Gotcha Questions

Q What if DHCP fails — can the PC reach anything at all?

A Not usefully. Windows self-assigns a 169.254.x.x APIPA address, which only allows communication with other APIPA hosts on the same local segment — there's no default gateway or DNS, so nothing beyond the local link is reachable.

Q What if the ARP request for the gateway times out?

A The PC has no Layer 2 address to send the frame to, so it can't leave the local segment at all — even though the PC's own IP configuration is perfectly valid. This is a classic "IP looks fine but nothing works" symptom.

Q Why doesn't return traffic need an explicit inbound firewall rule?

A A stateful firewall records the outbound session in a state table the instant it's created. Any reply matching that session's 5-tuple is automatically permitted as "established" — the rule base is only consulted for genuinely new sessions.

Q What if the PC's cached ARP entry for the gateway is stale (e.g. after an HSRP failover)?

A Traffic gets sent to a MAC address that's no longer answering, and connectivity silently breaks until the cache entry expires and re-resolves — unless the new active gateway sends a gratuitous ARP, which is exactly why HSRP/VRRP failover does that immediately.

Q Why does the switch flood the very first DHCP Discover frame instead of dropping it?

A The switch's MAC table only maps destinations it has already learned. Before that — and for any genuine broadcast — it floods out every port in the VLAN except the one it arrived on. That's precisely how a Discover finds a server without the PC or switch knowing anything about the network yet.

Q Where does NAT actually happen — the router or the firewall?

A Whichever device sits at the network edge — in most SMB/branch designs that's the firewall itself, since it's already stateful and already inspecting every session. Larger networks sometimes separate the roles, but the mechanism is identical either way.

04 Quick-Fire Glossary

Term	Meaning
DORA	Discover, Offer, Request, Ack — the four-step DHCP lease process
ARP	Address Resolution Protocol — maps a known IP to its Layer 2 MAC address on the local segment
MAC / CAM Table	The switch's mapping of learned source MACs to the port they arrived on
PortFast / Edge Port	STP setting that skips Listening/Learning delay on ports known to only ever face end hosts
RFC 1918	The private IP ranges (10/8, 172.16/12, 192.168/16) that require NAT to reach the internet
NAT vs PAT	NAT translates one IP to another; PAT (overload) shares one public IP across many sessions using different ports
State Table	The firewall's live record of established sessions, used to auto-permit return traffic
APIPA	169.254.0.0/16 — the self-assigned range a host falls back to when DHCP fails
Gratuitous ARP	An unsolicited ARP reply used to immediately update other hosts' caches, e.g. after a gateway failover
BGP	The routing protocol that determines paths between networks (autonomous systems) across the internet