An IPv4 host reaches peers on its own subnet but nothing beyond it; what can the ARP traffic on its segment tell you about where the fault lies?
answer
- what is the host asking for
- who-has the gateway, unanswered
- who-has a remote address
- an answer from an unexpected MAC
- code 1 from a far router
basics
~20 sRead what the host asks for. Unanswered gateway requests implicate the gateway or the path to it; requests for remote addresses mean a too-wide mask; an unexpected or duplicate reply means another station claims the gateway.
solid answer
~50 sA host needs exactly one mapping for off-subnet traffic: its gateway's, so a capture of ARP on the segment answers two questions - is it asking for the right address, and does anyone answer? Repeated requests for the gateway's IPv4 address with no reply point at the gateway's interface, a wrong gateway address, or a host and gateway in different broadcast domains such as mismatched VLANs. Requests for remote addresses mean the host thinks they are on-link: its mask is too wide. Replies for the gateway from an unexpected MAC, or from two MACs, mean another station claims that address. If the gateway resolves cleanly, ARP at the sender has done its job and the fault is past the first hop - where a failed ARP on the last router comes back as ICMP Destination Unreachable, code 1 (Host Unreachable).
go deeper
Recall that off-subnet traffic depends on resolving the default gateway, so a gateway that never answers ARP cuts off everything beyond the local subnet.
Explain how the mask decides which address gets resolved, and why requests for remote addresses or unanswered gateway requests point at different misconfigurations.
Demonstrate the triage: read the ARP target and the answers on the segment, separate first-hop faults from later ones, and interpret code 1 Host Unreachable as a far-side resolution failure.
Consider which first-hop signals your monitoring should watch, and how broadcast domain size and proxy ARP habits make these faults harder to localise.
## Start from the frame the host is trying to build For any off-subnet destination an IPv4 host needs exactly one mapping: that of its next hop, normally the default gateway. RFC 1122's local/remote decision splits destinations into on-link and off-link using the subnet mask, and only on-link addresses - including the gateway - are ever ARP targets. So "local works, remote fails" splits into two questions that the ARP exchange answers directly: **is the host asking for the right address**, and **is anyone answering**? A packet capture on the host's segment, filtered to EtherType `0x0806`, shows both. ## Reading the pattern | What the segment shows | What it means | Where to look next | |---|---|---| | Repeated requests for the gateway's IPv4 address, no reply | the gateway's interface is down, the configured gateway address is wrong, or host and gateway are not in the same broadcast domain (for example, different VLANs) | the gateway's address and interface, the switch port's VLAN | | Requests for remote addresses such as `198.51.100.20` | the host believes they are on-link: its mask is too wide | the host's prefix length | | Gateway replies come from an unexpected MAC, or from two different MACs | another station claims the gateway's address, by misconfiguration or forgery | address-conflict and spoofing checks | | The gateway resolves; remote traffic still fails | resolution at the sender is done; the fault is past the first hop | routing and filtering beyond the gateway, the far LAN | | No request for the gateway at all | the host already holds a mapping, possibly an outdated one, or no route sends traffic towards the gateway | the host's cached entry and routing table | The second row is the most decisive. A host with a correct mask and ordinary routes has no reason to ARP for an off-subnet address, so seeing such requests convicts the mask - unless a router on the segment answers them with proxy ARP, which hides the error instead of fixing it. ## The protocol rules that shape what you see - **Rate limit.** RFC 1122 section 2.3.2.1 requires a mechanism that prevents ARP flooding and recommends at most one request per second per destination, so an unanswered gateway shows up as a slow, steady retry rather than a storm. - **Held packets.** RFC 1122 section 2.3.2.2 says the link layer SHOULD keep at least the latest packet for an unresolved address and send it after resolution. An implementation that discards instead loses the first packet of every exchange; the first TCP connection request or DNS query after an entry expires is then recovered only by retransmission, which looks like a sporadic stall rather than a failure. - **Routers report late, not early.** RFC 1812 section 3.3.2 says a router's link layer MUST NOT report a destination unreachable merely because no ARP entry exists; it queues a few datagrams and reports only when resolution proves fruitless. ## Past the first hop Once the gateway is resolved, every remaining ARP exchange happens on other links, out of the sender's sight. The one that matters most is on the last router. If the destination host does not answer that router's request, RFC 1812 has the router return **ICMP Destination Unreachable, code 1 (Host Unreachable)**, which it defines as a directly connected host that "does not respond to ARP". Seeing code 1 from a remote router therefore says the far LAN could not resolve the host - a powered-off server, a wrong address on it, or a VLAN mistake on the far side - not that anything is wrong locally. **Code 0 (Net Unreachable)** means something different: a router had no route to the destination network at all. ## Traps in the reasoning 1. Treating an existing ARP entry for the gateway as proof that the gateway is up: the entry may predate the outage, so watch for a fresh request and reply. 2. Expecting the remote host's MAC anywhere on the local segment: it never appears there. 3. Blaming ARP for a filtering drop: if the gateway resolves and forwards, ARP has done its whole job at the sender. 4. Reading proxy-ARP replies for remote addresses as a healthy network: they mean a router is papering over a wrong mask.
- Why can the first connection after a quiet period be slow even when ARP works?If the cached mapping has expired, the host must resolve the next hop again before sending. RFC 1122 says the link layer SHOULD hold at least the latest waiting packet and send it after resolution; an implementation that drops it instead loses that first packet, so a TCP connection request or DNS query waits for its retransmission timer - a stall, not an error.
- The gateway resolves and forwards, yet a remote router returns ICMP Destination Unreachable, code 1; what does that mean?Per RFC 1812, code 1 (Host Unreachable) is what the router attached to the destination's subnet sends when that host does not answer its ARP request. The sender's own resolution is fine; the fault is on the far LAN - the host is down, misaddressed, or in the wrong VLAN there.
saying these in an interview costs you the question
- If the gateway never answers ARP, the host broadcasts the data packets instead.
- ARP requests for remote addresses are normal for off-subnet traffic.
- An ARP failure at the far router appears as an ARP timeout on the sender.
- A host retries an unanswered ARP request as fast as it can.
- An existing ARP entry for the gateway proves the gateway is reachable.