Troubleshooting Lab: Nothing Reaches the Internet

When resolution fails, no IP packet is ever sent at all

Step 1 of 2 — understand the idea. Read this first and the packet trace will confirm what you already expect, instead of teaching you two things at once.

What you'll be able to do

▸Recognise the signature of an unanswered ARP in a capture
▸Explain why an ARP failure produces no IP traffic whatsoever
▸Distinguish an ARP problem from a routing problem and from a server problem

Before this lesson — it builds directly on:

When ARP fails, the user's report is always the same: 'nothing works'. Not 'the website is slow' or 'email is down' — everything, at once. That is because ARP sits underneath all of it. Web, email, DNS, updates: every one of them eventually needs a frame, and no frame can be built without a destination MAC address. One missing answer takes out every application simultaneously. The good news is that this makes it easy to identify. A failure this total leaves an unmistakable capture.

✗ Common misunderstanding: ARP replies are broadcast, like the requests.

Why that's wrong: The replier learned the asker's MAC from the request itself, so it can answer privately. Broadcasting would waste every other host's attention.

Correct model: Requests broadcast because the asker knows nobody. Replies unicast because the replier now does.

The packets prove it: Compare the Ethernet destination on packets 1 and 2 of the local-resolution trace: ff:ff:ff:ff:ff:ff, then one specific MAC.

Watch these fields in the lab: arp.targetIp

1Predict the healthy trace first. Reaching a remote server should give you: ARP request → ARP reply → IP traffic. Write that down before looking.
2Check what is present. Here: ARP requests for the gateway. That already proves the interface is up, the address is configured, the mask arithmetic is right, and a gateway is set.
3Check what is absent. No replies. And — the decisive observation — no IP packets of any kind.
4Eliminate. Every hypothesis that needs a packet to have left the host is now impossible: DNS, remote firewalls, routing, server health.
5Locate. What remains must be within one link: wrong VLAN, gateway interface down, gateway address unassigned, or ARP filtered.
6Report as evidence plus conclusion, not as a guess. 'Three ARP requests for the gateway, no reply, zero IP traffic' is a sentence a network team can act on.

Watch these fields in the lab: arp.targetIp · arp.senderIp

✓ Concept check — before you open the packets

These test the idea, not the trace. You should be able to answer them from the explanation above.

Why is 'no IP packets in the capture' stronger evidence than 'no ARP replies in the capture'?

A different host on the same segment reaches everything fine. What does that add to your diagnosis?

Now that you understand the concept, observe how it appears in the packet exchange.

The lab runs a real simulated capture — pause, step, click any packet, and inspect every byte.